Internet-Draft Mesh/Recrypt November 2017
Hallam-Baker Expires May 13, 2018 [Page]
Stream:
Independent Submission
Series:
Internet-Draft
Status:
Informational
Published:
Expires
Authors:
Phillip Hallam-Baker (Comodo Group Inc.)

Mesh/Recrypt: Usable Confidentiality
draft-hallambaker-mesh-recrypt-03

Abstract

A messaging infrastructure providing full end-to end security is presented. Unlike existing approaches such as S/MIME and OpenPGP, Mesh/Recrypt uses proxy re-encryption to preserve full end-to-end security with individual user and device keys in situations such as the user having multiple decryption devices and messages being set to mailing lists.

This document shows the use of Mesh/Recrypt to address the principle use cases Mesh/Recrypt is designed to address. These include asynchronous messaging such as mail and controlled documents and synchronous messaging applications such as chat, voice and video.

This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-recrypt.html.

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 May 13, 2018

Table of Contents

1. Introduction

Traditional messaging security infrastructures are difficult to configure, difficult to use and limited to one mode of communication. Digital certificates are hard to obtain and harder to maintain. Managing a Web of Trust requires a very high level of user competence. S/MIME and OpenPGP offer end-to-end email security but not streaming services such as video, voice or chat.

In recent years a number of proprietary chat systems have been extended to the point that a single application and protocol supports chat, voice, video and asynchronous communication modes such as messaging and file transfer. While such systems typically claim to offer cryptographic security, the extent to which this is achieved is difficult to determine. Even systems purporting to offer ‘end-to-end’ security have proved to be woefully inadequate when it is discovered that one of the ‘ends’ referred to is in fact the messaging infrastructure operated by the provider.

A key limitation of all the deployed messaging systems that were reviewed in the development of this paper is that true end-to-end confidentiality is only achieved for a limited set of communication patterns. Specifically, bilateral communications (Alice sends a message to Bob) or broadcast communications to a known set of recipients (Alice sends a message to Bob, Carol and Doug). These capabilities do not support communication patterns where the set of recipients changes over time or is confidential. Yet such requirements commonly occur in situations such as sending a message to a mailing list whose membership isn’t known to the sender, or creating a spreadsheet whose readership is to be limited to authorized members of the ‘accounting’ team.

Figure 1 : Traditional End-to-End Encryption is static.

Mesh/Recrypt is an experimental messaging infrastructure that applies proxy re-encryption to support all the commonly used messaging modes with strong end-to-end encryption. The primary purpose of Mesh/Recrypt is to demonstrate the advantages of using the proxy re-encryption technique and to determine the feasibility of retrofitting such capabilities to legacy protocols such as SMTP, IMAP and XMPP.

Figure 2 : Mesh Recrypt supports End-to-End Encryption in dynamic groups.

Whether the advantages of building on an established base outweigh those of a clean slate approach for purposes of deployment are currently unknown, but there are clear advantages of using a clean slate approach for purposes of exposition.

As the name suggests, Mesh/Recrypt makes use of the Mathematical Mesh infrastructure for management of user keys. For clarity and convenience, this document describes the application of Mesh/Recrypt to a completely new protocol suite. Strategies for adding similar capabilities to existing specifications are discussed as possible future work.

2. Definitions

This section presents the related specifications and standards on which Mesh/Recrypt is built, the terms that are used as terms of art within the documents and the terms used as requirements language.

2.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].

2.2. Defined Terms

The following terms are used as terms of art in this document with the meaning specified below:

Confidential Document Control (CDC)
An Access Control mechanism that uses cryptography to control read access to static content (typically documents) within its control.
Controlled Document
Content that is subject to control of a CDC system.
Proxy Re-Encryption
A cryptography mechanism that permits a party that does not have the ability to decrypt an encrypted message to transform it into a message that can be decrypted under a different private key than the original.
Recryption
The term ‘recryption’ is used as a synonym for Proxy Re-Encryption in this document.
Recryption Key
A cryptographic key that is used to enable a different party to decrypt an encrypted message that does not grant decryption capability.

The related specifications used in the Mesh/Recrypt protocol are described in the Mesh Architecture specification [draft-hallambaker-mesh-architecture]

2.4. Implementation Status

The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].

3. Proxy Re-Encryption

Proxy re-encryption provides a technical capability that meets the needs of such communication patterns. Conventional symmetric key cryptography uses a single key to encrypt and decrypt data. Public key cryptography uses two keys, the key used to encrypt data is separate from the key used to decrypt. Proxy re-encryption introduces a third key (the recryption key) that allows a party to permit an encrypted data packet to be decrypted using a different key without permitting the data to be decrypted.

The introduction of a recryption key permits end-to-end confidentiality to be preserved when a communication pattern requires that some part of the communication be supported by a service.

The introduction of a third type of key, the recryption key permits two new roles to be established, that of an administrator and recryption service. There are thus four parties:

Administrator
Holder of Decryption Key, Creator of Recryption Keys
Sender
Holder of Encryption Key
Recryption Service
Holder of Recryption keys
Receiver
Holder of personal decryption key

The communication between these parties is shown in Figure X below:

Figure 7 : Mesh/Recrypt Parties

The chief advantage of recryption is that the recryption service does not have the ability to decrypt messages and does not need to be trusted at the same level as a recipient. A recryption service may be implemented as a cloud service on an untrusted host or managed in house by a system administrator who is only partially trusted.

3.1. Proxy Re-Encryption Algorithms

Proxy Re-Encryption was introduced by Blaze et. al. [Blaze98] in 1998. In this paper, we make use of the Diffie Hellman based mechanism described in this paper. While this approach does not have capabilities such as reversibility or transitivity offered in later work, such features do not appear to offer any practical advantages in developing protocols for the intended applications and may well introduce significant disadvantages.

The use of the Diffie Hellman based approach has the considerable advantages of being compatible with the recently developed CFRG Elliptic Curve algorithms and being minimally unencumbered by IPR claims.

Recall that in the Diffie Hellman key agreement algorithm, shared parameters e and p are generated, these being an exponent value (e) and a modulus value (p). To create a shared key, two parties (Alice and Bob) generate private keys a, b being positive integers in the interval [2 ... p-1]. The corresponding public keys are then ea mod p and eb mod p. Thus, knowledge of either {eb mod p, a} or {ea mod p, b} is sufficient to calculate the shared secret value s = eab mod p.

Figure 3 : Traditional Diffie-Hellman

