Network Working Group P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Standards Track May 9, 2017 Expires: November 10, 2017 Mesh/Recrypt draft-hallambaker-mesh-recrypt-01 Abstract Proxy Re-encryption 'recryption' is a form of public key encryption in which decryption requires the use of multiple keys. The Mesh/ Recrypt protocol is an implementation of a recryption scheme that supports use of end-to-end encryption by groups of users whose membership may change over time. The system is implemented using two separate protocols; An administration protocol that allows the creation of recryption groups, adding and removing members and a client protocol that allows an authorized group member request a partial decryption operation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 10, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hallam-Baker Expires November 10, 2017 [Page 1] Internet-Draft Mesh/Recrypt May 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Related Specifications . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Recryption Algorithms . . . . . . . . . . . . . . . . . . 5 2.2. Basic Protocol . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Extended Protocol . . . . . . . . . . . . . . . . . . 7 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Check service connection . . . . . . . . . . . . . . . . 7 3.2. Create and populate a group . . . . . . . . . . . . . . . 8 3.3. Request Recyption . . . . . . . . . . . . . . . . . . . . 9 3.4. Revoke Membership . . . . . . . . . . . . . . . . . . . . 9 3.5. Check service connection . . . . . . . . . . . . . . . . 9 3.6. Create and populate a group . . . . . . . . . . . . . . . 10 3.7. Request Recyption . . . . . . . . . . . . . . . . . . . . 11 3.8. Revoke Membership . . . . . . . . . . . . . . . . . . . . 11 3.9. Check service connection . . . . . . . . . . . . . . . . 12 3.10. Create and populate a group . . . . . . . . . . . . . . . 12 3.11. Request Recyption . . . . . . . . . . . . . . . . . . . . 13 3.12. Revoke Membership . . . . . . . . . . . . . . . . . . . . 14 4. Mesh/Recrypt/Admin Service . . . . . . . . . . . . . . . . . 14 4.1. Request Messages . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Message: RecryptRequest . . . . . . . . . . . . . . . 15 4.2. Response Messages . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Message: RecryptResponse . . . . . . . . . . . . . . 15 4.2.2. Successful Response Codes . . . . . . . . . . . . . . 16 4.2.3. Warning Response Codes . . . . . . . . . . . . . . . 16 4.2.4. Error Response Codes . . . . . . . . . . . . . . . . 17 4.2.5. Failure Response Codes . . . . . . . . . . . . . . . 17 4.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 18 4.4. Common classes . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. Structure: RecryptionGroup . . . . . . . . . . . . . 18 4.4.2. Structure: Member . . . . . . . . . . . . . . . . . . 18 4.4.3. Structure: Version . . . . . . . . . . . . . . . . . 19 4.4.4. Structure: Encoding . . . . . . . . . . . . . . . . . 20 4.4.5. Structure: PublicKey . . . . . . . . . . . . . . . . 20 4.4.6. Structure: MemberEntry . . . . . . . . . . . . . . . 21 4.4.7. Structure: UserDecryptionEntry . . . . . . . . . . . 22 4.5. Administrator Transactions . . . . . . . . . . . . . . . 22 4.6. Transaction: Hello . . . . . . . . . . . . . . . . . . . 22 4.6.1. Message: HelloRequest . . . . . . . . . . . . . . . . 22 Hallam-Baker Expires November 10, 2017 [Page 2] Internet-Draft Mesh/Recrypt May 2017 4.6.2. Message: HelloResponse . . . . . . . . . . . . . . . 23 4.7. Transaction: CreateGroup . . . . . . . . . . . . . . . . 23 4.7.1. Message: CreateGroupRequest . . . . . . . . . . . . . 23 4.7.2. Message: CreateGroupResponse . . . . . . . . . . . . 23 4.8. Transaction: UpdateGroup . . . . . . . . . . . . . . . . 24 4.8.1. Message: UpdateGroupRequest . . . . . . . . . . . . . 24 4.8.2. Message: UpdateGroupResponse . . . . . . . . . . . . 24 4.9. Transaction: AddMember . . . . . . . . . . . . . . . . . 25 4.9.1. Message: AddMemberRequest . . . . . . . . . . . . . . 25 4.9.2. Message: AddMemberResponse . . . . . . . . . . . . . 25 4.10. Transaction: UpdateMember . . . . . . . . . . . . . . . . 25 4.10.1. Message: UpdateMemberRequest . . . . . . . . . . . . 26 4.10.2. Message: UpdateMemberResponse . . . . . . . . . . . 26 4.11. Future work . . . . . . . . . . . . . . . . . . . . . . . 26 5. User Service . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Transaction: RecryptData . . . . . . . . . . . . . . . . 26 5.1.1. Message: RecryptDataRequest . . . . . . . . . . . . . 27 5.1.2. Message: RecryptDataResponse . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 28 6.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Availability . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Normative References . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Definitions 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Related Specifications This protocol is makes use of technology described in the following specifications JSON [RFC7159] For encoding of message data structures. JOSE [RFC7515] [RFC7516] [RFC7518] Formats for cryptographic messages and keys in JSON. JSON Web Service [draft-hallambaker-json-web-service-04] Hallam-Baker Expires November 10, 2017 [Page 3] Internet-Draft Mesh/Recrypt May 2017 Describes the approach used for Web Service discovery and the encapsulation of JSON messages as HTTP payloads with the necessary authentication and encryption services. Uniform Data Fingerprint [draft-hallambaker-udf-05] Describes the mechanism used to create identifiers for cryptographic keypairs from the public key. In addition, the following specifications are closely related but not required for implementation: Transport Layer Security [RFC5246] The use of TLS to protect the confidentiality and integrity of all protocol communications is of course highly recommended. It is however highly undesirable for a cryptographic protocol such as LURK should rely on transport layer security enhancements alone. The Mathematical Mesh [draft-hallambaker-mesh-architecture-03] [draft-hallambaker-mesh-reference-04] MAY be used to establish trust relationships between the parties in the protocol. CFRG Elliptic Curves and Algorithms [RFC7748] The threshold and proxy re-encryption schemes described are likely to be of most interest in conjunction with the emerging elliptic curve based cryptography. JSON-BCD [draft-hallambaker-jsonbcd-06] JSON-B or JSON-C encoding may be used if an efficient binary or compressed encoding is required. Alternatively, message structures MAY be encoded according to TLS conventions. 2. Introduction In traditional public key encryption, one key, the public key is used to encrypt messages and a second key, the private key is used for decryption. While this is sufficient for communication between two parties, it is less satisfactory when a message is to be sent to a group of users. Use of a session key allows a message to be sent to multiple recipients at once, but only if the list of recipients is known to the sender. And unless special processing is performed in the infrastructure, the distribution list is disclosed to all the message recipients. Hallam-Baker Expires November 10, 2017 [Page 4] Internet-Draft Mesh/Recrypt May 2017 The need for more flexible communication patterns has traditionally been supported through the use of key management services. A message encrypted under the public key of the key management service is decrypted on demand and re-encrypted under the public key of an authorized recipient. Again the use of session keys permits this to be performed efficiently (only the session key need be re-encrypted). This approach provides the necessary functionality but the end-to-end protection of confidentiality is lost. The use of proxy re-encryption 'recryption', affords full flexibility without losing end-to-end protection of the encrypted data. As with traditional public key encryption, one public key is used for encryption but instead of using one private key to decrypt, this is split into a pair of decryption keys for each authorized recipient. One of these keys is held by the key server and the other is held by the recipient. Since both private keys are required to complete decryption of the message, neither the key server nor the recipient can decrypt the message without the co-operation of the other. Thus end-to-end confidentiality is preserved even if the ciphertext is disclosed and the key service is entirely compromised. 2.1. Recryption Algorithms Currently three forms of public key encryption algorithm are in widespread use, RSA, Diffie Hellman and Elliptic Curve Diffie- Hellman. In each case, the operation at the heart of the algorithm is a method of calculating some function f^n(x) for some very large value n in some group order p. It follows therefore that if n = a+b mod pand there is an efficient method of calculating f^n(x) from f^a(x) and f^b(x), we can perform a private key operation in two separate stages and then combine the results to obtain f^n(x). In practice, the encryption algorithms of greatest interest at the current time is Elliptic Curve Diffie-Hellman using the curves Ed-25519 and Ed-448. While the Montgomery forms of these curves for encryption is widely established, existing implementations do not provide the primitives required to implement a recryption form of the algorithm directly. Equivalent Edwards curves were defined because the same limitation also hinders implementation of digital signatures. Since this code provides the cryptographic primitives we need for recryption, it makes sense to use them for both purposes. 2.2. Basic Protocol The basic Mesh/Recrypt protocol has three parties: Administrator Hallam-Baker Expires November 10, 2017 [Page 5] Internet-Draft Mesh/Recrypt May 2017 The initial generator of the encryption keypair associated with the group and the holder of the corresponding private key. The administrator has the ability to add users to the group and the authority to remove them. Service The recryption key service responds to administration requests from the authorized administrator(s) and recryption requests from members of the recryption group(s) it manages. Member A member of at least one recryption group. All group members have at least one personal decryption key. Note that the use of recryption does not change the encryption process at all, except to the extent that the party encrypting the message MUST support use of the algorithm specified by the recryption key. Thus a message sender or a creator of an encrypted document is not a party to the Mesh/Recrypt protocol. To create a recryption group, the administrator first creates a public encryption keypair and publishes the public key. She then uses the private key to create a recryption keypair for each of the initial members of the group and publishes these to the key server. Note that the private key for the recryption group is held by the administrator and is never revealed to the key service. In applications requiring a high level of security, this private key may be stored on a smartcart or other form of Hardware Security Module (HSM). The administrator client creates a recryption entry for each member and publishes it to the key service. This recryption entry contains: The UDF fingerprint of the user's mesh profile The recryption key for the user User decryption entry containing the corresponding decryption key encrypted under the public encryption key of the user. Storing the decryption key information at the keyserver avoids the need to communicate any information to the user during group administration operations. The administrator may add or remove group members at any time. Note however that while the key server cannot add members to a group, the Hallam-Baker Expires November 10, 2017 [Page 6] Internet-Draft Mesh/Recrypt May 2017 ability to permanently delete members from the group relies on the key service permanently erasing the information in the recryption entry. To decrypt a message, a group member reads the recryption data provided and determines which Mesh/Recrypt service to contact. The member then submits a recryption request specifying the UDF of their mesh profile. If a recryption entry exists for the specified key and the member is authorized to decrypt that message, the recryption service generates a partial recryption result and returns it together with the user decryption entry. The member then decrypts the private key in the decryption entry, uses it to obtain a second partial decryption result and combines the two partial results to obtain the decryption key. 2.2.1. Extended Protocol The basic protocol may be extended in several ways: Support for multiple encryption keys within a group to prevent collusion between the key server and former group members after a key rollover event occurs. Distinguishing between Administrators authorized to add and remove users and Super-Administrators with the ability to add and remove Administrators. Specify quotas to restrict the amount of data members may decrypt. Enforce separation of duties in the administration function through key splitting. Use of linked notary logs, aka Blockchain techniques. 3. Architecture 3.1. Check service connection It is often useful to be able to verify that a service is ready and willing to perform transactions before attempting to perform one. Especially so when the transaction requires considerable amounts of data and may require the use of specific server determined authentication options. The request message is 'HelloRequest' and has no parameters: Hallam-Baker Expires November 10, 2017 [Page 7] Internet-Draft Mesh/Recrypt May 2017 POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} The response message specifies the protocol version(s) supported, the corresponding encodings and bindings: HTTP/1.1 200 OK Date: Tue 09 May 2017 05:18:53 Content-Length: 157 { "HelloResponse": { "Status": 201, "StatusDescription": "Operation completed successfully", "Version": { "Major": 0, "Minor": 1}}} 3.2. Create and populate a group The request message is 'CreateGroupRequest' and specifies the initial data to be used to populate the group. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} The response message returns success or the reason for failure HTTP/1.1 200 OK Date: Tue 09 May 2017 05:18:53 Content-Length: 157 { "HelloResponse": { "Status": 201, "StatusDescription": "Operation completed successfully", "Version": { "Major": 0, "Minor": 1}}} Hallam-Baker Expires November 10, 2017 [Page 8] Internet-Draft Mesh/Recrypt May 2017 3.3. Request Recyption The request message is 'RecryptDataRequest' POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} If the request is successful, the response 'RecryptDataResponse' is returned containing the necessary partial decryption data and user decryption entry 3.4. Revoke Membership The request message is 'UpdateMemberRequest'. This specifies which member record in which group is to be updated and the new data to populate the entry. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} The response message returns success or the reason for failure 3.5. Check service connection It is often useful to be able to verify that a service is ready and willing to perform transactions before attempting to perform one. Especially so when the transaction requires considerable amounts of data and may require the use of specific server determined authentication options. The request message is 'HelloRequest' and has no parameters: POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} Hallam-Baker Expires November 10, 2017 [Page 9] Internet-Draft Mesh/Recrypt May 2017 The response message specifies the protocol version(s) supported, the corresponding encodings and bindings: HTTP/1.1 200 OK Date: Tue 09 May 2017 05:38:35 Content-Length: 157 { "HelloResponse": { "Status": 201, "StatusDescription": "Operation completed successfully", "Version": { "Major": 0, "Minor": 1}}} 3.6. Create and populate a group The first step in creating a recryption group is to create at least one public key encryption keypair. Note that a recryption group should be specified as some form of Mesh profile. Whether this should be an application profile or a personal profile is not yet clear. This part of the protocol is likely to change before deployment. Alice creates the recryption group and creates member entries for herself and Bob. [[TBS: Need to add profiles for Alice and Bob at some point. This needs thought.] The request message is 'CreateGroupRequest' and specifies the initial data to be used to populate the group. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 29 { "CreateGroupRequest": {}} The response message returns success or the reason for failure Hallam-Baker Expires November 10, 2017 [Page 10] Internet-Draft Mesh/Recrypt May 2017 HTTP/1.1 200 OK Date: Tue 09 May 2017 05:38:35 Content-Length: 109 { "CreateGroupResponse": { "Status": 201, "StatusDescription": "Operation completed successfully"}} 3.7. Request Recyption To test the new group, Alice encrypts a message under the group public key and sends it to Bob. Bob receives the test message from Alice. To decrypt the message, Bob's client requests the corresponding partial recryption information from the key server. The request message is 'RecryptDataRequest'. It specifies the Recipient data from the encrypted message and Bob's recryption key identifier for that particular key service. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 29 { "RecryptDataRequest": {}} If the request is successful, the response 'RecryptDataResponse' is returned containing the necessary partial decryption data and user decryption entry 3.8. Revoke Membership Bob leaves the company and Alice revokes the access to the recryption group that she granted earlier. Note that this will not stop Bob from reading material that he has already decrypted, it will only prevent him decrypting new material. Nor will this prevent the use of the key material that was issued to Bob being used to decrypt messages should the key service be breached. The request message is 'UpdateMemberRequest'. This specifies which member record in which group is to be updated and the new data to populate the entry. Hallam-Baker Expires November 10, 2017 [Page 11] Internet-Draft Mesh/Recrypt May 2017 POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 30 { "UpdateMemberRequest": {}} The response message returns success or the reason for failure 3.9. Check service connection It is often useful to be able to verify that a service is ready and willing to perform transactions before attempting to perform one. Especially so when the transaction requires considerable amounts of data and may require the use of specific server determined authentication options. The request message is 'HelloRequest' and has no parameters: POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 23 { "HelloRequest": {}} The response message specifies the protocol version(s) supported, the corresponding encodings and bindings: HTTP/1.1 200 OK Date: Tue 09 May 2017 05:42:32 Content-Length: 157 { "HelloResponse": { "Status": 201, "StatusDescription": "Operation completed successfully", "Version": { "Major": 0, "Minor": 1}}} 3.10. Create and populate a group The first step in creating a recryption group is to create at least one public key encryption keypair. Note that a recryption group should be specified as some form of Mesh profile. Whether this should be an application profile or a personal Hallam-Baker Expires November 10, 2017 [Page 12] Internet-Draft Mesh/Recrypt May 2017 profile is not yet clear. This part of the protocol is likely to change before deployment. Alice creates the recryption group and creates member entries for herself and Bob. [[TBS: Need to add profiles for Alice and Bob at some point. This needs thought.] The request message is 'CreateGroupRequest' and specifies the initial data to be used to populate the group. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 29 { "CreateGroupRequest": {}} The response message returns success or the reason for failure HTTP/1.1 200 OK Date: Tue 09 May 2017 05:42:32 Content-Length: 109 { "CreateGroupResponse": { "Status": 201, "StatusDescription": "Operation completed successfully"}} 3.11. Request Recyption To test the new group, Alice encrypts a message under the group public key and sends it to Bob. Bob receives the test message from Alice. To decrypt the message, Bob's client requests the corresponding partial recryption information from the key server. The request message is 'RecryptDataRequest'. It specifies the Recipient data from the encrypted message and Bob's recryption key identifier for that particular key service. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 29 { "RecryptDataRequest": {}} Hallam-Baker Expires November 10, 2017 [Page 13] Internet-Draft Mesh/Recrypt May 2017 If the request is successful, the response 'RecryptDataResponse' is returned containing the necessary partial decryption data and user decryption entry 3.12. Revoke Membership Bob leaves the company and Alice revokes the access to the recryption group that she granted earlier. Note that this will not stop Bob from reading material that he has already decrypted, it will only prevent him decrypting new material. Nor will this prevent the use of the key material that was issued to Bob being used to decrypt messages should the key service be breached. The request message is 'UpdateMemberRequest'. This specifies which member record in which group is to be updated and the new data to populate the entry. POST /.well-known/recrypt/HTTP/1.1 Host: prismproof.org Content-Length: 30 { "UpdateMemberRequest": {}} The response message returns success or the reason for failure 4. Mesh/Recrypt/Admin Service The Mesh/Recrypt administration service supports transactions to Add and Delete members from a group and to list all the members in a group. SRV Prefix: _recrypt._tcp HTTP Well Known Service Prefix: /.well-known/recrypt Every Recrypt Service transaction consists of exactly one request followed by exactly one response. Hallam-Baker Expires November 10, 2017 [Page 14] Internet-Draft Mesh/Recrypt May 2017 Mesh Service transactions MAY cause modification of the data stored in the Mesh Portal or the Mesh itself but do not cause changes to the connection state. The protocol itself is thus idempotent. There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to a CreateGroup, AddMember or any other transaction. 4.1. Request Messages A Mesh/Recrypt administration Service request consists of a payload object that inherits from the MeshRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field. 4.1.1. Message: RecryptRequest Base class for all request messages. Portal: String (Optional) Name of the Mesh/Recrypt administration Service to which the request is directed. 4.2. Response Messages A Mesh/Recrypt administration Service response consists of a payload object that inherits from the MeshResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative. 4.2.1. Message: RecryptResponse Base class for all response messages. Contains only the status code and status description fields. A service MAY return either the response message specified for that transaction or any parent of that message. Thus the RecryptResponse message MAY be returned in response to any request. Status: Integer (Optional) Status return code. The SMTP/HTTP scheme of 2xx = Success, 3xx = incomplete, 4xx = failure is followed. Hallam-Baker Expires November 10, 2017 [Page 15] Internet-Draft Mesh/Recrypt May 2017 StatusDescription: String (Optional) Text description of the status return code for debugging and log file use. 4.2.2. Successful Response Codes The following response codes are returned when a transaction has completed successfully. [201] SuccessOK Operation completed successfully [201] SuccessCreated Operation completed successfully, new data item created [202] SuccessUpdated Operation completed successfully, data item was updated 4.2.3. Warning Response Codes The following response codes are returned when a transaction did not complete because the target service has been redirected. In the case that a redirect code is returned, the StatusDescription field contains the URI of the new service. Note however that the redirect location indicated in a status response might be incorrect or even malicious and cannot be considered trustworthy without appropriate authentication. [303] RedirectPermanent Service has been permanently moved [307] RedirectTemporary Hallam-Baker Expires November 10, 2017 [Page 16] Internet-Draft Mesh/Recrypt May 2017 Service has been temporarily moved 4.2.4. Error Response Codes A response code in the range 400-499 is returned when the service was able to process the transaction but the transaction resulted in an error. [401] ClientUnauthorized Client is not authorized to perform specified request [404] NotFound The requested object could not be found. [409] AlreadyExists The requested object already exists. 4.2.5. Failure Response Codes A response code in the range 500-599 is returned when the service was unable to process the transaction but the transaction due to an internal failure. [500] ServerInternal An internal error occurred at the server [503] ServerOverload The server cannot handle the request as it is overloaded Hallam-Baker Expires November 10, 2017 [Page 17] Internet-Draft Mesh/Recrypt May 2017 4.3. Imported Objects The Recrypt Administration Sercice makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications. 4.4. Common classes The following classes are referenced at multiple points in the protocol. 4.4.1. Structure: RecryptionGroup Describes a group of recryption users. Name: String (Optional) A user friendly account name in RFC821 format (user@example.com). Members: Member [0..Many] Member of a recryption group ArchivedKeys: PublicKey (Optional) The set of past encryption keys associated with the group. 4.4.2. Structure: Member Describes a member of a recryption group UDF: String (Optional) UDF fingerprint of the user's master profile Privileges: String [0..Many] A list of privileges assigned to the user. Hallam-Baker Expires November 10, 2017 [Page 18] Internet-Draft Mesh/Recrypt May 2017 Currently defined privileges are RECRYPT, ADMIN and SUPER. Recrypt grants a user the right to request decryption of data encrypted under the group key. ADMIN grants the right to add or remove users from the group. SUPER grants the right to add or remove administrators and super-administrators from the group. Note that being granted the necessary privilege does not in itself confer the ability to decrypt messages as this requires access to the master private key. Quotas: String [0..Many] A list of quotas assigned to the user. Each quota is described by the UDF fingerprint of the quota service. 4.4.3. Structure: Version Describes a protocol version. Major: Integer (Optional) Major version number of the service protocol. A higher Minor: Integer (Optional) Minor version number of the service protocol. Encodings: Encoding [0..Many] Enumerates alternative encodings (e.g. ASN.1, XML, JSON-B) supported by the service. If no encodings are specified, the JSON encoding is assumed. URI: String [0..Many] Hallam-Baker Expires November 10, 2017 [Page 19] Internet-Draft Mesh/Recrypt May 2017 The preferred URI for this service. This MAY be used to effect a redirect in the case that a service moves. 4.4.4. Structure: Encoding Describes a message content encoding. ID: String [0..Many] The IANA encoding name Dictionary: String [0..Many] For encodings that employ a named dictionary for tag or data compression, the name of the dictionary as defined by that encoding scheme. 4.4.5. Structure: PublicKey The PublicKey class is used to describe public key pairs and trust assertions associated with a public key. Note that this class is also defined in the Mesh protocol libraries. It being clearly desirable that both protocols share a common specification of the PublicKey class, these classes will be merged at some future point. Mosty likely the best way to do this would be to define this element in a separate specification describing the Jose encryption wrapper. UDF: String (Optional) UDF fingerprint of the public key parameters/ X509Certificate: Binary (Optional) List of X.509 Certificates X509Chain: Binary [0..Many] Hallam-Baker Expires November 10, 2017 [Page 20] Internet-Draft Mesh/Recrypt May 2017 X.509 Certificate chain. X509CSR: Binary (Optional) X.509 Certificate Signing Request. 4.4.6. Structure: MemberEntry Name: String (Optional) User friendly account name UDF: String (Optional) Fingerprint of the user's Mesh profile Status: String (Optional) Member status. Valid values are ACTIVE, REVOKED and SUSPENDED. Once added to a recryption group, a user can never be 'deleted'. Instead their member record is marked as REVOKED or SUSPENDED which causes the recryption service to refuse further recryption requests. Note that it is entirely valid for newly created recryption group to contain member entries that are inactive. This allows a key administrator to generate key material for group members in anticipation of them requiring access without immediately granting that access. UserDecryptionEntries: UserDecryptionEntry [0..Many] The User Decryption Entries for this user for one particular encryption key. This entry is a list since the user may be authorized to decrypt the information on more than one device. Hallam-Baker Expires November 10, 2017 [Page 21] Internet-Draft Mesh/Recrypt May 2017 4.4.7. Structure: UserDecryptionEntry UDF: String (Optional) Fingerprint of the encryption key to which this recryption data corresponds RecryptionKey: Key (Optional) The recryption key to be used to recrypt for this user. DecryptionKey: JoseWebEncryption (Optional) The user's decryption key encrypted under a one or more encryption keys held by the user. The encrypted content is a PrivateKey structure specifying the decryption key for the user. 4.5. Administrator Transactions 4.6. Transaction: Hello Request: HelloRequest Response:HelloResponse Report service and version information. The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service. 4.6.1. Message: HelloRequest o * Inherits: RecryptRequest Request service description. [None] Hallam-Baker Expires November 10, 2017 [Page 22] Internet-Draft Mesh/Recrypt May 2017 4.6.2. Message: HelloResponse Always reports success. Describes the configuration of the service. o * Inherits: RecryptResponse Version: Version (Optional) Enumerates the protocol versions supported Alternates: Version [0..Many] Enumerates alternate protocol version(s) supported 4.7. Transaction: CreateGroup Request: CreateGroupRequest Response:CreateGroupResponse Create a new recryption group. 4.7.1. Message: CreateGroupRequest o * Inherits: RecryptRequest Request creation of a recryption group. The only request parameter describes the group to be created. RecryptionGroup: RecryptionGroup (Optional) The Recryption Group to create 4.7.2. Message: CreateGroupResponse o * Inherits: RecryptResponse Hallam-Baker Expires November 10, 2017 [Page 23] Internet-Draft Mesh/Recrypt May 2017 Reports the success or failure of a CreateGroup request. The operation either succeeds or fails, there are no returned parameters [None] 4.8. Transaction: UpdateGroup Request: UpdateGroupRequest Response:UpdateGroupResponse Update the information describing a recryption group. 4.8.1. Message: UpdateGroupRequest o * Inherits: RecryptRequest Request an update to a recryption group. Note that the update process is currently limited to 'strike and replace'. This is likely to become cumbersome if groups with very large numbers of entries are being maintained. It is likely that a future version of the protocol will support update requests that implement commonly occurring tasks such as updates to add a new encryption key, etc. RecryptionGroup: RecryptionGroup (Optional) The Recryption Group to create 4.8.2. Message: UpdateGroupResponse o * Inherits: RecryptResponse Reports the success or failure of a UpdateGroup request. The operation either succeeds or fails, there are no returned parameters [None] Hallam-Baker Expires November 10, 2017 [Page 24] Internet-Draft Mesh/Recrypt May 2017 4.9. Transaction: AddMember Request: AddMemberRequest Response:AddMemberResponse Add a member or members to an existing recryption group. 4.9.1. Message: AddMemberRequest o * Inherits: RecryptRequest RecryptionGroup: String (Optional) The UDF fingerprint of the recryption group to add the member to. MemberEntry: MemberEntry [0..Many] Describes the member(s) to add 4.9.2. Message: AddMemberResponse o * Inherits: RecryptResponse Reports the success or failure of a AddMember request. The operation either succeeds or fails, there are no returned parameters [None] 4.10. Transaction: UpdateMember Request: UpdateMemberRequest Response:UpdateMemberResponse Update a one or more member entries This transaction may be used to make member entries inactive by posting REVOKED or SUSPENDED status to their member entry. Hallam-Baker Expires November 10, 2017 [Page 25] Internet-Draft Mesh/Recrypt May 2017 4.10.1. Message: UpdateMemberRequest o * Inherits: RecryptRequest RecryptionGroup: String (Optional) The UDF fingerprint of the recryption group in which the member entries is to be updated MemberEntry: MemberEntry [0..Many] Describes the member(s) to add 4.10.2. Message: UpdateMemberResponse o * Inherits: RecryptResponse Reports the success or failure of a UpdateMember request. The operation either succeeds or fails, there are no returned parameters [None] 4.11. Future work At present the protocol does not provide a mechanism for modifying administrator privileges or requesting statistics on use of recryption services. These are obviously important. Whether these should be part of the base protocol or a separate protocol is another matter. 5. User Service The only transaction supported by the user facing service at this point is the ability to request a recryption operation. 5.1. Transaction: RecryptData Request: RecryptDataRequest Response:RecryptDataResponse Hallam-Baker Expires November 10, 2017 [Page 26] Internet-Draft Mesh/Recrypt May 2017 Request that the service provide a recryption result for the specified encrypted data and return it encrypted under the user's public key. 5.1.1. Message: RecryptDataRequest o * Inherits: RecryptRequest Request that the service provide a recryption result for the specified encrypted data and return it encrypted under the user's public key. RecryptionGroup: String (Optional) The recryption group in which the member entries is to be updated Recipient: Recipient (Optional) The Jose Web Encryption recipient information to be partially decrypted. 5.1.2. Message: RecryptDataResponse o * Inherits: RecryptResponse Partial: JoseWebEncryption (Optional) The partial decryption information to use to complete the decryption encrypted under the user's key. UserDecryptionEntry: JoseWebEncryption (Optional) The decryption key to use to complete the decryption encrypted under the user's key. Hallam-Baker Expires November 10, 2017 [Page 27] Internet-Draft Mesh/Recrypt May 2017 6. Security Considerations 6.1. Confidentiality The use of recryption techniques provides a limited form of end-to- end protection of confidentiality. Specifically, a message encrypted under the group encryption key cannot be decrypted by an unauthorized party unless either the encryption algorithm is broken or there is collusion between the key service and at least one party whose authorization has been either deleted or suspended. Mesh/Recrypt messages may reveal information through traffic analysis. Thus all Mesh/Recrypt messages SHOULD be protected using TLS in addition to the authentication and encryption services afforded by the service binding. 6.2. Integrity The Mesh/Recrypt protocol does not provide data integrity services. In applications where an audit trail of which parties requested access or were granted access to material is required, the Mesh/ Recrypt service MAY require all transaction messages to be digitally signed to provide non-repudiation. Further integrity protections MAY be afforded by enrolling messages in a linked notary log. 6.3. Availability Access to data encrypted under a recryption group will be impaired if the key service is unavailable. Use of fault tolerant approaches to service implementation SHOULD be considered in cases where high availability is required. 7. Acknowledgements Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin Alden. 8. Normative References [draft-hallambaker-json-web-service-04] "[Reference Not Found!]". [draft-hallambaker-jsonbcd-06] "[Reference Not Found!]". [draft-hallambaker-mesh-architecture-03] "[Reference Not Found!]". Hallam-Baker Expires November 10, 2017 [Page 28] Internet-Draft Mesh/Recrypt May 2017 [draft-hallambaker-mesh-reference-04] "[Reference Not Found!]". [draft-hallambaker-udf-05] "[Reference Not Found!]". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016. Author's Address Phillip Hallam-BakerPhillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires November 10, 2017 [Page 29]