Network Working Group P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Informational May 24, 2018 Expires: November 25, 2018 Data At Rest Encryption Part 1: DARE Message draft-hallambaker-dare-message-00 Abstract This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [1] . 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 https://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 25, 2018. Copyright Notice Copyright (c) 2018 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 (https://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 Hallam-Baker Expires November 25, 2018 [Page 1] Internet-Draft DARE Message May 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Existing approaches . . . . . . . . . . . . . . . . . . . 4 1.2. The DARE Approach . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Related Specifications . . . . . . . . . . . . . . . . . 5 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.3. Defined terms . . . . . . . . . . . . . . . . . . . . . . 6 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Consolidated Messages . . . . . . . . . . . . . . . . 7 3.1.2. Related Messages . . . . . . . . . . . . . . . . . . 7 3.1.3. Detached Messages . . . . . . . . . . . . . . . . . . 7 3.1.4. Annotated Messages . . . . . . . . . . . . . . . . . 8 3.1.5. Proxy Re-encryption . . . . . . . . . . . . . . . . . 8 3.2. Additional Use Cases . . . . . . . . . . . . . . . . . . 8 3.2.1. Streaming data . . . . . . . . . . . . . . . . . . . 8 3.2.2. Information Erasure by Key Deletion . . . . . . . . . 8 3.2.3. Field level encryption . . . . . . . . . . . . . . . 9 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. JSON . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. JSON-B . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Application Directed Encoding . . . . . . . . . . . . 10 5. Processing Model . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Consolidated Message Generation . . . . . . . . . . . . . 11 5.1.1. Message Header . . . . . . . . . . . . . . . . . . . 11 5.1.2. Enhanced Data Sequence . . . . . . . . . . . . . . . 13 5.1.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Consolidated Message Recovery . . . . . . . . . . . . . . 15 5.2.1. Verify signers . . . . . . . . . . . . . . . . . . . 15 5.2.2. Match recipient info . . . . . . . . . . . . . . . . 15 5.2.3. Recover Master Key . . . . . . . . . . . . . . . . . 15 5.2.4. Process Enhanced Data Sequences . . . . . . . . . . . 16 5.2.5. Signature validation . . . . . . . . . . . . . . . . 16 5.3. Detached Messages . . . . . . . . . . . . . . . . . . . . 16 5.4. Cloaked Messages . . . . . . . . . . . . . . . . . . . . 16 6. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Field: kwd . . . . . . . . . . . . . . . . . . . . . . . 17 7. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Message Classes . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. Structure: DAREMessageSequence . . . . . . . . . . . 17 7.2. Header and Trailer Classes . . . . . . . . . . . . . . . 18 7.2.1. Structure: DARETrailer . . . . . . . . . . . . . . . 18 Hallam-Baker Expires November 25, 2018 [Page 2] Internet-Draft DARE Message May 2018 7.2.2. Structure: DAREHeader . . . . . . . . . . . . . . . . 18 7.3. Cryptographic Data . . . . . . . . . . . . . . . . . . . 19 7.3.1. Structure: DARESigner . . . . . . . . . . . . . . . . 19 7.3.2. Structure: X509Certificate . . . . . . . . . . . . . 19 7.3.3. Structure: DARESignature . . . . . . . . . . . . . . 20 7.3.4. Structure: DARERecipient . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1. Encryption/Signature nesting . . . . . . . . . . . . . . 20 8.2. Side channel . . . . . . . . . . . . . . . . . . . . . . 20 8.3. Salt reuse . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Test Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Plaintext Message . . . . . . . . . . . . . . . . . . . 21 11.2. Plaintext Message with EDS . . . . . . . . . . . . . . . 22 11.3. Encrypted Message . . . . . . . . . . . . . . . . . . . 22 11.4. Signed Messages . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The DARE Message syntax is based on a subset of the JSON Web Signature [RFC7515] and JSON Web Encryption [RFC7516] standards and shares many fields and semantics. The processing model and data structures have been simplified to remove as many redundant features and alternative means of specifying the same content. An important innovation in the DARE message format is the separation of key exchange and data encryption operations so that a Master Key (MK) established in a single exchange to be applied to multiple octet sequences. This means that a public key operation may be used to encrypt multiple parts of the same message or to multiple messages. To maintain the security of the cryptographic algorithm, each octet sequence is encrypted under a different encryption key (and IV if required) derived from the Master Key by means of a salt. Depending on application needs, the salt may be explicit or implicit. An explicit salt is an opaque sequence of octets prepended to the data item. An implicit salt is an octet sequence constructed by application specific means such as the sequence number of a message or the byte position of a field in a file. Hallam-Baker Expires November 25, 2018 [Page 3] Internet-Draft DARE Message May 2018 1.1. Existing approaches Traditional cryptographic containers describe the application of a single key exchange to a single octet sequence. Examples include PCKS#7/CMS [RFC2315] , OpenPGP [RFC4880] and JSON Web Encryption [RFC7516] . To encrypt a message using RSA, the creator first generates a random encryption key and initialization vector (IV). The encryption key is encrypted under the public key of each recipient to create a per- recipient decryption entry. The encryption key, plaintext and IV are used to generate the ciphertext (figure 1). [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare- message.html [2].]] Monolithic Key Exchange and Encrypt This approach is adequate for the task of encrypting a single octet stream. It is less than satisfactory when encrypting multiple octet streams or very long streams for which a rekeying operation is desirable. 1.2. The DARE Approach The DARE key exchange begins with the same key exchange used to produce the CEK in JWE but instead of using the CEK to encipher data directly, it is used as one of the inputs to a Key Derivation Function (KDF) that is used to derive parameters for each block of data to be encrypted. To avoid the need to introduce additional terminology, the term 'CEK' is still used to describe the output of the key agreement algorithm (including key unwrapping if required) but it is more appropriately described as a Master Key (figure 2). [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare- message.html [3].]] Exchange of Master Key A Master Key may be used to encrypt any number of data items. Each data item is encrypted under a different encryption key and IV (if required). This data is derived from the Master Key using the HKDF function [RFC5869] using a different salt for each data item and separate info tags for each cryptographic function (figure 3). Hallam-Baker Expires November 25, 2018 [Page 4] Internet-Draft DARE Message May 2018 [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare- message.html [4].]] Data item encryption under Master Key and per-item salt. This approach to encryption offers considerably greater flexibility allowing the same format for data item encryption to be applied at the transport, message or field level. 2. Definitions 2.1. Related Specifications The DARE message format is based on the following existing standards and specifications. Object serialization The JSON-B [draft-hallambaker-jsonbcd] encoding is used for object serialization. This encoding is an extension of the JavaScript Object Notation (JSON) [RFC7159] . Message syntax The cryptographic processing model is based on JSON Web Signature (JWS) [RFC7515] , JSON Web Encryption (JWE) [RFC7516] and JSON Web Key (JWK) [RFC7517] . Cryptographic primitives. The HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] and Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm [RFC3394] are used. The Uniform Data Fingerprint method of presenting data digests is used for key identifiers and other purposes [draft-hallambaker-udf] . Cryptographic algorithms The cryptographic algorithms and identifiers described in JSON Web Algorithms (JWA) [RFC7518] are used together with additional algorithms as defined in the JSON Object Signing and Encryption IANA registry [IANAJOSE] . 2.2. 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] . Hallam-Baker Expires November 25, 2018 [Page 5] Internet-Draft DARE Message May 2018 2.3. Defined terms The terms "Authentication Tag", "Content Encryption Key", "Key Management Mode", "Key Encryption", "Direct Key Agreement", "Key Agreement with Key Wrapping" and "Direct Encryption" are defined in the JWE specification [RFC7516] . The terms "Authentication", "Ciphertext", "Digital Signature", "Encryption", "Initialization Vector (IV)", "Message Authentication Code (MAC)", "Plaintext" and "Salt" are defined by the Internet Security Glossary, Version 2 [RFC4949] . Annotated Message A DARE Message that contains an edss field with at least one entry. Authentication Data A Message Authentication Code or authentication tag. Buffered Generation Mode A mode of generating a DARE message in which the data input is read completely before beginning output. Consolidated Message A DARE message that contains the key exchange information necessary for the intended recipient(s) to decrypt it. Detached Message A DARE message that does not contain the key exchange information necessary for the intended recipient(s) to decrypt it. Encryption Context The master key, encryption algorithms and associated parameters used to generate a set of one or more enhanced data sequences. Enhanced data sequence (EDS) A sequence consisting of a salt, content data and authentication data (if required by the encryption context). Enhancement Applying a cryptographic operation to a data sequence. This includes encryption, authentication and both at the same time. Generator The party that generates a DARE message. Group Encryption Key A key used to encrypt data to be read by a group of users. This is typically achieved by means of some form of proxy re-encryption or distributed key generation. Group Encryption Key Identifier A key identifier for a group encryption key. Hallam-Baker Expires November 25, 2018 [Page 6] Internet-Draft DARE Message May 2018 Master Key (MK) The master secret from which keys are derived for authenticating enhanced data sequences. Recipient Any party that receives and processes at least some part of a DARE message. Related Message A set of DARE messages that share the same key exchange information and hence the same Master Key. Unbuffered Streaming Mode. A mode of generating a DARE message in which data MAY be output before the input is read. Uniform Data Fingerprint (UDF) The means of presenting the result of a cryptographic digest function over a data sequence and content type identifier specified in the Uniform Data Fingerprint specification [draft-hallambaker-udf] 3. Applications 3.1. Message Types 3.1.1. Consolidated Messages A consolidated DARE message contains the ciphertext and authentication data for a data object together with the key exchange information necessary for the intended recipient(s) to process it. Consolidated messages provide the same functionality as traditional PKJCS#7/CMS and OpenPGP message formats and may be used as a one-for- one replacement. 3.1.2. Related Messages A set of DARE messages are related if they share the same key exchange information. Related messages allow a single key exchange to be amortized over a collection of data items. This is particularly useful when a large collection of short data items is required such as in a server log or a chat-room transcript. 3.1.3. Detached Messages A detached DARE message contains only the ciphertext and authentication data for a data object and does not provide any key exchange information. Hallam-Baker Expires November 25, 2018 [Page 7] Internet-Draft DARE Message May 2018 The use of detached messages in a protocol allows key exchange information and message data to be passed to a recipient separately, possibly over different channels or even with entirely different partners. For example, a service returning the last hundred entries from a log file encrypted as a series of DARE related messages need only provide the key exchange data once. 3.1.4. Annotated Messages An annotated DARE message contains a message header with encrypted metadata in addition to an encrypted body. The use of annotated messages allows a receiver to process message data and metadata separately. For example, a mail application typically provides users with a display showing a short summary of the messages received (sender, date, subject, etc.). Encrypting the metadata to be shown to the user in the summary display separately from the message body allows this data to be presented to the user without the need to download any part of the message bodies 3.1.5. Proxy Re-encryption The ability to re-use the output of a key exchange is of particular importance when using proxy re-encryption or distributed key generation as completing each key agreement incurs an interaction with the key server. 3.2. Additional Use Cases 3.2.1. Streaming data The DARE message format supports encryption and decryption in 'streaming mode' in which blocks of output data are emitted as the input is presented. This allows synchronous communications (e.g. video, voice) to be supported and permits files of arbitrary size to be encrypted with finite state. It is not necessary to buffer the entire plaintext or ciphertext before generating a message. 3.2.2. Information Erasure by Key Deletion Overwriting a DARE salt value prevents decryption of the corresponding data unless the salt can be recovered. Use of a suitably large random salt allows erasure of the salt to be Hallam-Baker Expires November 25, 2018 [Page 8] Internet-Draft DARE Message May 2018 considered equivalent to erasure of the message data. For example, if a salt of 128 random bits and an encryption algorithm of at least 128 bits are used, the work factor for decryption will be O(2^128) even if the decryption key is compromised. 3.2.3. Field level encryption The DARE key exchange and data item encoding may be applied to encrypt multiple fields in a single file under a Common Encryption Key. Field level encryption is particularly useful in database and spreadsheet applications. 4. Message Format A consolidated DARE message is a sequence of four parts as follows. Header Information a reader requires to being processing the message body. By definition, the header of a consolidated message contains the key agreement information and the header of a detached message does not. The header may also be used to specify content metadata (such as the data type) and encrypted annotations. Salt An opaque sequence of octets that is (statistically) unique to this combination of body and Master Key. Body The data block Trailer Information a reader requires to complete processing the message body that is not provided in the header. A detached DARE message has the same sequence of four parts but the header part is empty. The header being communicated out-of- band with respect to the message to which it appears. 4.1. Encodings A DARE message MAY be presented in JSON encoding or a compact encoding based on JSON-B. 4.1.1. JSON The DARE message is encoded as JSON sequence with up to four entries. The position of the item in the sequence specifies its function. Thus the Header entry MAY be empty but MUST not be absent. Header The header is encoded as a JSON object Hallam-Baker Expires November 25, 2018 [Page 9] Internet-Draft DARE Message May 2018 Salt The salt is encoded as a base64url encoded string Body The body is encoded as a base64url encoded string Trailer The trailer is encoded as a JSON object For example, the following sequence is a JSON encoded message with an empty header and trailer and a salt and body of zero length: [ {}, "", "", {} ] Figure 1 4.1.2. JSON-B JSON-B Encoding provides a more compact representation and in particular, allows ciphertext to be presented in binary form as opposed to Base-64 encoding. Note that JSON-B encoding is a superset of JSON, a JSON-B decoder will be able to decode either format without additional tagging to specify which format is being used. The square braces used to specify a JSON sequence MUST be present when a DARE Message is embedded in a JSON-B encoded object but MAY be omitted in situations where no ambiguity arises from doing so. For example, when presenting a DARE Message as a standalone file or in a DARE Container. 4.1.3. Application Directed Encoding Applications MAY define their own encoding mechanisms to suit their needs. 5. Processing Model The DARE processing model is based on the model in JWE [RFC7516] with the following extensions: o Support for multiple recipients o Support for multiple message bodies encrypted under keys derived from a single key exchange. o Signature and encryption are supported in a single format rather than separately. o Authentication tags are appended to the end of the message body. Hallam-Baker Expires November 25, 2018 [Page 10] Internet-Draft DARE Message May 2018 o Message Authentication Codes are supported as a means of authentication. 5.1. Consolidated Message Generation Two generation modes are supported: Buffered The data body is buffered in memory while the data header is completed. Streaming The DARE message is generated in a single pass. Use of buffered mode avoids the need for data chunking and allows messages to provide all the information required for processing in the message header. Use of streamed mode avoids the need to buffer the data body while assembly of the header is completed. This allows messages of arbitrary size to be processed with fixed resources. 5.1.1. Message Header The Message header contains the key exchange information which MAY be shared by multiple related messages, 5.1.1.1. Signatures and Signers If the message is to be authenticated by means of a digital signature, the Header MUST contain either a Signatures field or a Signers field but not both. The Signatures field contains the actual signature value which cannot usually be calculated until processing of the message body is complete. The Signers field contains all the information from a signature except for the signature itself. This allows a verifier to perform decryption and signer verification processing in parallel and to reject a message that is not signed by an accepted signer before completing processing of the message body. 5.1.1.2. Key Exchange The DARE key exchange is based on the JWE key exchange except that encryption modes are intentionally limited and the output of the key exchange is the DARE Master Key rather than the Content Encryption Key. Hallam-Baker Expires November 25, 2018 [Page 11] Internet-Draft DARE Message May 2018 A DARE Key Exchange MAY contain any number of Recipient entries, each providing a means of decrypting the Master Key using a different private key. If the Key Exchange mechanism supports message recovery, Direct Key Agreement is used, in all other cases, Key Wrapping is used. This approach allows messages with one intended recipient to be handled in the exact same fashion as messages with multiple recipients. While this does require an additional key wrapping operation, that could be avoided if a message has exactly one intended recipient, this is offset by the reduction in code complexity. If the key exchange algorithm does not support message recovery (e.g. Diffie Hellman and Elliptic Curve Diffie-Hellman), the HKDF Extract- and-Expand Key Derivation Function is used to derive a master key using the following info tag: "dare-master" [64 61 72 65 2d 6d 61 73 74 65 72] Key derivation info field used when deriving a master key from the output of a key exchange. The master key length is the maximum of the key size of the encryption algorithm specified by the key exchange header, the key size of the MAC algorithm specified by the key exchange header (if used) and 256. 5.1.1.3. Key Identifier The JWE/JWS specifications define a kid field for use as a key identifier but not how the identifier itself is constructed. All DARE key identifiers are either UDF key fingerprints [draft-hallambaker-udf] or Group Key Identifiers. A UDF fingerprint is formed as the digest of an IANA content type and the digested data. A UDF key fingerprint is formed with the content type application/pkix-keyinfo and the digested data is the ASN.1 DER encoded PKIX certificate keyInfo sequence for the corresponding public key. A Group Key Identifier has the form @. Where is a UDF key fingerprint and is the DNS address of a service that provides the encryption service to support decryption by group members. Hallam-Baker Expires November 25, 2018 [Page 12] Internet-Draft DARE Message May 2018 5.1.2. Enhanced Data Sequence A DARE Enhanced Data Segment is an atomic unit that contains a salt and the result(s) of applying the salt and Master Key to a plaintext under the enhancement mode specified in the key exchange. The following enhancement modes are supported: Plaintext The EDS consists of a plaintext. Authenticated The EDS consists of a plaintext with an authentication tag appended to the end. Encrypted The EDS consists of a ciphertext only Encrypted and Authenticated The EDS consists of a ciphertext with an authentication tag appended to the end. In each case the encryption and/or authentication algorithms and all associated parameters (key size, output length) are specified in the associated key exchange header. A DARE message MAY contain multiple Enhanced Data Sequences. The message body, cloaked headers, annotations and signature values are all presented as Enhanced Data Sequences. The message body is distinct from all other Enhanced Data Sequences in that each message MUST have exactly one message body and only the message body can be signed. Additionally, when the compact encoding is used, it is the only Enhanced Data Sequence that can be of variable length. 5.1.2.1. Salt A salt is a sequence of zero or more octets that is unique within the scope of a Master Key. Generators SHOULD NOT generate salt values that exceed 1024 octets. The salt value is opaque to the DARE encoding but MAY be used to encode application specific semantics including: o Frame number to allow reassembly of a data sequence split over a sequence of messages which may be delivered out of order. o Transmit the Master Key in the manner of a Kerberos ticket to allow some (but not necessarily all) to avoid the need to perform a key exchange. Hallam-Baker Expires November 25, 2018 [Page 13] Internet-Draft DARE Message May 2018 o Identify the Master Key under which the Enhanced Data Sequence was generated. o Enable erasure of the encrypted data plaintext by erasure of the encryption key. For data erasure to be effective, the salt must be constructed so that the difficulty of recovering the key is sufficiently high that it is infeasible. For most purposes, a salt with 128 bits of appropriately random data will be sufficient. 5.1.2.2. Key Derivation Encryption and/or authentication keys are derived from the Master Key using a Extract-and-Expand Key Derivation Function as follows: 1. The Master Key and salt value are used to extract the PRK (pseudorandom key) 2. The PRK is used to derive the algorithm keys using the application specific information input for that key type. The application specific information inputs are: "dare-encrypt" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an encryption or encryption with authentication key. "dare-iv" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an initialization vector. "dare-mac" [dare-mac] To generate a Message Authentication Code key. 5.1.2.3. Content The content of an Enhanced Data Sequence is the plaintext or ciphertext with the appended authentication tag as directed by the enhancement mode. Support for enhancement of unbuffered streaming data presents implementations with two cases of interest: 5.1.2.3.1. Known Length If the length of the body is known in advance of enhancement the generator can calculate the final length of the Enhanced Data Segment before encryption begins. This allows encryption of (e.g.) data files as a single data-last production when the compact encoding is being used. Hallam-Baker Expires November 25, 2018 [Page 14] Internet-Draft DARE Message May 2018 5.1.2.3.2. Unknown Length If the final length of the body is not known in advance of enhancement the generator must either buffer the output data in memory before generation or use an encoding that permits indefinite length octet sequences to be represented. In the compact encoding, this means a (possibly zero length) sequence of data-chunk productions terminated by a single data-last production 5.1.3. Trailer The trailer only contains information when the message is authenticated by means of a signature. 5.1.3.1. Signatures A list of message signature values. If the message header contains a Signer field, the trailer MUST contain a Signatures field giving the corresponding signature values. 5.2. Consolidated Message Recovery Decryption and verification is the opposite of the generation process 5.2.1. Verify signers Recipients MAY verify that the message signatures are adequate to meet the requirements of the security policy at any point in message recovery. The recipient determines which signer or signature entries are appropriate to their needs and if so, which digest algorithms are to be applied to the message plaintext. 5.2.2. Match recipient info The first step in recovering the master key is to determine which (if any) of the recipient entries can be used for decryption by examining the kid fields. 5.2.3. Recover Master Key Having identified the key exchange to use, the Master key. Hallam-Baker Expires November 25, 2018 [Page 15] Internet-Draft DARE Message May 2018 5.2.4. Process Enhanced Data Sequences Having recovered the Master Key, the recipient can decrypt whichever Enhanced Data Sequences it requires. 5.2.5. Signature validation If validation of one or more signature entries is required, the recipient recovers the signature value from the corresponding Enhanced Data Sequences and performs signature verification according to the specified algorithm. 5.3. Detached Messages Processing of a detached message is the same as for a consolidated message except for the fact that at least some of the header information is passed out of band with respect to the message. There are thus two sets of headers: Context Header The header that contains the key exchange (passed out of band with respect to the message). Message Header Additional header data contained in the message itself. Message headers take precedence over context headers. Thus if the encryption algorithm field 'enc' is specified in both places, the value specified in the message header takes precedence. 5.4. Cloaked Messages A cloaked message is a DARE message that contains a Cloaked field in the header. Implementations MAY support generation and parsing of cloaked messages. Implementations SHOULD NOT generate and MAY reject nested cloaked headers unless specifically directed by an application specification. The use of cloaked headers allows a second layer of key agreement to be specified within the first. The message body is always encrypted under the Master Key corresponding to the innermost key exchange. Enhanced Data Sequences that are contained in a cloaked header are encrypted under the master key contained in that header. Hallam-Baker Expires November 25, 2018 [Page 16] Internet-Draft DARE Message May 2018 6. Algorithms 6.1. Field: kwd The key wrapping and derivation algorithms. Since the means of public key exchange is determined by the key identifier of the recipient key, it is only necessary to specify the algorithms used for key wrapping and derivation. The default (and so far only) algorithm is kwd-aes-sha2-256-256. Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm [RFC3394] is used to wrap the Master Exchange Key. AES 256 is used. HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] is used for key derivation. SHA-2-256 is used for the hash function. 7. Reference A DARE Message consists of a Header, an Enhanced Data Sequence (EDS) and an optional trailer. This section describes the JSON data fields used to construct headers, trailers and complete messages. Wherever possible, fields from JWE, JWS and JWK have been used. In these cases, the fields have the exact same semantics. Note however that the classes in which these fields are presented have different structure and nesting. 7.1. Message Classes A DARE Message contains a single DAREMessageSequence in either the JSON or Compact serialization as directed by the protocol in which it is applied. 7.1.1. Structure: DAREMessageSequence A DARE Message containing Header, EDS and Trailer in JSON object encoding. Since a DAREMessage is almost invariably presented in JSON sequence or compact encoding, use of the DAREMessage subclass is preferred. Although a DARE Message is functionally an object, it is serialized as an ordered sequence. This ensures that the message header field will always precede the body in a serialization, this allowing processing of the header information to be performed before the entire body has been received. Hallam-Baker Expires November 25, 2018 [Page 17] Internet-Draft DARE Message May 2018 Header: DAREHeader (Optional) The message header. May specify the key exchange data, pre-signature or signature data, cloaked headers and/or encrypted data sequences. Body: Binary (Optional) The message body Trailer: DARETrailer (Optional) The message trailer. If present, this contains the signature. 7.2. Header and Trailer Classes A DARE Message sequence MUST contain a (possibly empty) DAREHeader and MAY contain a DARETrailer. 7.2.1. Structure: DARETrailer A DARE Message Trailer Signatures: DARESignature [0..Many] A list of signatures. A message trailer MUST NOT contain a signatures field if the header contains a signatures field. 7.2.2. Structure: DAREHeader Inherits: DARETrailer A DARE Message Header. Since any field that is present in a trailer MAY be placed in a header instead, the message header inherits from the trailer. EncryptionAlgorithm: String (Optional) The encryption algorithm as specified in JWE AuthenticationAlgorithm: String (Optional) Message Authentication Code algorithm Cloaked: Binary (Optional) If present in a header or trailer, specifies an encrypted data block containing additional header fields whose values override those specified in the message and context headers. When specified in a header, a cloaked field MAY be used to conceal metadata (content type, compression) and/or to specify an additional layer of key exchange. That applies to both the Message body and to headers specified within the cloaked header. Processing of cloaked data is described in? Hallam-Baker Expires November 25, 2018 [Page 18] Internet-Draft DARE Message May 2018 ContentType: String (Optional) The content type field as specified in JWE EDSS: Binary [0..Many] If present, the Encrypted Data Segments field contains a sequence of Encrypted Data Segments encrypted under the message Master Key. The interpretation of these fields is application specific. Signers: DARESigner [0..Many] A list of 'presignature' Recipients: DARERecipient [0..Many] A list of recipient key exchange information blocks. 7.3. Cryptographic Data DARE Message uses the same fields as JWE and JWS but with different structure. In particular, DARE messages MAY have multiple recipients and multiple signers. 7.3.1. Structure: DARESigner The signature value Dig: String (Optional) Digest algorithm hint. Specifying the digest algorithm to be applied to the message body allows the body to be processed in streaming mode. Alg: String (Optional) Key exchange algorithm KeyIdentifier: String (Optional) Key identifier of the signature key. Certificate: X509Certificate (Optional) PKIX certificate of signer. Path: X509Certificate (Optional) PKIX certificates that establish a trust path for the signer. 7.3.2. Structure: X509Certificate X5u: String (Optional) URL identifying an X.509 public key certificate X5: Binary (Optional) An X.509 public key certificate Hallam-Baker Expires November 25, 2018 [Page 19] Internet-Draft DARE Message May 2018 7.3.3. Structure: DARESignature Inherits: DARESigner The signature value SignatureValue: Binary (Optional) The signature value as an Enhanced Data Sequence under the message Master Key. 7.3.4. Structure: DARERecipient Recipient information KeyIdentifier: String (Optional) Key identifier for the encryption key. The Key identifier MUST be either a UDF fingerprint of a key or a Group Key Identifier KeyWrapDerivation: String (Optional) The key wrapping and derivation algorithms. WrappedMasterKey: Binary (Optional) The wrapped master key. The master key is encrypted under the result of the key exchange. RecipientKeyData: String (Optional) The per-recipient key exchange data. 8. Security Considerations 8.1. Encryption/Signature nesting 8.2. Side channel 8.3. Salt reuse 9. IANA Considerations 10. Acknowledgements 11. Test Examples In the following examples, Alice's public key parameters are: Hallam-Baker Expires November 25, 2018 [Page 20] Internet-Draft DARE Message May 2018 { "PrivateKeyDH": { "kid": "MB6GU-TKTNH-QOH3W-UXMLL-336UD-R52NE-A", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": "rJIvzTjRmFa6SBtwnPe_ZkBGFxxa_W0yS5K0cnVI2x6rtT2eSkpp ovzCtTagsAlnAwI426HgQcinyF4AxJMNgOqqG9KvoGnbmMclnMdvRYY7nGFEcoT4R 6BmvcpJtivh3M6odHslh60niJMQGuYdhF9-8nFPi9uC4WJljplq9FCReHKG_0RkBp dsa2CGQNQLG3yXCvFxj99cvkZknmUY_VSq8X3tMVaO-3MbN-fIPTr5aCuJE5jPcrK 38taOwekH5XGyc-Mls4-rUd5zK0nr2uCiO2RIVKJQfjQ1h62rTVRf3bdP477Wk1ZN iiWuHijuF8uJVlT2RDLMRJ6NM3excA", "Private": "8PreevvNyy8MEutpHO_bqh2_N_9zH9R5mE5N76dLXIX0VZsob0f z9zA_lQ-nP4aRAFUPwJpqli0FNFS5a3BWW2AnRV_hCxsVFAl2UX6v4eCxvNPyx2sU is9r1bgptfj_wu2FtEIKZTFh1AZ7ncgypK0N6OdwKolhmHUDVrWBU1PFG34jVgvY9 -MFwX8Ee3Uq6foMyGQo6wGRqMlvUWcfiFrETH-Xdi-DqKPfabeaKB3zGCA-YRH3L8 SlzQZ-qzE0G7tJvA8yMlZJ84m-GT8R_uxvgMoPWr1Je5oR16ZyIKru2enfH2jwOzV tTIdFwQ3RVgA-TzrsIO-pCLyQ-ztYOQ"}} Figure 2 The body of the test message is the UTF8 representation of the following string: "This is a test long enough to require multiple blocks" Figure 3 The EDS sequences, are the UTF8 representation of the following strings: "Subject: Message metadata should be encrypted" "2018-02-01" Figure 4 11.1. Plaintext Message A plaintext message without associated EDS sequences is an empty header followed by the message body: { "DAREMessage": [{}, "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZ SBtdWx0aXBsZSBibG9ja3M"]} Figure 5 Hallam-Baker Expires November 25, 2018 [Page 21] Internet-Draft DARE Message May 2018 11.2. Plaintext Message with EDS If a plaintext message contains EDS sequences, these are also in plaintext: { "DAREMessage": [{ "edss": ["U3ViamVjdDogTWVzc2FnZSBtZXRhZGF0YSBzaG91bGQgYmUgZW5jcn lwdGVk", "MjAxOC0wMi0wMQ"]}, "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdW x0aXBsZSBibG9ja3M"]} Figure 6 11.3. Encrypted Message The creator generates a master session key: 1E 20 22 8F B7 5E 47 59 06 DA D9 39 A1 00 7E C5 63 15 A0 42 18 40 1D AD 17 EB 5B 87 E3 F3 0F B0 Figure 7 The creator generates an ephemeral key: { "PrivateKeyDH": { "kid": "MB7ZZ-3W33A-F2VNY-ADWAT-6X65X-HHHPG-A", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": "bhlMqhBTwLSjpph1ieEbehhDLmJzlNa6T_KgryqJk6CpgosOGMnj nvkVx4SflKwMDZgdmlHMmKxuAF5AFcvC5iVaLKcN8GFKiUMFnl-u5HCSkZ4pO7VtD WIEw22eQ6kpnE6lPRoLGEnizs8NEC31QwDsbt7BlT3yvNyys7Cq1Zi7zEytcikxRP JT-7ayFb0c2SkkeSgcaAnOnADIjtOSUNP6oyJfdAGCric3L9q2sYQH0A3zofCDkMH PTz9B2juBTIkF2ZP-E4FL3qskm8rFhWXYDaBOoz0L8Ri0H4yL5lIR_NYeU7NmEsmN soPnMzFub5-vDk05hKzSYsZSapxsNw", "Private": "H9NDxDPDczPI4VfaADhpktKGNnbbFEXU32LrN6HWUOqC-jjgEjq JQPSSsh5OqOGI-qH3MRIWQptnZBoZZw8AZrst2hMSUgavR5pjdOUfI3qFDJ7X2BoJ 9tWIxdeRqRY68yZKQ2GRIsYWuJX-G4rMBne3OJMpYvSgOdMVAULfhIqQxQ4Bg36nh 5aiAFhHbAhFT_U8G9uJVp-MziOpFJMDJuuVpafl9BMwEroAbXbnqcCPZxm52MwrUa 15bUsRPiad4Rs3nUy3vwdBC0O5jJQDw_F7ood6-uhpTx7t_R5vntf5Tjq7hEU1QLq EZskmJ6uK4Lya6-WoAPpsmTKgXI_HXg"}} Figure 8 The key agreement value is calculated: Hallam-Baker Expires November 25, 2018 [Page 22] Internet-Draft DARE Message May 2018 22811486391394414590492811341153777463986902783003089366556548209526762765730219683813707386799406750290691991753923128379146807967938078807539268764153770385646898665685008214627230328234942573389292959755404564616024770330032105390813078723890794285774439949542234967770376637613771818877350239294601632726372687979478370265482477606010822581622774899854594915608577020941832506650132488015593629195309445336842126287753184731712091345210543038195952101405956063248137905625118965725721384090610579010991196609345058434675430657696472302230895509628359510168125995303027050657800721605305012305489054529556556071287 Figure 9 The key agreement value is used as the input to a HKDF key derivation function with the info parameter "master". E6 2B 66 B3 03 F1 23 62 50 1D 88 5E A3 1C DB 86 16 80 A1 1A 62 E9 9F 2B D1 5B 35 66 84 FB 08 ED Figure 10 To create the first EDS, a salt value is assigned. In this case a single octet with the value '01'. The salt value is then used to create the encryption key and IV as follows: Salt: Example.DareEDSSalt.ToStringBase16FormatHex() Encryption Key: Example.DareMessageKeyEncrypt.ToStringBase16FormatHex() IV: Example.DareMessageKeyIV.ToStringBase16FormatHex() Figure 11 The output sequence is the salt followed by the ciphertext: 88 01 01 88 40 15 3A AA 2A 62 BA 09 F2 C5 7D EF 40 F1 DF 4F 8E 62 9B 75 0B C1 CB 6D AE 87 BE 8C C3 BE 92 F9 42 64 8D 37 DB 1D 69 7C D9 60 21 05 94 C5 1C 8B F0 AC 17 5F 55 D6 D1 1F A5 EA 1C D7 42 39 E7 8C 61 Figure 12 The completed message is: Hallam-Baker Expires November 25, 2018 [Page 23] Internet-Draft DARE Message May 2018 { "DAREMessage": [{ "recipients": [{ "kid": "MB6GU-TKTNH-QOH3W-UXMLL-336UD-R52NE-A", "epk": { "PublicKeyDH": { "kid": "MB7ZZ-3W33A-F2VNY-ADWAT-6X65X-HHHPG-A", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": "bhlMqhBTwLSjpph1ieEbehhDLmJzlNa6T_KgryqJk6CpgosOGMnj nvkVx4SflKwMDZgdmlHMmKxuAF5AFcvC5iVaLKcN8GFKiUMFnl-u5HCSkZ4pO7VtD WIEw22eQ6kpnE6lPRoLGEnizs8NEC31QwDsbt7BlT3yvNyys7Cq1Zi7zEytcikxRP JT-7ayFb0c2SkkeSgcaAnOnADIjtOSUNP6oyJfdAGCric3L9q2sYQH0A3zofCDkMH PTz9B2juBTIkF2ZP-E4FL3qskm8rFhWXYDaBOoz0L8Ri0H4yL5lIR_NYeU7NmEsmN soPnMzFub5-vDk05hKzSYsZSapxsNw"}}, "wmk": "BbAZbgVlhI35WYKXJ-JgYDr0XyaFwa30KNJaoWmQhItN2Fb2WYfesA"}]}, "iAEBiEAVOqoqYroJ8sV970Dx30-OYpt1C8HLba6HvozDvpL5QmSNN9s daXzZYCEFlMUci_CsF19V1tEfpeoc10I554xh"]} Figure 13 11.4. Signed Messages This is not yet implemented. 12. References 12.1. Normative References [draft-hallambaker-jsonbcd] Hallam-Baker, P., "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- jsonbcd-11 (work in progress), April 2018. [draft-hallambaker-udf] Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- hallambaker-udf-10 (work in progress), April 2018. [IANAJOSE] "[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. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998. Hallam-Baker Expires November 25, 2018 [Page 24] Internet-Draft DARE Message May 2018 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010. [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. [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015. [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. 12.2. URIs [1] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [2] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [3] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [4] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html Author's Address Phillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires November 25, 2018 [Page 25]