When applying Diffie Hellman to a messaging protocol, it is typically desirable to ensure that a unique shared value is created for each exchange. If the protocol only requires authentication of the receiver, the sender may ensure that each shared value is unique by generating a new key pair {t, et mod p} for each exchange. Alternatively, mutual authentication may be preserved if the shared secret is formed from three values s = eabt mod p, where a and b are the validated public keys of the sender and receiver and t is a temporary key generated by the sender that has a nonce-like function.

To adapt Diffie Hellman to a recryption mechanism, we note that just as the value s = ebt mod p may be calculated as either (eb mod p)t mod p or (et mod p)b mod p, it can also be calculated as ((et mod p)b-x mod p . (et mod p)x mod p) mod p. This equivalence is used to create the recryption protocol.

Figure XX shows Bob calculating the shared secret with the aid of a Recryption service. Bob's private key for decryption is now x and the Recryption service has the corresponding recryption key b-x. The recryption service can provide Bob with the additional information needed to decrypt the message but cannot decrypt the message itself.

Figure 4 : Diffie-Hellman with Recryption

Applying this approach to Proxy Re-Encryption directly is unacceptable since the administrator of the recryption group must know Bob's private key. To avoid this problem, the administrator generates a new public key pair for each member of the group and encrypts the decryption portion under the public key of the member.

In the following example, Alice is the administrator of the recryption group and Bob and Carol are recipients.

Bob
Generates a public key encryption pair (b, B). The algorithm used for this does not matter, as the only functions used are encryption and decryption.
Bob publishes his public key B.
Alice (Administrator)
Generates public key pair {a, ea mod p}.
Publishes the public key value for the recryption group ea mod p
To enable Bob to receive messages, Alice generates a recryption keypair for Bob {a-bx, bx } and encrypts the decryption key (bx) using Bob’s public key (pubB) to create a recryption entry for Bob {a- bx, E(bx, pubB)}.
The recryption entry is sent to the recryption service.

At this point Alice, Bob and the Recryption Service have the information they need to receive encrypted messages (figure X).

Figure 5 : Mesh/Recrypt Administration Protocol

Having established the necessary keying material, Carol (or any other party who knows the recryption group encryption key) can encrypt a message:

Carol (Sender)
Generates a temporary key pair {t, et mod p} and uses this and the public key of the recryption group (ea mod p) to create a shared secret s = eat mod p that is used to encrypt the message.
Sends the encrypted message and temporary public key (et mod p) to the recryption service
Recryption Service
Receives the message and retrieves the list of intended recipients, this currently has just a single entry for Bob {a-bx, E(bx, B)}
Calculates (et mod p)a-bx mod p = eta-tbx mod p
Sends the encrypted message, the original temporary public key generated by Carol (et mod p), the recryption value eta-tbx mod p and the encrypted decryption key E(bx, B) to Bob.
Bob
Receives the message
Decrypts the E(bx, B) using his private key b to obtain bx
Uses bx and et mod p to calculate etbx mod p
Calculates (eta-tbx mod p. etbx mod p) mod p = eta mod p = s
Uses s to decrypt the message

This protocol is illustrated in figure X:

Figure 6 : Mesh/Recrypt Decryption Protocol

Note that Alice is not a participant in the recryption protocol. Administrator actions are only required when adding or removing recipients to the recryption group.

Alice can add additional recipients to the group at any time by creating a recryption pair, encrypting the decryption key under the new user's public key and sending the information to the recryption service, just like she did for Bob.

Alice can remove a user from the recryption group by telling the recryption service to no longer recrypt messages to the removed user’s recryption key. This requires the recryption service to be trusted not to forward messages to the deleted user. To restore the untrusted status of the recryption service it is necessary for the administrator to create a new encryption key and a full set of recryption keys for the continuing users.

One major limitation in the trust model of the recryption scheme described is that while it is not possible for either the recryption service or individual recipients to decrypt arbitrary messages the recryption service and a recipient may do so if they collude. This particular limitation in the trust model is an inescapable consequence of the fact that the function of the recryption service is to enable a recipient to decrypt a message and cannot be avoided without introducing additional parties. This limitation is not considered to be a serious limitation for the intended application.

3.2. Applying Mesh/Recrypt

This document describes the Mesh/Recrypt algorithm and protocol. To make use of the capability it provides, it is necessary to make use of it in an application protocol. Mesh/Recrypt MAY be used in any application that supports data level encryption. This includes mailing lists, conferencing systems offering voice or chat and confidential document control.

3.3. Mailing Lists

One of the earliest uses proposed for recryption is to support end-to-end security for a confidential mailing list in which the membership of the list is not disclosed to its members. In this application, the mail server is a recryption service and trusted to maintain the confidentiality of the mailing list membership but not the messages themselves. This offers many advantages over existing approaches:

To apply recryption to a mailing list server, a recryption keyset is created for each mailing list managed by the server and the administrator responsible for maintaining the membership of the list is also the administrator of the corresponding recryption key set.

3.4. Chat rooms and other streaming data.

The application of recryption to a chat room application is similar to the mailing list application except that the administrator may be either an offline party as before or a participant in the conversation. In the latter case, the protocol should permit the administrator to pass their role to another participant should they need to leave.

One major constraint on the use of recryption to support streamed audio or video is that since the messaging service cannot decrypt the data stream, it can hardly be expected to perform transcoding services such as producing lower resolution versions of a video stream to support participants with low bandwidth connections. Either all the participants must receive the exact same data feed or transcoding services must be provided by a trusted party granted access by the administrator.

3.5. Confidential Document Control

Confidential Document Control (CDC) uses cryptography to enforce access control. Unlike Digital Rights Management and related technologies, CDC only provides a means to permit or deny access to confidential data while it is under protection. A CDC infrastructure does not attempt to control the use made of that data by an authorized recipient, in particular, a CDC infrastructure does not necessarily prevent redistribution of data by a party permitted to read it.

