| 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
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.
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 (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 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.
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].
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]
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.
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.
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.
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.
The basic Mesh/Recrypt protocol has three parties:
Administrator
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 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.
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.
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:18:53
Content-Length: 157
{
"HelloResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Version": {
"Major": 0,
"Minor": 1}}}
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}}}
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
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
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:38:35
Content-Length: 157
{
"HelloResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Version": {
"Major": 0,
"Minor": 1}}}
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
HTTP/1.1 200 OK
Date: Tue 09 May 2017 05:38:35
Content-Length: 109
{
"CreateGroupResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
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
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
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}}}
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
HTTP/1.1 200 OK
Date: Tue 09 May 2017 05:42:32
Content-Length: 109
{
"CreateGroupResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
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
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
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:
HTTP Well Known Service Prefix:
Every Recrypt Service transaction consists of exactly one request followed by exactly one response.
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.
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.
Base class for all request messages.
Portal: String (Optional)
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.
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)
StatusDescription: String (Optional)
The following response codes are returned when a transaction has completed successfully.
[201] SuccessOK
[201] SuccessCreated
[202] SuccessUpdated
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
[307] RedirectTemporary
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
[404] NotFound
[409] AlreadyExists
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
[503] ServerOverload
The Recrypt Administration Sercice makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications.
The following classes are referenced at multiple points in the protocol.
Describes a group of recryption users.
Name: String (Optional)
Members: Member [0..Many]
ArchivedKeys: PublicKey (Optional)
Describes a member of a recryption group
UDF: String (Optional)
Privileges: String [0..Many]
Quotas: String [0..Many]
Describes a protocol version.
Major: Integer (Optional)
Minor: Integer (Optional)
Encodings: Encoding [0..Many]
URI: String [0..Many]
Describes a message content encoding.
ID: String [0..Many]
Dictionary: String [0..Many]
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)
X509Certificate: Binary (Optional)
X509Chain: Binary [0..Many]
X509CSR: Binary (Optional)
Name: String (Optional)
UDF: String (Optional)
Status: String (Optional)
UserDecryptionEntries: UserDecryptionEntry [0..Many]
UDF: String (Optional)
RecryptionKey: Key (Optional)
DecryptionKey: JoseWebEncryption (Optional)
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.
Request service description.
[None]
Always reports success. Describes the configuration of the service.
Version: Version (Optional)
Alternates: Version [0..Many]
Request: CreateGroupRequest
Response:CreateGroupResponse
Create a new recryption group.
Request creation of a recryption group. The only request parameter describes the group to be created.
RecryptionGroup: RecryptionGroup (Optional)
Reports the success or failure of a CreateGroup request. The operation either succeeds or fails, there are no returned parameters
[None]
Request: UpdateGroupRequest
Response:UpdateGroupResponse
Update the information describing a recryption group.
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)
Reports the success or failure of a UpdateGroup request. The operation either succeeds or fails, there are no returned parameters
[None]
Request: AddMemberRequest
Response:AddMemberResponse
Add a member or members to an existing recryption group.
RecryptionGroup: String (Optional)
MemberEntry: MemberEntry [0..Many]
Reports the success or failure of a AddMember request. The operation either succeeds or fails, there are no returned parameters
[None]
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.
RecryptionGroup: String (Optional)
MemberEntry: MemberEntry [0..Many]
Reports the success or failure of a UpdateMember request. The operation either succeeds or fails, there are no returned parameters
[None]
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.
The only transaction supported by the user facing service at this point is the ability to request a recryption operation.
Request: RecryptDataRequest
Response:RecryptDataResponse
Request that the service provide a recryption result for the specified encrypted data and return it encrypted under the user's public key.
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)
Recipient: Recipient (Optional)
Partial: JoseWebEncryption (Optional)
UserDecryptionEntry: JoseWebEncryption (Optional)
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.
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.
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.
Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin Alden.
| [draft-hallambaker-json-web-service-04] | , , "[Reference Not Found!]" |
| [draft-hallambaker-jsonbcd-06] | , , "[Reference Not Found!]" |
| [draft-hallambaker-mesh-architecture-03] | , , "[Reference Not Found!]" |
| [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. |