idnits 2.17.1 draft-hallambaker-mesh-recrypt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'None' is mentioned on line 860, but not defined -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 16, 2017 5 Expires: February 17, 2018 7 Mesh/Recrypt: Usable Confidentiality 8 draft-hallambaker-mesh-recrypt-02 10 Abstract 12 independent 14 A messaging infrastructure providing full end-to end security is 15 presented. Unlike existing approaches such as S/MIME and OpenPGP, 16 Mesh/Recrypt uses proxy re-encryption to preserve full end-to-end 17 security with individual user and device keys in situations such as 18 the user having multiple decryption devices and messages being set to 19 mailing lists. 21 This document shows the use of Mesh/Recrypt to address the principle 22 use cases Mesh/Recrypt is designed to address. These include 23 asynchronous messaging such as mail and controlled documents and 24 synchronous messaging applications such as chat, voice and video. 26 This document is also available online at 27 http://prismproof.org/Documents/draft-hallambaker-mesh-recrypt.html . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 17, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Related Specifications . . . . . . . . . . . . . . . . . 5 66 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 3. Proxy Re-Encryption . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Proxy Re-Encryption Algorithms . . . . . . . . . . . . . 6 70 3.2. Applying Mesh/Recrypt . . . . . . . . . . . . . . . . . . 10 71 3.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 72 3.4. Chat rooms and other streaming data. . . . . . . . . . . 10 73 3.5. Confidential Document Control . . . . . . . . . . . . . . 11 74 3.6. Multiple Devices . . . . . . . . . . . . . . . . . . . . 12 75 4. Mesh/Recrypt/Admin Service . . . . . . . . . . . . . . . . . 12 76 4.1. Request Messages . . . . . . . . . . . . . . . . . . . . 13 77 4.1.1. Message: RecryptRequest . . . . . . . . . . . . . . . 13 78 4.2. Response Messages . . . . . . . . . . . . . . . . . . . . 13 79 4.2.1. Message: RecryptResponse . . . . . . . . . . . . . . 13 80 4.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 13 81 4.4. Common classes . . . . . . . . . . . . . . . . . . . . . 13 82 4.4.1. Structure: RecryptionGroup . . . . . . . . . . . . . 13 83 4.4.2. Structure: MemberEntry . . . . . . . . . . . . . . . 14 84 4.4.3. Structure: UserDecryptionEntry . . . . . . . . . . . 15 85 4.4.4. Structure: CombinedToGroup . . . . . . . . . . . . . 15 86 4.5. Administrator Transactions . . . . . . . . . . . . . . . 16 87 4.6. Transaction: Hello . . . . . . . . . . . . . . . . . . . 16 88 4.7. Transaction: CreateGroup . . . . . . . . . . . . . . . . 16 89 4.7.1. Message: CreateGroupRequest . . . . . . . . . . . . . 16 90 4.7.2. Message: CreateGroupResponse . . . . . . . . . . . . 17 91 4.8. Transaction: UpdateGroup . . . . . . . . . . . . . . . . 17 92 4.8.1. Message: UpdateGroupRequest . . . . . . . . . . . . . 17 93 4.8.2. Message: UpdateGroupResponse . . . . . . . . . . . . 17 95 4.9. Transaction: AddMember . . . . . . . . . . . . . . . . . 17 96 4.9.1. Message: AddMemberRequest . . . . . . . . . . . . . . 18 97 4.9.2. Message: AddMemberResponse . . . . . . . . . . . . . 18 98 4.10. Transaction: UpdateMember . . . . . . . . . . . . . . . . 18 99 4.10.1. Message: UpdateMemberRequest . . . . . . . . . . . . 18 100 4.10.2. Message: UpdateMemberResponse . . . . . . . . . . . 19 101 4.11. Future work . . . . . . . . . . . . . . . . . . . . . . . 19 102 5. User Service . . . . . . . . . . . . . . . . . . . . . . . . 19 103 5.1. Transaction: RecryptData . . . . . . . . . . . . . . . . 19 104 5.1.1. Message: RecryptDataRequest . . . . . . . . . . . . . 19 105 5.1.2. Message: RecryptDataResponse . . . . . . . . . . . . 20 106 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 107 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 108 7.1. Reference Implementation . . . . . . . . . . . . . . . . 20 109 7.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 21 110 7.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 21 111 7.1.3. Implementation Experience . . . . . . . . . . . . . . 21 112 7.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 21 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 117 10.2. Informative References . . . . . . . . . . . . . . . . . 22 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 120 1. Introduction 122 Traditional messaging security infrastructures are difficult to 123 configure, difficult to use and limited to one mode of communication. 124 Digital certificates are hard to obtain and harder to maintain. 125 Managing a Web of Trust requires a very high level of user 126 competence. S/MIME and OpenPGP offer end-to-end email security but 127 not streaming services such as video, voice or chat. 129 In recent years a number of proprietary chat systems have been 130 extended to the point that a single application and protocol supports 131 chat, voice, video and asynchronous communication modes such as 132 messaging and file transfer. While such systems typically claim to 133 offer cryptographic security, the extent to which this is achieved is 134 difficult to determine. Even systems purporting to offer ?end-to- 135 end? security have proved to be woefully inadequate when it is 136 discovered that one of the ?ends? referred to is in fact the 137 messaging infrastructure operated by the provider. 139 A key limitation of all the deployed messaging systems that were 140 reviewed in the development of this paper is that true end-to-end 141 confidentiality is only achieved for a limited set of communication 142 patterns. Specifically, bilateral communications (Alice sends a 143 message to Bob) or broadcast communications to a known set of 144 recipients (Alice sends a message to Bob, Carol and Doug). These 145 capabilities do not support communication patterns where the set of 146 recipients changes over time or is confidential. Yet such 147 requirements commonly occur in situations such as sending a message 148 to a mailing list whose membership isn?t known to the sender, or 149 creating a spreadsheet whose readership is to be limited to 150 authorized members of the ?accounting? team. 152 [[This figure is not viewable in this format. The figure is 153 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 154 recrypt.html.]] 156 Traditional End-to-End Encryption is static. 158 Mesh/Recrypt is an experimental messaging infrastructure that applies 159 proxy re-encryption to support all the commonly used messaging modes 160 with strong end-to-end encryption. The primary purpose of Mesh/ 161 Recrypt is to demonstrate the advantages of using the proxy re- 162 encryption technique and to determine the feasibility of retrofitting 163 such capabilities to legacy protocols such as SMTP, IMAP and XMPP. 165 [[This figure is not viewable in this format. The figure is 166 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 167 recrypt.html.]] 169 Mesh Recrypt supports End-to-End Encryption in dynamic groups. 171 Whether the advantages of building on an established base outweigh 172 those of a clean slate approach for purposes of deployment are 173 currently unknown, but there are clear advantages of using a clean 174 slate approach for purposes of exposition. 176 As the name suggests, Mesh/Recrypt makes use of the Mathematical Mesh 177 infrastructure for management of user keys. For clarity and 178 convenience, this document describes the application of Mesh/Recrypt 179 to a completely new protocol suite. Strategies for adding similar 180 capabilities to existing specifications are discussed as possible 181 future work. 183 2. Definitions 185 This section presents the related specifications and standards on 186 which Mesh/Recrypt is built, the terms that are used as terms of art 187 within the documents and the terms used as requirements language. 189 2.1. Related Specifications 191 The related specifications used in the Mesh/Recrypt protocol are 192 described in the Mesh Architecture specification [draft-hallambaker- 193 mesh-architecture] [draft-hallambaker-mesh-architecture] 195 2.2. Defined Terms 197 The following terms are used as terms of art in this document with 198 the meaning specified below: 200 An Access Control mechanism that uses cryptography to control read 201 access to static content (typically documents) within its control. 203 Content that is subject to control of a CDC system. 205 A cryptography mechanism that permits a party that does not have 206 the ability to decrypt an encrypted message to transform it into a 207 message that can be decrypted under a different private key than 208 the original. 210 The term ?recryption? is used as a synonym for Proxy Re-Encryption 211 in this document. 213 A cryptographic key that is used to enable a different party to 214 decrypt an encrypted message that does not grant decryption 215 capability. 217 2.3. Requirements Language 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119] [RFC2119] . 223 3. Proxy Re-Encryption 225 Proxy re-encryption provides a technical capability that meets the 226 needs of such communication patterns. Conventional symmetric key 227 cryptography uses a single key to encrypt and decrypt data. Public 228 key cryptography uses two keys, the key used to encrypt data is 229 separate from the key used to decrypt. Proxy re-encryption 230 introduces a third key (the recryption key) that allows a party to 231 permit an encrypted data packet to be decrypted using a different key 232 without permitting the data to be decrypted. 234 The introduction of a recryption key permits end-to-end 235 confidentiality to be preserved when a communication pattern requires 236 that some part of the communication be supported by a service. 238 The introduction of a third type of key, the recryption key permits 239 two new roles to be established, that of an administrator and 240 recryption service. There are thus four parties: 242 Holder of Decryption Key, Creator of Recryption Keys 244 Holder of Encryption Key 246 Holder of Recryption keys 248 Holder of personal decryption key 250 The communication between these parties is shown in Figure X below: 252 [[This figure is not viewable in this format. The figure is 253 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 254 recrypt.html.]] 256 Mesh/Recrypt Parties 258 The chief advantage of recryption is that the recryption service does 259 not have the ability to decrypt messages and does not need to be 260 trusted at the same level as a recipient. A recryption service may 261 be implemented as a cloud service on an untrusted host or managed in 262 house by a system administrator who is only partially trusted. 264 3.1. Proxy Re-Encryption Algorithms 266 Proxy Re-Encryption was introduced by Blaze et. al. [Blaze98] 267 [Blaze98] in 1998. In this paper, we make use of the Diffie Hellman 268 based mechanism described in this paper. While this approach does 269 not have capabilities such as reversibility or transitivity offered 270 in later work, such features do not appear to offer any practical 271 advantages in developing protocols for the intended applications and 272 may well introduce significant disadvantages. 274 The use of the Diffie Hellman based approach has the considerable 275 advantages of being compatible with the recently developed CFRG 276 Elliptic Curve algorithms and being minimally unencumbered by IPR 277 claims. 279 Recall that in the Diffie Hellman key agreement algorithm, shared 280 parameters e and p are generated, these being an exponent value (e) 281 and a modulus value (p). To create a shared key, two parties (Alice 282 and Bob) generate private keys a, b being positive integers in the 283 interval [2 ... p-1]. The corresponding public keys are then ea mod 284 p and eb mod p. Thus, knowledge of either {eb mod p, a} or {ea mod 285 p, b} is sufficient to calculate the shared secret value s = eab mod 286 p. 288 [[This figure is not viewable in this format. The figure is 289 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 290 recrypt.html.]] 292 Traditional Diffie-Hellman 294 When applying Diffie Hellman to a messaging protocol, it is typically 295 desirable to ensure that a unique shared value is created for each 296 exchange. If the protocol only requires authentication of the 297 receiver, the sender may ensure that each shared value is unique by 298 generating a new key pair {t, et mod p} for each exchange. 299 Alternatively, mutual authentication may be preserved if the shared 300 secret is formed from three values s = eabt mod p, where a and b are 301 the validated public keys of the sender and receiver and t is a 302 temporary key generated by the sender that has a nonce-like function. 304 To adapt Diffie Hellman to a recryption mechanism, we note that just 305 as the value s = ebt mod p may be calculated as either (eb mod p)t 306 mod p or (et mod p)b mod p, it can also be calculated as ((et mod 307 p)b-x mod p . (et mod p)x mod p) mod p. This equivalence is used to 308 create the recryption protocol. 310 Figure XX shows Bob calculating the shared secret with the aid of a 311 Recryption service. Bob's private key for decryption is now x and 312 the Recryption service has the corresponding recryption key b-x. The 313 recryption service can provide Bob with the additional information 314 needed to decrypt the message but cannot decrypt the message itself. 316 [[This figure is not viewable in this format. The figure is 317 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 318 recrypt.html.]] 320 Diffie-Hellman with Recryption 322 Applying this approach to Proxy Re-Encryption directly is 323 unacceptable since the administrator of the recryption group must 324 know Bob's private key. To avoid this problem, the administrator 325 generates a new public key pair for each member of the group and 326 encrypts the decryption portion under the public key of the member. 328 In the following example, Alice is the administrator of the 329 recryption group and Bob and Carol are recipients. 331 Generates a public key encryption pair (b, B). The algorithm used 332 for this does not matter, as the only functions used are 333 encryption and decryption. 335 Bob publishes his public key B. 337 Generates public key pair {a, ea mod p}. 339 Publishes the public key value for the recryption group ea mod p 341 To enable Bob to receive messages, Alice generates a recryption 342 keypair for Bob {a-bx, bx } and encrypts the decryption key (bx) 343 using Bob?s public key (pubB) to create a recryption entry for Bob 344 {a- bx, E(bx, pubB)}. 346 The recryption entry is sent to the recryption service. 348 At this point Alice, Bob and the Recryption Service have the 349 information they need to receive encrypted messages (figure X). 351 [[This figure is not viewable in this format. The figure is 352 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 353 recrypt.html.]] 355 Mesh/Recrypt Administration Protocol 357 Having established the necessary keying material, Carol (or any other 358 party who knows the recryption group encryption key) can encrypt a 359 message: 361 Generates a temporary key pair {t, et mod p} and uses this and the 362 public key of the recryption group (ea mod p) to create a shared 363 secret s = eat mod p that is used to encrypt the message. 365 Sends the encrypted message and temporary public key (et mod p) to 366 the recryption service 368 Receives the message and retrieves the list of intended 369 recipients, this currently has just a single entry for Bob {a-bx, 370 E(bx, B)} 372 Calculates (et mod p)a-bx mod p = eta-tbx mod p 374 Sends the encrypted message, the original temporary public key 375 generated by Carol (et mod p), the recryption value eta-tbx mod p 376 and the encrypted decryption key E(bx, B) to Bob. 378 Receives the message 380 Decrypts the E(bx, B) using his private key b to obtain bx 382 Uses bx and et mod p to calculate etbx mod p 384 Calculates (eta-tbx mod p. etbx mod p) mod p = eta mod p = s 386 Uses s to decrypt the message 388 This protocol is illustrated in figure X: 390 [[This figure is not viewable in this format. The figure is 391 available at http://prismproof.org/Documents/draft-hallambaker-mesh- 392 recrypt.html.]] 394 Mesh/Recrypt Decryption Protocol 396 Note that Alice is not a participant in the recryption protocol. 397 Administrator actions are only required when adding or removing 398 recipients to the recryption group. 400 Alice can add additional recipients to the group at any time by 401 creating a recryption pair, encrypting the decryption key under the 402 new user's public key and sending the information to the recryption 403 service, just like she did for Bob. 405 Alice can remove a user from the recryption group by telling the 406 recryption service to no longer recrypt messages to the removed 407 user?s recryption key. This requires the recryption service to be 408 trusted not to forward messages to the deleted user. To restore the 409 untrusted status of the recryption service it is necessary for the 410 administrator to create a new encryption key and a full set of 411 recryption keys for the continuing users. 413 One major limitation in the trust model of the recryption scheme 414 described is that while it is not possible for either the recryption 415 service or individual recipients to decrypt arbitrary messages the 416 recryption service and a recipient may do so if they collude. This 417 particular limitation in the trust model is an inescapable 418 consequence of the fact that the function of the recryption service 419 is to enable a recipient to decrypt a message and cannot be avoided 420 without introducing additional parties. This limitation is not 421 considered to be a serious limitation for the intended application. 423 3.2. Applying Mesh/Recrypt 425 This document describes the Mesh/Recrypt algorithm and protocol. To 426 make use of the capability it provides, it is necessary to make use 427 of it in an application protocol. Mesh/Recrypt MAY be used in any 428 application that supports data level encryption. This includes 429 mailing lists, conferencing systems offering voice or chat and 430 confidential document control. 432 3.3. Mailing Lists 434 One of the earliest uses proposed for recryption is to support end- 435 to-end security for a confidential mailing list in which the 436 membership of the list is not disclosed to its members. In this 437 application, the mail server is a recryption service and trusted to 438 maintain the confidentiality of the mailing list membership but not 439 the messages themselves. This offers many advantages over existing 440 approaches: 442 o Messages are encrypted end-to-end 444 o It is not necessary for senders to know the membership of the 445 list. 447 o New members added to the list can read messages sent before they 448 joined. 450 To apply recryption to a mailing list server, a recryption keyset is 451 created for each mailing list managed by the server and the 452 administrator responsible for maintaining the membership of the list 453 is also the administrator of the corresponding recryption key set. 455 3.4. Chat rooms and other streaming data. 457 The application of recryption to a chat room application is similar 458 to the mailing list application except that the administrator may be 459 either an offline party as before or a participant in the 460 conversation. In the latter case, the protocol should permit the 461 administrator to pass their role to another participant should they 462 need to leave. 464 One major constraint on the use of recryption to support streamed 465 audio or video is that since the messaging service cannot decrypt the 466 data stream, it can hardly be expected to perform transcoding 467 services such as producing lower resolution versions of a video 468 stream to support participants with low bandwidth connections. 469 Either all the participants must receive the exact same data feed or 470 transcoding services must be provided by a trusted party granted 471 access by the administrator. 473 3.5. Confidential Document Control 475 Confidential Document Control (CDC) uses cryptography to enforce 476 access control. Unlike Digital Rights Management and related 477 technologies, CDC only provides a means to permit or deny access to 478 confidential data while it is under protection. A CDC infrastructure 479 does not attempt to control the use made of that data by an 480 authorized recipient, in particular, a CDC infrastructure does not 481 necessarily prevent redistribution of data by a party permitted to 482 read it. 484 The application of recryption to CDC maps naturally to the use of 485 ?security labels? to control access to confidential documents in 486 government and military applications. Each security label (e.g. 487 secret#example.com) has an associated recryption key set. The 488 administrator of the recryption key set is responsible for managing 489 the parties authorized to read documents controlled under that label. 491 Recryption may be used to support the use of multiple labels. 492 Combining appropriate cryptographic operations permits a document 493 author to require recipients to be granted access for all the labels 494 specified or for any of the labels specified. For example, the 495 designation (Accounting#example.com + Executive#example.com) might 496 indicate that a recipient must be a member of the Accounting and 497 Executive teams while the designation (Accounting#example.com | 498 Executive#example.com) would enable members of either team to read 499 the material. 501 While the recryption algorithm used in Mesh/Recrypt allows the use of 502 conjunctions and disjunctions to implement the equivalent of an ACL 503 entry granting access, it is not possible to implement the equivalent 504 of an ACL entry denying access to a group of users. The recryption 505 service can be instructed to refuse recryption to a group of users 506 but this restriction is not cryptographically enforced. 508 Since users must request a recryption key from the recryption service 509 for each document accessed, the recryption service is a Policy 510 Control Point and is thus potentially a point at which additional 511 accountability and/or access controls may be introduced. An 512 enterprise recryption service might maintain a log of all access 513 requests from users and restrict access to users whose requests 514 exceed some form of quota. Attempts to access particularly sensitive 515 documents might raise flags requiring review by a supervisor. 517 3.6. Multiple Devices 519 When the S/MIME and OpenPGP email encryption schemes were developed 520 in the 1990s the machines of the day, if movable at all were 521 ?portable? rather than ?mobile?. Contemporary users demand access to 522 their communications applications from a wide variety of devices 523 including desktops, laptops, tablets, phones and even watches. The 524 need for a single user to access their email on multiple devices is 525 now the norm rather than the exception. 527 Use of multiple devices and in particular mobile devices introduces 528 obvious security concerns. A device may be lost or stolen; a machine 529 may be sold without destroying data stored on it. Such circumstances 530 very frequently result in disclosure of private keys to an attacker. 531 Maintaining separate private keys on each device allows the 532 consequences of such loss to be mitigated and further compromise 533 prevented. 535 To apply recryption to this use case, the email recipient establishes 536 a personal recryption keyset on a machine that they consider at least 537 risk of compromise. A separate recryption key entry is then created 538 for each device and the recryption keyset uploaded to a suitable 539 recryption server host (e.g. the presence service of a chat 540 application, inbound mail server, etc.) 542 One difficulty that arises in this approach is that while a non- 543 transitive recryption mechanism can be applied in either a sender 544 side context such as a mailing list or a receiver side context such 545 as supporting multiple devices, enabling the use of both at the same 546 time requires additional effort. 548 4. Mesh/Recrypt/Admin Service 550 The Mesh/Recrypt administration service supports transactions to Add 551 and Delete members from a group and to list all the members in a 552 group. 554 _recrypt._tcp 556 /.well-known/recrypt 558 Every Recrypt Service transaction consists of exactly one request 559 followed by exactly one response. 561 Mesh Service transactions MAY cause modification of the data stored 562 in the Mesh Portal or the Mesh itself but do not cause changes to the 563 connection state. The protocol itself is thus idempotent. There is 564 no set sequence in which operations are required to be performed. It 565 is not necessary to perform a Hello transaction prior to a 566 CreateGroup, AddMember or any other transaction. 568 4.1. Request Messages 570 A Mesh/Recrypt administration Service request consists of a payload 571 object that inherits from the MeshRequest class. When using the HTTP 572 binding, the request MUST specify the portal DNS address in the HTTP 573 Host field. 575 4.1.1. Message: RecryptRequest 577 Base class for all request messages. 579 [None] 581 4.2. Response Messages 583 A Mesh/Recrypt administration Service response consists of a payload 584 object that inherits from the MeshResponse class. When using the 585 HTTP binding, the response SHOULD report the Status response code in 586 the HTTP response message. However the response code returned in the 587 payload object MUST always be considered authoritative. 589 4.2.1. Message: RecryptResponse 591 Base class for all response messages. Contains only the status code 592 and status description fields. 594 [None] 596 4.3. Imported Objects 598 The Recrypt Administration Sercice makes use of JSON objects defined 599 in the JOSE Signatgure and Encryption specifications. 601 4.4. Common classes 603 The following classes are referenced at multiple points in the 604 protocol. 606 4.4.1. Structure: RecryptionGroup 608 Describes a group of recryption users. 610 String (Optional) 612 A user friendly account name in RFC821 format (user@example.com). 614 MemberEntry [0..Many] 616 Member of a recryption group 618 PublicKey [0..Many] 620 The set of past encryption keys associated with the group. 622 PublicKey (Optional) 624 The current group encryption key 626 4.4.2. Structure: MemberEntry 628 Describes a member of a recryption group 630 String (Optional) 632 UDF fingerprint of the user's master profile 634 String (Optional) 636 User friendly account name 638 String [0..Many] 640 A list of privileges assigned to the user. 642 Currently defined privileges are RECRYPT, ADMIN and SUPER. Recrypt 643 grants a user the right to request decryption of data encrypted under 644 the group key. ADMIN grants the right to add or remove users from 645 the group. SUPER grants the right to add or remove administrators 646 and super-administrators from the group. 648 Note that being granted the necessary privilege does not in itself 649 confer the ability to decrypt messages as this requires access to the 650 master private key. 652 String [0..Many] 654 A list of quotas assigned to the user. 656 Each quota is described by the UDF fingerprint of the quota service. 658 String (Optional) 660 Member status. Valid values are ACTIVE, REVOKED and SUSPENDED. 662 Once added to a recryption group, a user can never be 'deleted'. 663 Instead their member record is marked as REVOKED or SUSPENDED which 664 causes the recryption service to refuse further recryption requests. 666 Note that it is entirely valid for newly created recryption group to 667 contain member entries that are inactive. This allows a key 668 administrator to generate key material for group members in 669 anticipation of them requiring access without immediately granting 670 that access. 672 UserDecryptionEntry [0..Many] 674 Identifier of 676 4.4.3. Structure: UserDecryptionEntry 678 Decryption entry for a particular user and group key 680 String (Optional) 682 Fingerprint of the encryption key to which this recryption data 683 corresponds 685 String (Optional) 687 Fingerprint of the user's key 689 String (Optional) 691 A user friendly account name in RFC821 format (user@example.com). 693 PublicKey (Optional) 695 The recryption key to be used to recrypt for this user. 697 JoseWebEncryption (Optional) 699 The user's decryption key encrypted under a one or more encryption 700 keys held by the user. The encrypted content is a PrivateKey 701 structure specifying the decryption key for the user. 703 4.4.4. Structure: CombinedToGroup 705 Glue that maps a combined key identifier (Encryption, Member) to a 706 group and member entry. 708 String (Optional) 710 Fingerprint of the encryption key to which this recryption data 711 corresponds 713 String (Optional) 715 Fingerprint of the user's key 717 String (Optional) 719 UDF fingerprint of the user's master profile 721 String (Optional) 723 A user friendly account name in RFC821 format (user@example.com). 725 4.5. Administrator Transactions 727 4.6. Transaction: Hello 729 Request: HelloRequest 731 Response: HelloResponse 733 Report service and version information. 735 The Hello transaction provides a means of determining which protocol 736 versions, message encodings and transport protocols are supported by 737 the service. 739 4.7. Transaction: CreateGroup 741 Request: CreateGroupRequest 743 Response: CreateGroupResponse 745 Create a new recryption group. 747 4.7.1. Message: CreateGroupRequest 749 o Inherits: RecryptRequest 751 Request creation of a recryption group. The only request parameter 752 describes the group to be created. 754 RecryptionGroup (Optional) 756 The Recryption Group to create 758 4.7.2. Message: CreateGroupResponse 760 o Inherits: RecryptResponse 762 Reports the success or failure of a CreateGroup request. The 763 operation either succeeds or fails, there are no returned parameters 765 [None] 767 4.8. Transaction: UpdateGroup 769 Request: UpdateGroupRequest 771 Response: UpdateGroupResponse 773 Update the information describing a recryption group. 775 4.8.1. Message: UpdateGroupRequest 777 o Inherits: RecryptRequest 779 Request an update to a recryption group. 781 Note that the update process is currently limited to 'strike and 782 replace'. This is likely to become cumbersome if groups with very 783 large numbers of entries are being maintained. It is likely that a 784 future version of the protocol will support update requests that 785 implement commonly occurring tasks such as updates to add a new 786 encryption key, etc. 788 RecryptionGroup (Optional) 790 The Recryption Group to create 792 4.8.2. Message: UpdateGroupResponse 794 o Inherits: RecryptResponse 796 Reports the success or failure of a UpdateGroup request. The 797 operation either succeeds or fails, there are no returned parameters 799 [None] 801 4.9. Transaction: AddMember 803 Request: AddMemberRequest 805 Response: AddMemberResponse 806 Add a member or members to an existing recryption group. 808 4.9.1. Message: AddMemberRequest 810 o Inherits: RecryptRequest 812 String (Optional) 814 The UDF fingerprint of the recryption group to add the member to. 816 MemberEntry [0..Many] 818 Describes the member(s) to add 820 4.9.2. Message: AddMemberResponse 822 o Inherits: RecryptResponse 824 Reports the success or failure of a AddMember request. The operation 825 either succeeds or fails, there are no returned parameters 827 [None] 829 4.10. Transaction: UpdateMember 831 Request: UpdateMemberRequest 833 Response: UpdateMemberResponse 835 Update a one or more member entries 837 This transaction may be used to make member entries inactive by 838 posting REVOKED or SUSPENDED status to their member entry. 840 4.10.1. Message: UpdateMemberRequest 842 o Inherits: RecryptRequest 844 String (Optional) 846 The UDF fingerprint of the recryption group in which the member 847 entries is to be updated 849 MemberEntry [0..Many] 851 Describes the member(s) to add 853 4.10.2. Message: UpdateMemberResponse 855 o Inherits: RecryptResponse 857 Reports the success or failure of a UpdateMember request. The 858 operation either succeeds or fails, there are no returned parameters 860 [None] 862 4.11. Future work 864 At present the protocol does not provide a mechanism for modifying 865 administrator privileges or requesting statistics on use of 866 recryption services. These are obviously important. Whether these 867 should be part of the base protocol or a separate protocol is another 868 matter. 870 5. User Service 872 The only transaction supported by the user facing service at this 873 point is the ability to request a recryption operation. 875 5.1. Transaction: RecryptData 877 Request: RecryptDataRequest 879 Response: RecryptDataResponse 881 Request that the service provide a recryption result for the 882 specified encrypted data and return it encrypted under the user's 883 public key. 885 5.1.1. Message: RecryptDataRequest 887 o Inherits: RecryptRequest 889 Request that the service provide a recryption result for the 890 specified encrypted data and return it encrypted under the user's 891 public key. 893 String (Optional) 895 The recryption group in which the member entries is to be updated 897 Recipient (Optional) 899 The Jose Web Encryption recipient information to be partially 900 decrypted. 902 5.1.2. Message: RecryptDataResponse 904 o Inherits: RecryptResponse 906 JoseWebEncryption (Optional) 908 The partial decryption information to use to complete the decryption 909 encrypted under the user's key. 911 JoseWebEncryption (Optional) 913 The decryption key to use to complete the decryption encrypted under 914 the user's key. 916 6. Acknowledgements 918 7. Implementation Status 920 This section records the status of known implementations of the 921 protocol defined by this specification at the time of posting of this 922 Internet-Draft, and is based on a proposal described in [RFC6982] 923 [RFC6982] . The description of implementations in this section is 924 intended to assist the IETF in its decision processes in progressing 925 drafts to RFCs. Please note that the listing of any individual 926 implementation here does not imply endorsement by the IETF. 927 Furthermore, no effort has been spent to verify the information 928 presented here that was supplied by IETF contributors. This is not 929 intended as, and must not be construed to be, a catalog of available 930 implementations or their features. Readers are advised to note that 931 other implementations may exist. 933 According to [RFC6982] [RFC6982] , "this will allow reviewers and 934 working groups to assign due consideration to documents that have the 935 benefit of running code, which may serve as evidence of valuable 936 experimentation and feedback that have made the implemented protocols 937 more mature. It is up to the individual working groups to use this 938 information as they see fit". 940 7.1. Reference Implementation 942 Organization: Comodo Group Inc. 944 Implementer: Phillip Hallam-Baker 946 Maturity: Experimental Prototype 948 This implementation was used to produce the reference section and all 949 the examples in this document. Since the conversion of specification 950 to code is automatic, there is a high degree of assurance that the 951 reference implementation is consistent with this document. 953 7.1.1. Coverage: 955 The draft-xx branch describes the code used to create version xx of 956 this document. 958 The main current limitations are that the code only supports RSA key 959 pairs and for ease of development the server does not persist keys 960 across sessions. Nor does the implementation currently support the 961 HTTP payload authentication and encryption layer or make use of TLS. 962 These could be easily fixed. 964 The client and server are implemented as libraries that may be called 965 from a multi-protocol server. A standalone server will be provided 966 in a future release. 968 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 969 ASN.1 and TLS Schema implementations are all supported by the code 970 generation tool but not currently implemented as the build tool 971 bindings for those encodings have not yet been finalized or 972 documented. 974 The key restrictions for TLS key exchange have not yet been 975 implemented. 977 The code has only been tested on Windows 10 but passed compatibility 978 testing for both Mono and dotNetCore 10 run times which should in 979 theory permit use on Linux and OSX platforms. 981 7.1.2. Licensing 983 The code is released under an MIT License 985 Source code is available from GitHub at 986 https://github.com/hallambaker/Mathematical-Mesh 988 7.1.3. Implementation Experience 990 The implementation and specification documentation were developed in 991 Visual Studio using the PHB Build Tools suite. 993 7.1.4. Contact Info 995 Contact Phillip Hallam-Baker phill@hallambaker.com 997 8. Security Considerations 999 [This is just a sketch for the present.] 1001 9. IANA Considerations 1003 [TBS list out all the code points that require an IANA registration] 1005 10. References 1007 10.1. Normative References 1009 [Blaze98] "[Reference Not Found!]". 1011 [draft-hallambaker-mesh-architecture] 1012 Hallam-Baker, P., "Mathematical Mesh: Architecture", 1013 draft-hallambaker-mesh-architecture-03 (work in progress), 1014 May 2017. 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, 1018 DOI 10.17487/RFC2119, March 1997. 1020 10.2. Informative References 1022 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1023 Code: The Implementation Status Section", RFC 6982, 1024 DOI 10.17487/RFC6982, July 2013. 1026 Author's Address 1028 Phillip Hallam-Baker 1029 Comodo Group Inc. 1031 Email: philliph@comodo.com