The application of recryption to CDC maps naturally to the use of ‘security labels’ to control access to confidential documents in government and military applications. Each security label (e.g. secret#example.com) has an associated recryption key set. The administrator of the recryption key set is responsible for managing the parties authorized to read documents controlled under that label.

Recryption may be used to support the use of multiple labels. Combining appropriate cryptographic operations permits a document author to require recipients to be granted access for all the labels specified or for any of the labels specified. For example, the designation (Accounting#example.com + Executive#example.com) might indicate that a recipient must be a member of the Accounting and Executive teams while the designation (Accounting#example.com | Executive#example.com) would enable members of either team to read the material.

While the recryption algorithm used in Mesh/Recrypt allows the use of conjunctions and disjunctions to implement the equivalent of an ACL entry granting access, it is not possible to implement the equivalent of an ACL entry denying access to a group of users. The recryption service can be instructed to refuse recryption to a group of users but this restriction is not cryptographically enforced.

Since users must request a recryption key from the recryption service for each document accessed, the recryption service is a Policy Control Point and is thus potentially a point at which additional accountability and/or access controls may be introduced. An enterprise recryption service might maintain a log of all access requests from users and restrict access to users whose requests exceed some form of quota. Attempts to access particularly sensitive documents might raise flags requiring review by a supervisor.

3.6. Multiple Devices

When the S/MIME and OpenPGP email encryption schemes were developed in the 1990s the machines of the day, if movable at all were ‘portable’ rather than ‘mobile’. Contemporary users demand access to their communications applications from a wide variety of devices including desktops, laptops, tablets, phones and even watches. The need for a single user to access their email on multiple devices is now the norm rather than the exception.

Use of multiple devices and in particular mobile devices introduces obvious security concerns. A device may be lost or stolen; a machine may be sold without destroying data stored on it. Such circumstances very frequently result in disclosure of private keys to an attacker. Maintaining separate private keys on each device allows the consequences of such loss to be mitigated and further compromise prevented.

To apply recryption to this use case, the email recipient establishes a personal recryption keyset on a machine that they consider at least risk of compromise. A separate recryption key entry is then created for each device and the recryption keyset uploaded to a suitable recryption server host (e.g. the presence service of a chat application, inbound mail server, etc.)

One difficulty that arises in this approach is that while a non-transitive recryption mechanism can be applied in either a sender side context such as a mailing list or a receiver side context such as supporting multiple devices, enabling the use of both at the same time requires additional effort.

4. Using Recryption

Use of recryption is essentially the same as the use of public key encryption with the proviso that instead of one private key being sufficient to decrypt the message, two are required. For the sake of convenience, these are refered to as the recryption key (held by the key service) and the decryption key (held by the end user).

4.1. Creating a Recryption Group

A recryption group consists of

To create a recryption group with the recryption tool, Alice enters:

recrypt create recrypt@example.com alice@example.com

A recryption group is created and registered to the Key service. A new public key pair is generated for the group. The list of user entries consists of an entry for Alice as the administrator of the group. Although Alice has custody of the corresponding decryption key and can decrypt messages without the use of the recryption service, she might not want to provision this key to every one of her devices. So she creates a recryption user entry for herself.

The client requests creation of the recryption group at the key service. The request is authenticated under an authentication key connected to Alice's account for use in recryption:

POST /.well-known/recrypt/HTTP/1.1
Host: example.com
Content-Length: 12521

{
  "CreateGroupRequest": {
    "RecryptionGroup": {
      "GroupName": "recrypt@example.com",
      "Master": {
        "Identifier": "MBWMZ-A7GMP-GFSEZ-I5RRR-NZ3G2-I2VCN",
        "MasterSignatureKey": {
          "UDF": "MBWMZ-A7GMP-GFSEZ-I5RRR-NZ3G2-I2VCN",
          "X509Certificate": "
MIIFXDCCBESgAwIBAgIQUfJWmPiBlYNuRt3tjZn60jANBgkqhkiG9w0BAQ0FADAu
MSwwKgYDVQQDFiNNQldNWi1BN0dNUC1HRlNFWi1JNVJSUi1OWjNHMi1JMlZDTjAe
Fw0xNzExMDgxMjAwMDFaFw0zNzExMjQwMjQ4MDdaMC4xLDAqBgNVBAMWI01CV01a
LUE3R01QLUdGU0VaLUk1UlJSLU5aM0cyLUkyVkNOMIIBIDANBgkqhkiG9w0BAQEF
AAMPADCCAQoCggEBAKD48F46wI_i6gmkmlpQg97kyrK4wyLbz-5lqObb7XwN2lfx
Qqz4X3gLVpHuQaQiQa9R2y4nfViO3CDzexuRWBQRAhcgJS-jphvk_IK6qRcI-rXl
PF_yp4mW9Ja7Exd0gD0-xp8_UB84HzroRRlvaRqPYMtntjt4B2xgubdbY73zHgXQ
1Qef45nCw4BahnZlWa-xtl19H-LVb8Yy-8wqC_kTtvVt2jskGP4N9wevo5QYOWDr
FOM-F3uB7bt3T5P8ZR7mprXyYVFusSzxnwpKsvPLzgloRLzsN79NdEh7c2KR7S1k
gHEmSY1I1brHN3YB_Si4VIEGspmpiWdLGPfWRRUCAwEAAaOCAnYwggJyMIIBNwYD
VR0jBIIBLjCCASqAggEmMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
oPjwXjrAj-LqCaSaWlCD3uTKsrjDItvP7mWo5tvtfA3aV_FCrPhfeAtWke5BpCJB
r1HbLid9WI7cIPN7G5FYFBECFyAlL6OmG-T8grqpFwj6teU8X_KniZb0lrsTF3SA
PT7Gnz9QHzgfOuhFGW9pGo9gy2e2O3gHbGC5t1tjvfMeBdDVB5_jmcLDgFqGdmVZ
r7G2XX0f4tVvxjL7zCoL-RO29W3aOyQY_g33B6-jlBg5YOsU4z4Xe4Htu3dPk_xl
HuamtfJhUW6xLPGfCkqy88vOCWhEvOw3v010SHtzYpHtLWSAcSZJjUjVusc3dgH9
KLhUgQaymamJZ0sY99ZFFQIDAQABMIIBMwYDVR0OBIIBKgSCASYwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg-PBeOsCP4uoJpJpaUIPe5MqyuMMi28_u
Zajm2-18DdpX8UKs-F94C1aR7kGkIkGvUdsuJ31Yjtwg83sbkVgUEQIXICUvo6Yb
5PyCuqkXCPq15Txf8qeJlvSWuxMXdIA9PsafP1AfOB866EUZb2kaj2DLZ7Y7eAds
YLm3W2O98x4F0NUHn-OZwsOAWoZ2ZVmvsbZdfR_i1W_GMvvMKgv5E7b1bdo7JBj-
DfcHr6OUGDlg6xTjPhd7ge27d0-T_GUe5qa18mFRbrEs8Z8KSrLzy84JaES87De_
TXRIe3Nike0tZIBxJkmNSNW6xzd2Af0ouFSBBrKZqYlnSxj31kUVAgMBAAEwDQYJ
KoZIhvcNAQENBQADggEBAAwyqi3PvVb2BO9DTsshgOcCOx8KuAfVxds77Kbl6g1P
dm84Bs3eM8BCchLAPomkza2xYawR1kSFVjXO0lqA6Bu2BumIJ6IIRc3c08fiVv74
pLYQ7BYDKtsmkAHtY16wAYgYU1LucpoEOHd9QcImj4RGnQte6Bbwn_VIPp2lmcfY
ihCPUggSZsWAjMPe5B51RsjAr6eQUR0WLdB0Vn4XYj9JCjXGqBDCqyEseV78_Dp3
46pDwOhHVIDoZvE1nnS4XkuTu9kg8AnauPZKcnu6doN_gUwpfnsAXywzeqNINwBk
mHGvIQB3Z3O5Fc9cgrHMSAJ3Su-Qo9rPCvm02-6A1NM",
          "PublicParameters": {
            "PublicKeyRSA": {
              "kid": "MBWMZ-A7GMP-GFSEZ-I5RRR-NZ3G2-I2VCN",
              "n": "
oPjwXjrAj-LqCaSaWlCD3uTKsrjDItvP7mWo5tvtfA3aV_FCrPhfeAtWke5BpCJB
r1HbLid9WI7cIPN7G5FYFBECFyAlL6OmG-T8grqpFwj6teU8X_KniZb0lrsTF3SA
PT7Gnz9QHzgfOuhFGW9pGo9gy2e2O3gHbGC5t1tjvfMeBdDVB5_jmcLDgFqGdmVZ
r7G2XX0f4tVvxjL7zCoL-RO29W3aOyQY_g33B6-jlBg5YOsU4z4Xe4Htu3dPk_xl
HuamtfJhUW6xLPGfCkqy88vOCWhEvOw3v010SHtzYpHtLWSAcSZJjUjVusc3dgH9
KLhUgQaymamJZ0sY99ZFFQ",
              "e": "
AQAB"}}},
        "MasterEscrowKeys": [{
            "UDF": "MAEYW-XMUJP-IWIPX-NND45-YHVRG-JMPUJ",
            "X509Certificate": "
MIIFXTCCBEWgAwIBAgIRAIfXe_wa1-2TDxAIWj6rB_UwDQYJKoZIhvcNAQENBQAw
LjEsMCoGA1UEAxYjTUJXTVotQTdHTVAtR0ZTRVotSTVSUlItTlozRzItSTJWQ04w
HhcNMTcxMTA4MTIwMDAxWhcNMzcxMTI0MDI0ODA4WjAuMSwwKgYDVQQDFiNNQUVZ
Vy1YTVVKUC1JV0lQWC1OTkQ0NS1ZSFZSRy1KTVBVSjCCASAwDQYJKoZIhvcNAQEB
BQADDwAwggEKAoIBAQCtzWGkbAIOQ9G3KcAG9RVpm_18_RxSd0wq2D3IFI0wK9Vu
c0_WXfheQSgQBJT_UAMpx7m46hVzqtxO8iXMW_UPbuimQaOI-iQqcbXna7aBeGmR
-zf_i_SQF0JVCZEwuxgln-keMCUlhZh4PWHVIX7EGv_5JaL6a3jPuGU33riVyrsB
u1N7Li-L4FmlvP6zkpe0u6joH9YKader7DuKmByS7nRBLDO5BSfZ7aWyVqQZfMvw
BOKykCxSFwdmsfZUac6VQNBDL2p11AXdlqnrK5j7VGR-smaLrdOfXZMs0FNVnYc6
bcouh-LcA1kpk_szvbYoT06rCVXNpHYfSovBjcNpAgMBAAGjggJ2MIICcjCCATcG
A1UdIwSCAS4wggEqgIIBJjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKD48F46wI_i6gmkmlpQg97kyrK4wyLbz-5lqObb7XwN2lfxQqz4X3gLVpHuQaQi
Qa9R2y4nfViO3CDzexuRWBQRAhcgJS-jphvk_IK6qRcI-rXlPF_yp4mW9Ja7Exd0
gD0-xp8_UB84HzroRRlvaRqPYMtntjt4B2xgubdbY73zHgXQ1Qef45nCw4BahnZl
Wa-xtl19H-LVb8Yy-8wqC_kTtvVt2jskGP4N9wevo5QYOWDrFOM-F3uB7bt3T5P8
ZR7mprXyYVFusSzxnwpKsvPLzgloRLzsN79NdEh7c2KR7S1kgHEmSY1I1brHN3YB
_Si4VIEGspmpiWdLGPfWRRUCAwEAATCCATMGA1UdDgSCASoEggEmMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArc1hpGwCDkPRtynABvUVaZv9fP0cUndM
Ktg9yBSNMCvVbnNP1l34XkEoEASU_1ADKce5uOoVc6rcTvIlzFv1D27opkGjiPok
KnG152u2gXhpkfs3_4v0kBdCVQmRMLsYJZ_pHjAlJYWYeD1h1SF-xBr_-SWi-mt4
z7hlN964lcq7AbtTey4vi-BZpbz-s5KXtLuo6B_WCmnXq-w7ipgcku50QSwzuQUn
2e2lslakGXzL8ATispAsUhcHZrH2VGnOlUDQQy9qddQF3Zap6yuY-1RkfrJmi63T
n12TLNBTVZ2HOm3KLofi3ANZKZP7M722KE9OqwlVzaR2H0qLwY3DaQIDAQABMA0G
CSqGSIb3DQEBDQUAA4IBAQB9o8-ib11GUwMrv0dbyMg0onhdx4Z_ZcGV5ptInNwt
0bXN9eqMcVZ6MnSv79Cg2bfvSd_FbAHnV-Zd3pUQOl-iid7lM_XzkjkSMqHqErnT
E1k-jWR_zglJKqmxfIZpMuXs2MrxbsUve8ijtRhD5eaP58wAX7ERTHOjvttq0VPV
Z92cGaNV7tvKwj2SVHu9y0rSXbLpkAToJEpM1vFmHB-li7_Xhla3VCHYcdkwDAaG
Xv40yjIO6XtaGDmzfCem6h26igqub9lG4VfZ3u5ebIVWoj8CKsVzAt3QZ7TLWZ5P
dOieRUHei2j3zpKibSoP5sZzFBKOkQTVNZ9gPVk05obe",
            "PublicParameters": {
              "PublicKeyRSA": {
                "kid": "MAEYW-XMUJP-IWIPX-NND45-YHVRG-JMPUJ",
                "n": "
rc1hpGwCDkPRtynABvUVaZv9fP0cUndMKtg9yBSNMCvVbnNP1l34XkEoEASU_1AD
Kce5uOoVc6rcTvIlzFv1D27opkGjiPokKnG152u2gXhpkfs3_4v0kBdCVQmRMLsY
JZ_pHjAlJYWYeD1h1SF-xBr_-SWi-mt4z7hlN964lcq7AbtTey4vi-BZpbz-s5KX
tLuo6B_WCmnXq-w7ipgcku50QSwzuQUn2e2lslakGXzL8ATispAsUhcHZrH2VGnO
lUDQQy9qddQF3Zap6yuY-1RkfrJmi63Tn12TLNBTVZ2HOm3KLofi3ANZKZP7M722
KE9OqwlVzaR2H0qLwY3DaQ",
                "e": "
AQAB"}}}],
        "OnlineSignatureKeys": [{
            "UDF": "MD2WG-JIM5J-MUEEL-RMKZB-2HLLZ-CBPSN",
            "X509Certificate": "
MIIFXTCCBEWgAwIBAgIRAJe48flw5DPuc1RNnhud4LYwDQYJKoZIhvcNAQENBQAw
LjEsMCoGA1UEAxYjTUJXTVotQTdHTVAtR0ZTRVotSTVSUlItTlozRzItSTJWQ04w
HhcNMTcxMTA4MTIwMDAxWhcNMzcxMTI0MDI0ODA4WjAuMSwwKgYDVQQDFiNNRDJX
Ry1KSU01Si1NVUVFTC1STUtaQi0ySExMWi1DQlBTTjCCASAwDQYJKoZIhvcNAQEB
BQADDwAwggEKAoIBAQDBEHyKY5_uENZVEagHv0oYDss_K2mfz5aKeF0gEkeies4Y
vEDIALLxnTXGbf3jX9EtjQa9ZqDCwvARmqVsiowigrKb7dqbJ_qCgKkYV9wIYo8p
XE-d_jrHlLIH0CXBKIrDq5MV1rY50wKxchiJI0Wdp1ETbA-aVopv13qOR8B-X_sl
ZP_ECsj8RVMX4tRFDrogFy3Cv-Fu7dVuaK-WNXtDTvwG6KcGYS25UUXxqp1l5Grb
732DO9wc8iC9kXCfVRU5AcGnKy4uaWIMmC710sFb7-krx8MTWE-Fd3sAdPEoAcHh
UWOi2nRD1ACne9E11cKateWlgzVnsdYUo5L9LFOhAgMBAAGjggJ2MIICcjCCATcG
A1UdIwSCAS4wggEqgIIBJjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKD48F46wI_i6gmkmlpQg97kyrK4wyLbz-5lqObb7XwN2lfxQqz4X3gLVpHuQaQi
Qa9R2y4nfViO3CDzexuRWBQRAhcgJS-jphvk_IK6qRcI-rXlPF_yp4mW9Ja7Exd0
gD0-xp8_UB84HzroRRlvaRqPYMtntjt4B2xgubdbY73zHgXQ1Qef45nCw4BahnZl
Wa-xtl19H-LVb8Yy-8wqC_kTtvVt2jskGP4N9wevo5QYOWDrFOM-F3uB7bt3T5P8
ZR7mprXyYVFusSzxnwpKsvPLzgloRLzsN79NdEh7c2KR7S1kgHEmSY1I1brHN3YB
_Si4VIEGspmpiWdLGPfWRRUCAwEAATCCATMGA1UdDgSCASoEggEmMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwRB8imOf7hDWVRGoB79KGA7LPytpn8-W
inhdIBJHonrOGLxAyACy8Z01xm3941_RLY0GvWagwsLwEZqlbIqMIoKym-3amyf6
goCpGFfcCGKPKVxPnf46x5SyB9AlwSiKw6uTFda2OdMCsXIYiSNFnadRE2wPmlaK
b9d6jkfAfl_7JWT_xArI_EVTF-LURQ66IBctwr_hbu3VbmivljV7Q078BuinBmEt
uVFF8aqdZeRq2-99gzvcHPIgvZFwn1UVOQHBpysuLmliDJgu9dLBW-_pK8fDE1hP
hXd7AHTxKAHB4VFjotp0Q9QAp3vRNdXCmrXlpYM1Z7HWFKOS_SxToQIDAQABMA0G
CSqGSIb3DQEBDQUAA4IBAQCdIZjvziLtxSlevxnBs4y7uieSD35YXiVxYBraIo6q
a31IZXsgBSQcyrLUcl8ENkbD3HMHbT6yjDqml_0exWqQ45DkehgwP-e0VduP5IYv
GHTCIRPF7GzI61ajm6DiRM5xw-GKkqeYS9y3q-JwPyuT673Wf-86L0hNftdsid38
M7rhe1ILqINigR0pdd5LIcRO3roqiVNxOO1Maz9_xKh1Pa05_ZNv-3Z2_UQOl2WG
M35QY3jZcqbkEA34IWDcfJrZ4t04pD-MUWfvfcaDz8g0Qe7sgQJmuTQI47UmgSmq
ipMeggBhSm3GxwkzoYi-YyTdmCHcRczo5DznvKVhWuT-",
            "PublicParameters": {
              "PublicKeyRSA": {
                "kid": "MD2WG-JIM5J-MUEEL-RMKZB-2HLLZ-CBPSN",
                "n": "
wRB8imOf7hDWVRGoB79KGA7LPytpn8-WinhdIBJHonrOGLxAyACy8Z01xm3941_R
LY0GvWagwsLwEZqlbIqMIoKym-3amyf6goCpGFfcCGKPKVxPnf46x5SyB9AlwSiK
w6uTFda2OdMCsXIYiSNFnadRE2wPmlaKb9d6jkfAfl_7JWT_xArI_EVTF-LURQ66
IBctwr_hbu3VbmivljV7Q078BuinBmEtuVFF8aqdZeRq2-99gzvcHPIgvZFwn1UV
OQHBpysuLmliDJgu9dLBW-_pK8fDE1hPhXd7AHTxKAHB4VFjotp0Q9QAp3vRNdXC
mrXlpYM1Z7HWFKOS_SxToQ",
                "e": "
AQAB"}}}]},
      "Members": [{
          "UDF": "MAGNR-IB6EU-AEGSN-LYRGP-FTKB4-FRW53",
          "RecryptUDF": "RDXBT-Q3NEW-ERHRA-V5RBB-VIS2P-RB36K",
          "Status": "Active",
          "Entries": [{
              "EncryptionKeyUDF": "MAKT6-DHL2R-XL4GQ-FIRW6-4DLMD-3U4LQ",
              "MemberKeyUDF": "MCEL2-KO3TO-KV645-DTLIN-PEONH-7YERD",
              "RecryptionKey": {
                "PrivateKeyDH": {
                  "kid": "MBBSK-AOB3X-GZXD3-IADJW-GCRYW-WK5CD",
                  "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
                  "Public": "
mCCQganzKJN-QqCVmasTP7GxWVzd2orNVSgoXTAqw57suMY90-Xs6LtEBqbkSrwj
XodOcF-rD1Dte2UuR5wUcHVBVfL2mnIFJKQHRj97OUgcAZaToQIQLB8dmpN9aPSb
jX4WF0dOrgIAqlVvOzA0O38K6WDGpLxV6EqwpQHmPv3GWPz935GcAwJq_NNwKlGo
QII5nPo7thNv7g-8t4--YPJpeHl1BOqV7P6biSciUN7pxwjazqFbj_cZSOPIjfPz
3a88v46HffcCDQf4d37A-TPeHTSGQBLyNfTx78pge_DJLNxNqoIpGZMZaFx7rDSC
Jck7WLWC93GD64GuojvUDA",
                  "Private": "
hB7LUdh3AP_jWVJ1GwgkHVwSpcBY_oek3KiTA2XwQoBMHiH1EgioGfeMKKn_k-uq
AqqEP_FTe2Bmyk4AL3uISTgAmj5lUXaP8IpiXoGjwr7u5IIJUL746ZKvf6JyTQce
x5YeiNvq7XHY4exHbAqu345VFA8yyWcccNlwCYJ-abVG14BjpcbZJq1P-2QTOAZ9
gh8h67dtj5NzJldUiJCVMCgX6Y-vyhwkwXNJy5JwAC-7n2q97vhgZnqk9hVzaj5M
1Mj-i8DQVZlZeQQ7GY7bEMJGA5RDGVvT0QxkcIHd1L4wQZdIfE5OMQvzOfJSs4Mz
12hhX2mPDpoZLQEUoOSQlQA"}},
              "DecryptionKey": {
                "protected": "
ewogICJlbmMiOiAiQTI1NkNCQyJ9",
                "iv": "
s0zYech-noDw6ClRUvDl9Q",
                "recipients": [{
                    "Header": {
                      "alg": "RSA-OAEP",
                      "kid": "MCEL2-KO3TO-KV645-DTLIN-PEONH-7YERD"},
                    "encrypted_key": "
VWHtVi2ATWVE1mIx9tqtPnqtX1oaadTzAJfWR8DfgckCFw3l_mOKpaRFzifk0ftq
3UxwUGirKTV3bjqEaQ2jQzTy17Knqu8-m5vkq8qpF4chRuTinLMwwfa6Wx8wBUfA
R7rGD2RFppyoBnlJXmmmmk39PCmzTBWp_F4XoT26GGY50Cb6D7qYk2I-7sUQP4_A
Vr88dq7eJSjb4Ceenv6-iRo7upNXANWLN8QDDjFOyzXKN0xbPPnGN1iOTU_cAw-x
5CzjD3VivfhjAAEMjcA55R0rRLzmVgwJT69vPixXRt_YOpfsz8_xCZEI1mgKfwqY
BaFJgG_w6ODMa-x2mh9GxA"}],
                "ciphertext": "
ZzO-hBIfY_Uazk-mWSD3coRXSIyx57nPQNy0Orhh5oYv7smgoBbLxStRisTQI9g5
xvUeqhxvuSjmocJMw8o2twGpRerwhx3a9Jj-WS7mHT_UOma7jx9xcqc-IlpVmgXR
HY9IEGkFVYbTCK7eMHxcZ6QfNV8NVkdWZh6tcDu0sNRwZDZcGz--jEadGKOWGwnD
C-WDiwsCuJPs_9PA0eFCFKhc4xOzIG3PAVJNIyH6NxVac5MTQ_tlEY5TCy-0wQSS
tsr33YTqBfWgDylRoBOWyq2tUoxQBCh_8z068GwQiBkvSWZVhTcbR3t29fyrn-lI
QIijq18-2fwPlbJZdxIVZqEKHaKxx4EwBm49eJza8ScJ8r0EdNO4ZrQ2yvN2VhqL
2pZ6s3WI10stq7Ocw1kNwUDCqBXQ0Jy3S09phVM8jaKHwWt-6-kuOTpkaH3dFObp
xu805u8OTXvV2CebKGdhFe4qcapLOHk9x88aWN2A-sdvP9xcrh7j_XYMGkFCxbh2
fXdGwBjYaJ9CGKBvZFA-Qo_oFVAZa33Ea72rUaoVSiJ7yxJSJYcteK857NFOYu0C
kkudinlaSqPSE6joitPBPszcHzP2dss8U3MBvCOfPj64WSvZt6IVHNHuCF6WjC4y
yfdc27pWL0S9c3Zgh8yEg4Lr3b_PTVrPfS2EFC-KAzx601uDwZl3pgmiwiB126dT
-NB6qyuqTfEScHmhPjfSEh-x3wE33Pmx0qbL-Lso19KW1j0DpLLiNwq1P1dT6qZ-
fZKWoFHoDcVbXjb11iPIWdUnhSIOH8NAlTwop1vECDWS4VEW245BbB8Z-vl139Br
zc49xVX-4BobHaLmO_atzAWZE-FofYAG8dYK7R3jkZ-JdrefHFCo3Ph7kG7RRKUD
SPdOFEh1z6o0DbDXKeOhQOd2DqAp0oB_ORGA8ZBfZGfknpGVlWZ0C4fTDJLjevws
l2UV-Mmdtz8cp56Ep_8C0mhJdOe7NtQNN3ZcuwLblbi9TzfJLmfqFYgNiYNTKRGV
Ix0YatxNB8wg_SUosBbuL4Nw5V1d5hF0xmb0NpTiZrLrn-Rr1PBkSG7fhCYfMm4J
O2FSvATFNW5N5A3f3gn-mvlSxG8kNRBiUzrYQZhwhC5156NCjjwxLIJcWpHvDrNZ"}}]}],
      "CurrentEncryptionKey": {
        "unprotected": {
          "dig": "S512"},
        "payload": "
ewogICJSZWNyeXB0aW9uS2V5IjogewogICAgIkVuY3J5cHRpb25LZXkiOiB7CiAg
ICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlESCI6
IHsKICAgICAgICAgICJraWQiOiAiTUFLVDYtREhMMlItWEw0R1EtRklSVzYtNERM
TUQtM1U0TFEiLAogICAgICAgICAgIkRvbWFpbiI6ICIKWUU2Ym5xMU1sWDVvamFK
dG82UExQX1BFd0EiLAogICAgICAgICAgIlB1YmxpYyI6ICIKc2UtX25GaHI3RlVZ
YkxXcWpxZG1vaHh6SXF6aUEwcGlVUXFRMDVzQ0J2N0VJdElMMXRtOHZOekZmQUZr
V08wNgpBYm8weThybXdyaHphWkV4ZWwybnBZdUt4QnlxbllmWjVfNFdsa3FFWk9B
bzJLUWVqMXpEcEhzZWVENTZrYVNJCmlBS3dEMmNDcTZwYUpKbG9ObUZTTnJLRFlv
SHlRUHBpazcwNm5WelpMbGZCMjVocU9yQTZHOGZmYUg3WGFTd3AKYUhIY293anZG
eUl3MlhEMzFHV0RrdWpUSk9sZ3hrNS1UQW1PVm9aSkxVTkJoRHZlVk5iRFozQlhw
bzMtTU5YVAp6SEMzd0ZGWVVJR1l1WGpNUHhjdFBJTHQ3UkkycHpwSkcwQ0k1WUEx
N1c1OWx4enkwOG1WSlJ2STEwbmtNajdNClJIUndXVnBiWE56SEppdy1iUjBvZ1FB
In19fX19",
        "signatures": [{
            "header": {
              "kid": "MD2WG-JIM5J-MUEEL-RMKZB-2HLLZ-CBPSN"},
            "protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjlXdTk2Szk4WnRacFJYTjdE
LVN6QktLZzlWNC04SERFdlZrUmJyTm5xY2JlZjd4d0dYblVMcXhKODZpTGMzM0cK
d3BsSlhlMXg2Y2txOGxMWnVwQnhlQSJ9",
            "signature": "
GU0MN3b29e-e_7F7CyugT2dEEN3nrunqaLWj7e1AKHyGSEzWwr84wFKBTnm_maOi
ykTFcmtUCC0CnjwJlseoJyo4hxfywH1FxWGmvBw5J4BnVa_RXseM7rLAuCwIj3gH
MJhZfOz_MVUAVp2zqvqS6bH_tLoS5dmhTM2SzkZvs8pzZEfU0PxSXl9_qkJVEIIH
DrDqK3SbRZknFlOvEX7n2IwhYmRXrBJZ9IVum0_mkG7RHOQQb2E53pvs9ngr-Xya
dslrhpWNd_AyQ9vbwH3mGBG9RaFUTArm6UqZ2D-yxUeH3jMegPikExK4JIUnhZ9x
9Uu7wG86uturHB14H-81wA"}]}}}}

The service authenticates the request, determines if Alice is authorized to create new recryption groups and if these are satisfactory creates the group entry, returns the result of the transaction:

HTTP/1.1 200 OK
Date: Thu 09 Nov 2017 02:48:09
Content-Length: 109

{
  "CreateGroupResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully"}}

4.2. Encrypting files

At this point, anyone who knows the recryption key can start sending encrypted messages.

To encrypt a test message, Bob enters:

recrypt encrypt recrypt@example.com /in=file1.txt

The plaintext file, file1.txt contains the following text.

This is a test

The UTF representation of the text is:

The client feteches the encryption key from the service:

POST /.well-known/recrypt/HTTP/1.1
Host: example.com
Content-Length: 61

{
  "GetKeyRequest": {
    "GroupID": "recrypt@example.com"}}

The service responds with the key:

HTTP/1.1 200 OK
Date: Thu 09 Nov 2017 02:48:10
Content-Length: 1009

{
  "GetKeyResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully",
    "SignedKey": {
      "unprotected": {
        "dig": "S512"},
      "payload": "
ewogICJSZWNyeXB0aW9uS2V5IjogewogICAgIkVuY3J5cHRpb25LZXkiOiB7CiAg
ICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlESCI6
...
In19fX19"
,
      "signatures": [{
          "header": {
            "kid": "MD2WG-JIM5J-MUEEL-RMKZB-2HLLZ-CBPSN"},
          "protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjlXdTk2Szk4WnRacFJYTjdE
LVN6QktLZzlWNC04SERFdlZrUmJyTm5xY2JlZjd4d0dYblVMcXhKODZpTGMzM0cK
d3BsSlhlMXg2Y2txOGxMWnVwQnhlQSJ9"
,
          "signature": "
GU0MN3b29e-e_7F7CyugT2dEEN3nrunqaLWj7e1AKHyGSEzWwr84wFKBTnm_maOi
ykTFcmtUCC0CnjwJlseoJyo4hxfywH1FxWGmvBw5J4BnVa_RXseM7rLAuCwIj3gH
MJhZfOz_MVUAVp2zqvqS6bH_tLoS5dmhTM2SzkZvs8pzZEfU0PxSXl9_qkJVEIIH
DrDqK3SbRZknFlOvEX7n2IwhYmRXrBJZ9IVum0_mkG7RHOQQb2E53pvs9ngr-Xya
dslrhpWNd_AyQ9vbwH3mGBG9RaFUTArm6UqZ2D-yxUeH3jMegPikExK4JIUnhZ9x
9Uu7wG86uturHB14H-81wA"
}]}}}

The encryption key is used to encrypt the data:

{
  "protected": "
ewogICJlbmMiOiAiQTI1NkNCQyJ9",
  "iv": "
XCHNrAaG2G3DRXm8wXsQ4Q",
  "recipients": [{
      "Header": {
        "alg": "DH",
        "kid": "recrypt@example.com.mm--masq6-i75dd-wl3na-mwps2-vpiir-3w4u2",
        "epk": {
          "PublicKeyDH": {
            "kid": "MDZYK-XHSK3-RFLQB-UBOIX-AVXKX-SWASA",
            "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
            "Public": "
1Tk2BJDPP_wAaxjCjVx3tg3kCkSDtftxsTbdtfd_55J6mhnU5WTLvgEiMeuu5ffb
nb29lKEJneP4Fy5Lewu-v6M50IEWJ46QXMfgUhojF16fV-IyqCOMo4uLh-fquCve
CeYFQR5sJUT1pgqKMvF_d6s1IUsHbhu6YMI6TP3tgOT30e2JatW1pyyhG9jqnlke
IzrCwM01s0gY_RwdLRivcRIkIgIN3HT99R9DNj42z-8VabkVvEUuRtQdRf4VwBRI
x32MdpXSMq63hZsLlNTNOko_qwgDqPws20CzkqahkLikw-xh1IkYSp8PrNtxQnoh
L4bWPc7Ps_7TlUCJcLlA-QA"}}},
      "encrypted_key": "
tr3PlqXZv_i8MfvxZqKFbdKCL13Lk65ripdivcgWU1VWgdtMHoRpSw"}],
  "ciphertext": "
XXQoLExvW-CYNZGuJhuyVe-ByMGUdQiyTLuMXUz5jtc"}

Here, an ephemeral key has been generated to encrypt the data against the public group key. An ephemeral key MAY be used to establish a shared secret used to encrypt multiple pieces of data.

4.3. Adding users to a recryption group

Alice can add members to the group at any time. To add Mallet, she uses the commands:

recrypt add recrypt@example.com mallet@example.com

This creates a recryption entry for Mallet which is pushed to the service:

POST /.well-known/recrypt/HTTP/1.1
Host: example.com
Content-Length: 63

{
  "GetGroupRequest": {
    "GroupID": "recrypt@example.com"}}

Mallet can now decrypt the message Bob sent before he was added to the group.

4.4. Decrypting files

To decrypt Bob's message, Mallet uses the command:

recrypt decrypt /in=file1.txt.mmx  /out=file1m.txt

The client reads the message and determines that it needs recryption data from the key server example.com. It requests the necessary material.

{Point.Messages[0].String()}

The key server checks to see that Mallet is authorized to read the message. If the user entry for the group included additional constraints such as limiting the number of documents Mallet could read in a day, these would also be checked.

The Key server accepts the request and returns the response:

{Point.Messages[1].String()}

The client decrypts the recryption blob using Mallet's private key and uses the decrypted key and the recryption data to complete the decryption of the data

4.5. Deleting a user

5. 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.

HTTP Well Known Service Prefix: /.well-known/recrypt

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.

5.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.

5.1.1. Message: RecryptRequest

Base class for all request messages.

[No fields]

5.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.

5.2.1. Message: RecryptResponse

Base class for all response messages. Contains only the status code and status description fields.

[No fields]

5.3. Imported Objects

The Recrypt Administration Sercice makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications.

5.4. Common classes

The following classes are referenced at multiple points in the protocol.

5.5. Administrator Transactions

5.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.

5.7. Transaction: CreateGroup

Request: CreateGroupRequest
Response: CreateGroupResponse

Create a new recryption group.

5.7.1. Message: CreateGroupRequest
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
5.7.2. Message: CreateGroupResponse
Inherits: RecryptResponse

Reports the success or failure of a CreateGroup request. The operation either succeeds or fails, there are no returned parameters

[No fields]

5.8. Transaction: UpdateGroup

Request: UpdateGroupRequest
Response: UpdateGroupResponse

Update the information describing a recryption group.

5.8.1. Message: UpdateGroupRequest
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
5.8.2. Message: UpdateGroupResponse
Inherits: RecryptResponse

Reports the success or failure of a UpdateGroup request. The operation either succeeds or fails, there are no returned parameters

[No fields]

5.9. Transaction: GetGroup

Request: GetGroupRequest
Response: GetGroupResponse

Request a recryption group record.

5.9.1. Message: GetGroupRequest
Inherits: RecryptRequest

Obtain recryption group data

GroupID: String (Optional)
The UDF fingerprint of the recryption group to add the member to.
5.9.2. Message: GetGroupResponse
Inherits: RecryptResponse

Obtain recryption group response.

RecryptionGroup: RecryptionGroup (Optional)
The Recryption Group to create

5.10. Transaction: AddMember

Request: AddMemberRequest
Response: AddMemberResponse

Add a member or members to an existing recryption group.

5.10.1. Message: AddMemberRequest
Inherits: RecryptRequest

Add a member to a recryption group (not currently used)

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
5.10.2. Message: AddMemberResponse
Inherits: RecryptResponse

Reports the success or failure of a AddMember request. The operation either succeeds or fails, there are no returned parameters

[No fields]

5.11. 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.

5.11.1. Message: UpdateMemberRequest
Inherits: RecryptRequest

Update a recryption group member entry (not currently used)

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
5.11.2. Message: UpdateMemberResponse
Inherits: RecryptResponse

Reports the success or failure of a UpdateMember request. The operation either succeeds or fails, there are no returned parameters

[No fields]

5.12. 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.

6. User Service

The only transaction supported by the user facing service at this point are the ability to request a recryption operation and the ability to request a group encryption key.

6.1. Transaction: GetKey

Request: GetKeyRequest
Response: GetKeyResponse

Request that the service provide a recryption result for the specified encrypted data and return it encrypted under the user's public key.

6.1.1. Message: GetKeyRequest
Inherits: RecryptRequest

Request the current recryption key for the specified recryption group. NB: At present the group key is NOT authenticated and thus a MITM can perform a key substituition attack. This will be fixed in the next release.

GroupID: String (Optional)
The recryption group for which the key data is requested.
6.1.2. Message: GetKeyResponse
Inherits: RecryptResponse

Response to get key request.

SignedKey: JoseWebSignature (Optional)
The signed key entry

6.2. Transaction: RecryptData

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.

6.2.1. Message: RecryptDataRequest
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.

MemberUDF: String (Optional)
The member Mesh profile UDF
MemberKeyUDF: String (Optional)
The member key fingerprint
GroupKeyID: String (Optional)
The key identifier of the group key to which the data is encrypted
6.2.2. Message: RecryptDataResponse
Inherits: RecryptResponse

Result of recryption request.

Partial: Binary (Optional)
The partial decryption information to use to complete the key agreement
EncryptedPartial: JoseWebEncryption (Optional)
The partial decryption information to use to complete the key agreement encrypted under the user's key.
DecryptionKey: JoseWebEncryption (Optional)
The decryption key to use to complete the decryption encrypted under the user's key.

7. Acknowledgements

8. Security Considerations

[This is just a sketch for the present.]

9. IANA Considerations

[TBS list out all the code points that require an IANA registration]

References

Normative References

[RFC2119]
S. Bradner "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 RFC 2119 DOI 10.17487/RFC2119
[draft-hallambaker-mesh-architecture]
Phillip Hallam-Baker "Mathematical Mesh: Architecture" Internet-Draft draft-hallambaker-mesh-architecture-04 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-04.txt>
[Blaze98]
"[Reference Not Found!]"

Informative References

[draft-hallambaker-mesh-developer]
Phillip Hallam-Baker "Mathematical Mesh: Reference Implementation" Internet-Draft draft-hallambaker-mesh-developer-05 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-developer-05.txt>

Author's Address


Phillip Hallam-Baker
Comodo Group Inc.
Email:
Prepared: Rendered: