Mesh/Recrypt
draft-hallambaker-mesh-recrypt-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Phillip Hallam-Baker | ||
| Last updated | 2017-05-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hallambaker-mesh-recrypt-01
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 &</ReportTime>
<Description>
Watch-list of known bad IPs or networks
</Description>
<Assessment>
<Impact type="admin" completion="succeeded" />
<Impact type="recon" completion="succeeded" />
</Assessment>
<Contact type="organization" role="creator">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Separate <EventData> is used to convey
different <Expectation> -->
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.53</Address>
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<!-- Expectation class indicating that sender of list would
like to be notified if activity from the host is seen -->
<Expectation action="contact-sender" />
</EventData>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Description>
Source of heavy scanning over past 1-month
</Description>
</System>
</Flow>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.241</Address>
</Node>
<Description>C2 IRC server</Description>
Danyliw & Stoecker Expires August 18, 2014 [Page 91]
Internet-Draft IODEFv2 February 2014
</System>
</Flow>
<!-- Expectation class recommends that these networks
be filtered -->
<Expectation action="block-host" />
</EventData>
</Incident>
</IODEF-Document>
8. The IODEF Schema
<xs:schema targetNamespace="urn:ietf:params:xml:ns:iodef-2.0"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/2002/
REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<xs:annotation>
<xs:documentation>
Incident Object Description Exchange Format v2.0, RFC5070-bis
</xs:documentation>
</xs:annotation>
<!--
==================================================================
== IODEF-Document class ==
==================================================================
-->
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident"
maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version"
type="xs:string" fixed="2.00"/>
<xs:attribute name="lang"
type="xs:language" use=#x27;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]