Internet-Draft DARE Message August 2018
Hallam-Baker Expires February 28, 2019 [Page]
Stream:
Internet Engineering Task Force
Series:
Internet-Draft
Status:
Informational
Published:
Expires
Authors:
Phillip Hallam-Baker (Comodo Group Inc.)

Data At Rest Encryption Part 1: DARE Message Syntax
draft-hallambaker-dare-message-02

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.

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 February 28, 2019

Table of Contents

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 streamlined to remove alternative means of specifying the same content.

A DARE Message consists of a Header, Payload and an optional Trailer. To enable single pass encoding and decoding, the Header contains all the information required to perform cryptographic processing of the Payload and authentication data (digest, MAC, signature values) may be deferred to the Trailer section.

The DARE Message Syntax is designed to compliment the DARE Container syntax. A DARE Container is an append-only log format consisting of a sequence of frames. Cryptographic enhancements (signature, encryption) may be applied to individual frames or to sets of frames. Thus, a single key exchange may be used to provide a master key to encrypt multiple frames and a single signature may be used to authenticate all the frames in the container up to and including the frame in which the signature is presented.

The DARE Message syntax may be used either as a standalone cryptographic message syntax or as a means of presenting a single DARE Container frame together with the complete cryptographic context required to verify the contents and decrypt them.

1.1. Encryption and Integrity

An important innovation in the DARE Message Syntax 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 frames in a DARE Container.

To avoid reuse of the key and to avoid the need to communicate separate IVs, each octet sequence is encrypted under a different encryption key (and IV if required) derived from the Master Key by means of a salt that is unique for each octet sequence that is encrypted. The same approach is used to generate keys for calculating a MAC over the octet sequence if required. This approach allows encryption and integrity protections to be applied to the message payload, to header or trailer fields or to application defined Enhanced Data Sequences in the header or trailer.

1.1.1. Key Exchange

Traditional cryptographic containers describe the application of a single key exchange to encryption of a single octet sequence. Examples include PCKS#7/CMS [RFC2315], OpenPGP [RFC4880] and JSON Web Encryption [RFC7516].

To encrypt a message using RSA, the encoder 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).

Figure 1 : 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.

In the DARE approach, key exchange and key derivation are separate operations and keys MAY be derived for encryption or integrity purposes or both. A single key exchange MAY be used to derive keys to apply encryption and integrity enhancements to multiple data sequences.

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

Figure 2 : 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).

Figure 3 : 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.

1.1.2. Data Erasure

Each encrypted DARE Message specifies a unique Master Salt value of at least 128 bits which is used to derive the salt values used to derive cryptographic keys for the message payload and annotations.

Erasure of the Master Salt value MAY be used to effectively render the message payload and annotations undecipherable without altering the message payload data. The work factor for decryption will be O(2^128) even if the decryption key is compromised.

1.2. Signature

As with encryption, DARE Message signatures MAY be applied to an individual message or a sequence of messages.

1.2.1. Signing Individual Plaintext Messages

When an individual plaintext message is signed, the digest value used to create the signature is calculated over the binary value of the payload data. That is, the value of the payload before the encoding (Base-64, JSON-B) is applied.

1.2.2. Signing Individual Encrypted Messages

When an individual plaintext message is signed, the digest value used to create the signature is calculated over the binary value of the payload data. That is, the value of the payload after encryption but before the encoding (Base-64, JSON-B) is applied.

Use of signing and encryption in combination presents the risk of subtle attacks depending on the order in which signing and encryption take place [Davis2001].

Naïve approaches in which a message is encrypted and then signed present the possibility of a surreptitious forwarding attack. For example, Alice signs a message and sends it to Mallet who then strips off Alice's signature and sends the message to Bob.

Naïve approaches in which a message is signed and then encrypted present the possibility of an attacker claiming authorship of a ciphertext. For example, Alice encrypts a ciphertext for Bob and then signs it. Mallet then intercepts the message and sends it to Bob.

While neither attack is a concern in all applications, both attacks pose potential hazards for the unwary and require close inspection of application protocol design to avoid exploitation.

To prevent these attacks, each signature on a message that is signed and encrypted MUST include a witness value that is calculated by applying a MAC function to the signature value as described in section XXX.

1.2.3. Signing Sequences of Messages

To sign multiple messages with a single signature, we first construct a Merkle tree of the message payload digest values and then sign the root of the Merkle tree.

[This is not yet implemented but will be soon.]

2. Definitions

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 Annotations field with at least one entry.
Authentication Data
A Message Authentication Code or authentication tag.
Complete 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.
Encoded 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.
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.
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. Architecture

A DARE message is a sequence of three parts as follows.

Header
A JSON object containing information a reader requires to begin processing the message.
Payload
An array of octets.
Trailer
A JSON object containing information calculated from the message payload.

For example, the following sequence is a JSON encoded DARE Message with an empty header, a payload of zero length and an empty trailer:

[ {}, "", {} ]

DARE Messages MAY be encoded using JSON serialization or a binary serialization for greater efficiency.

JSON
Offers compatibility with applications and libraries that support JSON. Payload data is encoded using Base64 incurring a 33% overhead.
JSON-B
A superset of JSON encoding that permits binary data to be encoded as a sequence of length-data segments. This avoids the Base64 overhead incurred by JSON encoding.
JSON-C
A superset of JSON-C which provides additional efficiency by allowing field tags and other repeated string data to be encoded by reference to a dictionary.

DARE Message processors MUST support JSON serialization and SHOULD support JSON-B serialization.

3.1. Processing Considerations

The DARE Message Syntax supports single pass encoding and decoding without buffering of data. All the information required to begin processing a DARE message (key agreement information, digest algorithms), is provided in the message header. All the information that is derived from message processing (authentication codes, digest values, signatures) is presented in the message trailer.

The choice of message encoding does not affect the semantics of message processing. A DARE Message MAY be reserialized under the same serialization or converted from any of the specified serialization to any other serialization without changing the semantics or integrity properties of the message.

3.2. Content Metadata and Annotations

A header MAY contain header fields describing the payload content. These include:

ContentType
Specifies the IANA Content Type.
Annotations
A list of Encoded Data Sequences that provide application specific annotations to the message.

The format of the Encoded Data Sequences is described in the following section.

Consider the following mail message:

From: Alice@example.com
To: bob@example.com
Subject: TOP-SECRET Product Launch Today!

The CEO told me the product launch is today. Tell no-one!

Existing encryption approaches require that header fields such as the subject line be encrypted with the body of the message or not encrypted at all. Neither approach is satisfactory. In this example, the subject line gives away important information that the sender probably assumed would be encrypted. But if the subject line is encrypted together with the message body, a mail client must retrieve at least part of the message body to provide a 'folder' view.

The following is a plaintext DARE Message in which the header fields of the mail message are presented as annotations:

[{
    "cty":"application/example-mail",
    "Annotations":["iAEBiBdGcm9tOiBBbGljZUBleGFtcGxlLmNvbYgA",
      "iAECiBNUbzogYm9iQGV4YW1wbGUuY29tiAA",
      "iAEDiClTdWJqZWN0OiBUT1AtU0VDUkVUIFByb2R1Y3QgTGF1bmNoIFRvZGF5
  IYgA"
      ]},
  "VGhlIENFTyB0b2xkIG1lIHRoZSBwcm9kdWN0IGxhdW5jaCBpcyB0b2RheS4gVGVs
  bCBuby1vbmUh"
  ]

3.3. Encoded Data Sequence

An encoded data sequence (EDS) is a sequence of octets that encodes a data sequence according to cryptographic enhancements specified in the context in which it is presented. An EDS MAY be encrypted and MAY be authenticated by means of a MAC. The keys and other cryptographic parameters used to apply these enhancements are derived from the cryptographic context and a Salt prefix specified in the EDS itself.

An EDS sequence contains exactly three binary fields encoded in JSON-B serialization as follows:

Salt Prefix
A sequence of octets used to derive the encryption key, Initialization Vector and MAC key as required.
Body
The plaintext or encrypted content.
Authentication Tag
The authentication code value in the case that the cryptographic context specifies use of authenticated encryption or a MAC, otherwise is a zero-length field.

Requiring all three fields to be present, even in cases where they are unnecessary simplifies processing at the cost of up to six additional data bytes.

The encoding of the 'From' header of the previous example as a plaintext EDS is as follows:

88 01 
  01 
88 17 
  46 72 6f 6d 3a 20 41 6c   69 63 65 40 65 78 61 6d 
  70 6c 65 2e 63 6f 6d 
88 00 

~~~~

3.4. Encryption and Integrity

Encryption and integrity protections MAY be applied to any DARE Message Payload and Annotations.

The following is an encrypted version of the message shown earlier. The payload and annotations have both increased in size as a result of the block cipher padding. The header now includes Recipients and Salt fields to enable the content to be decoded.

[{
    "enc":"A256CBC",
    "Salt":"efgd4ZmJA8SWSD_l56mcFA",
    "cty":"application/example-mail",
    "Annotations":["iAEBiCCjAMYL7Y6ttb0s6Z2uDgHd_ZQpwdV_dIDVFlza2d6W
  8w",
      "iAECiCDHdBSRzEQyn9tD_pERC-_7jVp4gAiLtDIVD2qtiNWesA",
      "iAEDiDCWYa4U1EpF3ixKF1jNpdyfbtSYv7HlsD_5GfmO_gJJuEXmTLP0ekSQ
  yqhWubB4nPI"
      ],
    "recipients":[{
        "kid":"MD7VA-LPCWZ-KNRB2-EZVDE-G4OC2-QQXON-A",
        "epk":{
          "PublicKeyDH":{
            "kid":"MAB6Q-BP3Q4-DOH3V-H237A-PZARW-W5MDP-A",
            "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
            "Public":"kZe4hAzfInhXxINHCpIyfgZ1KabmGavzsh2gTgRsjaE76
  aI31UcH3IyXqOi8xTKZKxlAyiGPJlEGhkyZa_7hNmr8Pg_fP8MX-GQ4Nn-AEhUF1_
  YpnDHZp8dnEh9cmOGwoSi6SYsjSC3JlLnuyyuGgEEox1XDm5j4BN1Yp7Jqgoyiehd
  YShijkz3sjGymzfgTLV1x20zLQPO9hqWTUZq8s0ut1wmXB-n52XqwKWRAyAspFPom
  fVA6bLprAoxz3KvwQnLdGo8lCTG9n2HUo3n9ASXMrCtA3xXDGEf4QDEQJ-gP6IHDg
  cGhvgEZRPIHPqV7Kx6rqDsUHVppj_e-rpTnLg"}},
        "wmk":"Wp4WRPKNKDGI4NfSU6VnY2y8tkxvDtv-zFu26t0kl1_Aj0YrJDsW
  -Q"}
      ]},
  "xOY3fTKMc8XwUckZYThCEXEx2ptHpLnRZqqzF8lkk6pPBhVfpLnI2S3b74uFIsa6
  kVAh66jHepmmQsP-qKrDgA"
  ]
3.4.1. 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.

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.

3.4.2. Key Identifiers

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 Mesh/Recrypt 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 <fingerprint>@<domain>. Where <fingerprint> is a UDF key fingerprint and <domain> is the DNS address of a service that provides the encryption service to support decryption by group members.

3.4.3. Salt Derivation

A Master Salt is a sequence of 16 or more octets that is specified in the Salt field of the header.

The Master Salt is used to derive salt values for the message payload and associated encoded data sequences as follows.

Payload

EDS

Encoders 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:

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 is sufficient.

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

3.5. Signature

While encryption and integrity enhancements can be applied to any part of a DARE message, signatures are only applied to payload digest values calculated over one or more message payloads.

The payload digest value for a message is calculated over the binary payload data. That is, after any encryption enhancement has been applied but before the message encoding is applied. This allows messages to be converted from one encoding to another without affecting signature verification.

Single Payload
The signed value is the payload digest of the message payload.
Multiple Payload.
The signed value is the root of a Merkle Tree in which the payload digest of the message is one of the leaves.

Verification of a multiple payload signature naturally requires the additional digest values required to construct the Merkle Tree. These are provided in the Trailer in a format that permits multiple signers to reference the same tree data.

4. Algorithms

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

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

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

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

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.

5.2. Header and Trailer Classes

A DARE Message sequence MUST contain a (possibly empty) DAREHeader and MAY contain a DARETrailer.

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

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

5.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.
5.3.2. Structure: X509Certificate
X5u: String (Optional)
URL identifying an X.509 public key certificate
X5: Binary (Optional)
An X.509 public key certificate
5.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.
5.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.

6. Security Considerations

6.1. Encryption/Signature nesting

6.2. Side channel

6.3. Salt reuse

7. IANA Considerations

8. Acknowledgements

9. Test Examples

In the following examples, Alice's encryption private key parameters are:

{
  "PrivateKeyDH":{
    "kid":"MD7VA-LPCWZ-KNRB2-EZVDE-G4OC2-QQXON-A",
    "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
    "Public":"xaeO0_m7bbfmhmE1O0qyDRTIXwAwQFGV3XKMdC5xav_aBgz5k-X4d
  n8r5tEJ1ldfI-3MZ0l_0Vd00mV-cAVFfvd1ypmDkZTEve6SogXE1JYLeUywa0GCe1
  Htvyy-XKaXfKjPMm9hETbPJgqbNsirn_IOjhC2UtSpNibjgqPFWcxunJ4i1xEhQAH
  -Tw5ipk30igVUXOnyPosB4kGTUUSUmtG17cG6mKgWkc0mfWGGDuV9buzFnukB6dRh
  RASUD92vTcZriJrB9DUENmbd6d7dLJltuX7O7o-NOhySDfjjJ6f5StvLJNmrppzSa
  _wQyO-kPpu_mhgHNIEOMcvJyaqGiQA",
    "Private":"o4He4EvxqVrngKpvjHzTAvd7-nhx-_vnJyl6F4m9ipUsoyhD7yUc
  uclas3xAQnbacxkR-xO3J0N4_9FMJjcDlo53VWji_9ql2a4gViRraFbJCqxgOwiFt
  la9FPsyaqxP_TYm2E2d5DEPUvHumZZfz0pKOubtxA70iumcOJV1RxGW5W6mgIVeUz
  pmCDVwYuEm8a_P3E_NQcnM-GYlxeCpiQ_ynXzczb4ARo-DyKDrbv5lU_vm1lx9JH0
  C5oNzMjIg_W65eblEUvl7s3KGh6UhbWwL4-mcGX3rzEm3wFpldZbRKOhWDhJZ2pSU
  BGhmL2jVvfYY-SbrqfHklMlMYlmdsgA"}}

Alice's signature private key parameters are:

{
  "PrivateKeyRSA":{
    "kid":"MA3HR-W4WTI-QFMMQ-SRXKG-XR5L3-T3BQD-A",
    "n":"sv6WHejtoDKzpM2WrLqYywiBSB2zWU_dQ38YRv2Q8Q5Du5QrzP5hPaY1N6
  XsK-jXIXtLkUphwNNnR4FYj5KBGvlHXWtx326CNIVexsWzJDNXix-HEeGFl6zuFJe
  o99-iHtUGfu6tJbLVEzZO0VhRnjRV4qri88I1CbFq2Q_QUJg4USF6ma26ZC7cjYDD
  D4OtZ1tsgcs1gE8ji9koa8LGIwojD6NIIe8Pmi0WPqZI-z6NRqnKRmPY7x_02cofq
  ezQoqVf2QmAWbP3x7vZRu3PolxezQecTlhqtjyBjEcdbyOmS0xykWp7uElyzJZovC
  g11fcTnY16qZuKJ8B-oKNx_Q",
    "e":"AQAB",
    "d":"UsvWzrEPMhoh5OrAdte9k7U0cBJlArwhonYo2bWzFP4_MIaCmElW27iFR1
  911n3W_YLV2rgobZScYoQfXhIrrDmA3GK2At9QVVEYHSQYEHe7V_xWc1v5esagPmB
  E5ZvJly982Lw41YZab4-gd8-9uUuGKtpXLuA3vmsV_KAHATARoBxloeJDZF-Bi-sf
  J5hX9lh41houcODRntP3fLQyNcaJfH4YULytBdIV3be1N_O0kZmSU-a4VNL2AtORA
  C1xfsjCTU0hGd6nrRMncT0lSU6Njh1Yw2tPE__FVwkx2F1NRYmkK_mqoSpMJ5NWk_
  sTi05IrKG5g8ajlDu3tGbVVQ",
    "p":"xHElx_ETa4Q0V8C_7QtYWs6o3EX-hb3s-OeTRVt7IAKFIj1iq5AhyESX8J
  9Dmt6GWV8uKPP5K0y76CbJM6cM3z1khiAUJsFUy2d6ZHQQUVns2xxSN2qBhzFIxv6
  Lbbk-euhPRqI9YA81iSXfc2T3WlB46Cx7yCzneKnbao6xmb8",
    "q":"6UNAAkoXSWw4UUZ8ZDFrg6d2rBzvJQek99VH5w-KF5-hefWyvAKsXy-ww3
  9MobOPDCk7XevL9580Z_zjuMNB4w33lXa5JywQBFNCwso60-ZLBrQe_LofRa-beqe
  Na0dYSCI4F63D5A_tDDMNad2mU6kUgp3dXUjgj22aQlqzC0M",
    "dp":"KOinRYwezzUo8V1imqrSK5b982FgL9ntj6gqMzdp3LCpqQe_lJrfbiVav
  vFr0sSkldgMdNrZ-Ppx51asb-VJ-POAC66Cg8-fKPzTsDe7bjWb7cVoGcJEVzMcRN
  SdlKwPJulaGQuQXIDOVVFdx1ovaM95XmBlJrqzOZ2l4_rzYWE",
    "dq":"tpQ16NTXb1fuqOcz_DSWhAEzKTqokOJv5LCjTB9kpmMDQHPpR7IL-6FXi
  V39vF_QauNnHXewOgz6Nx7Bm9_xlWhcTzgTaq7ZhpkpG1CxRSTvurqHuqdwTNpMJ3
  A4iCza0_M81oPjXYJ9t9vJ9wBP7RHeBPLNzvN5GarfYGqf1AM",
    "qi":"Ay1lgoJtsIWN_7Htm7x95Xr1MHRNocW3H3uZQ8_o6HdpSxR7LoqkKOOmL
  ZbjJYlJ7fdeGypRnGQTBB9g-bdi5Yhlx2N_aT0l1rAuktUMouRqhDLLERTZDs_RE2
  bQ1ZdD4XXD7iX9LugoSVoFUbMZeLLeQZlxKeUBjbhnPin32Ek"}}

The body of the test message is the UTF8 representation of the following string:

"This is a test long enough to require multiple blocks"

The EDS sequences, are the UTF8 representation of the following strings:

"Subject: Message metadata should be encrypted"
"2018-02-01"

9.1. Plaintext Message

A plaintext message without associated EDS sequences is an empty header followed by the message body:

{
  "DAREMessage":[{},
    "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
  BibG9ja3M"
    ]}

9.2. Plaintext Message with EDS

If a plaintext message contains EDS sequences, these are also in plaintext:

{
  "DAREMessage":[{
      "Annotations":["iAEBiC1TdWJqZWN0OiBNZXNzYWdlIG1ldGFkYXRhIHNob3
  VsZCBiZSBlbmNyeXB0ZWSIAA",
        "iAECiAoyMDE4LTAyLTAxiAA"
        ]},
    "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
  BibG9ja3M"
    ]}

9.3. Encrypted Message

The creator generates a master session key:

  F2 5A 85 06  EF D1 FD B6  CF B9 13 01  F6 7B 9E E9
  A0 04 AA 38  FE B2 E7 0A  59 17 A3 0B  58 FC 9E 5E

The creator generates an ephemeral key:

{
  "PrivateKeyDH":{
    "kid":"MCHMJ-3VQ7B-FXEH3-UVV5R-WNXOA-XUMSQ-A",
    "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
    "Public":"fZKmHpZH7PaNgIHzlFsU1VjrzRk6qwCn1yOmFUzYMxuMGelnkANq2
  pYqVBCKTSm5kZ-amEBYrYFGGWPhwSrvvYhtf1YGJhFZgOObnbfsUGGwZ6fvPLdCjF
  BqaLdLR7FYqaLORjtI5UxJpWBckGg6Cf-DFMFbrEJbTGtjw45E-wegW0XeYWosv9N
  I88S5dOlRHkwCQ59ZD_NyZ-khKxnSxIyZ4gkypsGCIDk7_mf1u4LyGzVIBQ_A_LAV
  PThxS_Zt9yvOp9F_Yf9PnKe2jvXaLb0cdtndHiDX-rAALoqmsRwJXxeSkl6JynpxH
  AgOVYjkR7mMgQxE-sMQMAHzqW1pfg",
    "Private":"_F_JApRGh70a-FcsfpQ3WJXXKhsegmvMr8bpF0E4UXusApOCG0dI
  uW4eD5vmLpCk4hRl9xJyQmP4bT7hIrSrDOBdg06uhEoOyp20xLoZJYXzCOFH0MK1G
  MyRkrHcXG94lJX7FIxpjTZrwRU_uey7ROXPlp-TY0ekQzFJjf7YDAN1-BmhSLY_zf
  JN0P79d1u6YoGJ6jpxdtIt7tQv3bsc76mWDfeYb1AhqkbFaayNFjchQiG4liCpTTH
  IdIhra2wnDAPig5uEaA0P7xqC83MEbv7J2TX_XQJlGNTSyfSdxMCC_Ix4YU7M4y4f
  NxQX_rh7cgxO0_I5g4lylXOcl7CvcQ"}}

The key agreement value is calculated:

  33 E2 C8 BC  06 30 2E 9F  A5 C0 82 01  5D A5 37 19
  22 93 7A B1  A9 FE E0 B1  A1 A1 86 B1  46 17 3A 01
  69 78 F1 83  5B 44 1A D5  31 D0 18 69  EB 1E 8A B8
  58 6B 33 2E  5F 6D 0F B1  A6 4E CA 07  61 A8 60 D1
  66 8B 91 97  05 20 4E B9  18 01 8E 9F  A5 31 6E B6
  A7 3C A1 86  0E F7 18 FA  09 5B 04 FD  86 3D E2 6C
  04 62 A1 2C  4B 16 80 EE  FA 5A 0A 61  D4 CF D0 F2
  67 B3 68 9C  53 7A 12 97  FB 9F 32 1F  D7 BA 86 6B
  62 74 F2 D6  F2 7B 09 16  F6 36 7A 78  EA 51 69 DC
  E4 D6 1C F9  ED EF 8D F0  90 99 5E 16  BD 78 21 40
  72 3B B2 E4  DF D5 64 C9  71 B0 5C 93  C6 0E AE 76
  F8 85 39 1F  57 C0 30 71  90 A8 9B 2B  FF EE 84 46
  9B 91 3E 62  50 CD C7 E3  72 33 DE 06  E4 27 1A 3F
  1F 82 5A 11  37 53 8E BD  59 40 12 6D  D8 00 A8 AD
  3C 15 36 6D  C3 83 D7 23  5B 15 66 99  D2 AE 94 36
  87 9B 77 F4  7F 94 51 29  3A 42 05 82  44 A8 87 75

The key agreement value is used as the input to a HKDF key derivation function with the info parameter System.Byte[] to create the key used to wrap the master key:

  60 DA 63 AE  D8 92 AD 6E  06 53 04 F2  A4 7C 47 62
  2E 89 59 86  03 9E B8 73  CF 0D 2F 6E  6C 61 53 CE

The wrapped master key is:

  C7 D6 D0 D7  71 17 A1 55  A3 61 EF E8  CD 0B 98 55
  B8 E4 A3 C1  C4 0C B4 3C  E6 AB 94 96  42 F2 E4 EE
  C8 51 2E C6  C9 B0 E8 45

This information is used to calculate the Recipient information shown in the example below.

To encrypt a message, we first generate a unique salt value:

  DB E0 2A 28  D9 ED 62 60  42 4F 0B D6  92 9E E8 8A

The salt value and master key are used to generate the payload encryption key:

  68 0D 0C F0  60 D1 99 C4  C6 15 71 F9  92 03 24 83
  52 2F 33 96  96 6B 87 DA  30 F3 C2 C5  5E 4F 03 11

Since AES is a block cipher, we also require an initializarion vector:

  C1 0E 1A 3B  24 E0 EA 62  7D 85 41 53  AF E9 D6 35

The output sequence is the encrypted bytes:

  79 38 5B 62  1E 5C A3 06  45 C4 A3 51  DE 00 C2 50
  5C 5F 0E 90  9B 00 45 8E  73 A9 2D 83  2A 2F 49 83
  EB 04 74 9B  70 C3 36 20  F3 66 4D AB  54 35 2F D4
  69 00 46 75  26 40 44 58  C2 F1 8A 6C  27 42 74 5F

Since the message is not signed, there is no need for a trailer. The completed message is:

{
  "DAREMessage":[{
      "enc":"A256CBC",
      "Salt":"2-AqKNntYmBCTwvWkp7oig",
      "recipients":[{
          "kid":"MD7VA-LPCWZ-KNRB2-EZVDE-G4OC2-QQXON-A",
          "epk":{
            "PublicKeyDH":{
              "kid":"MCHMJ-3VQ7B-FXEH3-UVV5R-WNXOA-XUMSQ-A",
              "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
              "Public":"fZKmHpZH7PaNgIHzlFsU1VjrzRk6qwCn1yOmFUzYMxu
  MGelnkANq2pYqVBCKTSm5kZ-amEBYrYFGGWPhwSrvvYhtf1YGJhFZgOObnbfsUGGw
  Z6fvPLdCjFBqaLdLR7FYqaLORjtI5UxJpWBckGg6Cf-DFMFbrEJbTGtjw45E-wegW
  0XeYWosv9NI88S5dOlRHkwCQ59ZD_NyZ-khKxnSxIyZ4gkypsGCIDk7_mf1u4LyGz
  VIBQ_A_LAVPThxS_Zt9yvOp9F_Yf9PnKe2jvXaLb0cdtndHiDX-rAALoqmsRwJXxe
  Skl6JynpxHAgOVYjkR7mMgQxE-sMQMAHzqW1pfg"}},
          "wmk":"x9bQ13EXoVWjYe_ozQuYVbjko8HEDLQ85quUlkLy5O7IUS7Gyb
  DoRQ"}
        ]},
    "eThbYh5cowZFxKNR3gDCUFxfDpCbAEWOc6ktgyovSYPrBHSbcMM2IPNmTatUNS
  _UaQBGdSZARFjC8YpsJ0J0Xw"
    ]}

9.4. Signed Message

Signed messages specify the digest algorithm to be used in the header and the signature value in the trailer. Note that the digest algorithm is not optional since it serves as notice that a decoder should digest the payload value to enable signature verification.

{
  "DAREMessage":[{
      "dig":"S512"},
    "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
  BibG9ja3M",
    {
      "signatures":[{
          "signature":"Jmkiofz1Sf_egB1J1CEajcmRUckChROVM5N9ecx0AFso
  0EsJkhc94h-mGQk596aHtlBdOdCAkuzoJyEKSyQ90a356qLM0XOl9h2mC_MakWSqh
  Yp2e7yiViTCoCCoT7chyP9utuZVznaCh803JXTU5pH7h4-Gxit32MbkXp-IDKI"}
        ],
      "PayloadDigest":"raim8SV5adPbWWn8FMM4mrRAQCO9A2jZ0NZAnFXWlG0x
  F6sWGJbnKSdtIJMmMU_hjarlIPEoY3vy9UdVlH5KAg"}
    ]}

9.5. Signed and Encrypted Message

A signed and encrypted message is encrypted and then signed. The signer proves knowledge of the payload plaintext by providing the plaintext witness value.

{
  "DAREMessage":[{
      "enc":"A256CBC",
      "dig":"S512",
      "Salt":"aOvCYp9a5DpcHcgpw3wv4w",
      "recipients":[{
          "kid":"MD7VA-LPCWZ-KNRB2-EZVDE-G4OC2-QQXON-A",
          "epk":{
            "PublicKeyDH":{
              "kid":"MAS7K-ZBZXN-3U4DA-UEHQW-LSZDA-OVX4J-A",
              "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
              "Public":"5u5OuBV3Ccj89DhPv2WppNswXpW2eA_CTsO-pZTA-kT
  grsqUUDVrbwI9dtUNOPF8ND4UZXZouzsVPJ-0yyOJTGiMDRqrKYY0jATfOVD42EYu
  fyR31XFVz-hdzgpM103yCxnBMCOzYCH0GJT-lASeDuEojHtVsvxuCQNxE_-Ta8jUm
  YnpS1JqaMB5sSh2iSktkJnWFOVwKI3kixQN6p1UXLmvhw5t2fpHwzx3Hiy22kq0me
  hnDgffUgy2OCeltOV4UlDexpjDxWDeIj29VYoucGfr3L13zLY2gdLMZ2IJ-DZrhHv
  9hIKmsR3yZ1sn9THZXsF0rZESkJgPNy2AkIBXgAA"}},
          "wmk":"aiilPIFPT3nL5EUYRU5GSzk_F82wUG-r4xBRxLAs6TxQIZJ-Ff
  WiLA"}
        ]},
    "qr-30TuT9qe5t59itN9ao2xBX1Pvr4qHRseL-IaGiSzJou2IK1k2x-YrBedDCS
  G2dg5uUEoUZmOF2hc3DSGvbQ",
    {
      "signatures":[{
          "signature":"NwqdPQ2DwFCr4kEq1auzdez3e32HdP-agRbf_idYt9Ta
  AIE5UwGj6-GY4RiaogghaD3uHK-3tZSyXyMuWcFxu86nPs3ZKgrpAT-T4EsI559Bi
  DRLvkn4xSPUOooHFizVquI92ozRJAATT-R3pNI4-p8xLp03e408mfNSdAl3QIY",
          "witness":"ldeWLTmDQAIBKDSo0tS8KLwTgzYFmCD3TKEWp-1y8ss"}
        ],
      "PayloadDigest":"zL7dRkjAQRvnIBNgSzPUGbiw2_AVDf8lOolFE3FY-e7O
  EZX-LZMffFuwXyrjElnqJ47jsz6wlMuI64YWg9M8vQ"}
    ]}

References

Normative References

[RFC7515]
M. Jones and J. Bradley and N. Sakimura "JSON Web Signature (JWS)" RFC 7515 DOI 10.17487/RFC7515
[RFC7516]
M. Jones and J. Hildebrand "JSON Web Encryption (JWE)" RFC 7516 DOI 10.17487/RFC7516
[RFC2315]
B. Kaliski "PKCS #7: Cryptographic Message Syntax Version 1.5" RFC 2315 DOI 10.17487/RFC2315
[RFC4880]
J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer "OpenPGP Message Format" RFC 4880 DOI 10.17487/RFC4880
[RFC5869]
H. Krawczyk and P. Eronen "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)" RFC 5869 DOI 10.17487/RFC5869
[RFC7159]
T. Bray "The JavaScript Object Notation (JSON) Data Interchange Format" RFC 7159 DOI 10.17487/RFC7159
[RFC7517]
M. Jones "JSON Web Key (JWK)" RFC 7517 DOI 10.17487/RFC7517
[RFC3394]
J. Schaad and R. Housley "Advanced Encryption Standard (AES) Key Wrap Algorithm" RFC 3394 DOI 10.17487/RFC3394
[RFC7518]
M. Jones "JSON Web Algorithms (JWA)" RFC 7518 DOI 10.17487/RFC7518
[RFC2119]
S. Bradner "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 RFC 2119 DOI 10.17487/RFC2119
[RFC4949]
R. Shirey "Internet Security Glossary, Version 2" FYI 36 RFC 4949 DOI 10.17487/RFC4949
[draft-hallambaker-jsonbcd]
Phillip Hallam-Baker "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D" Internet-Draft draft-hallambaker-jsonbcd-13 <http://www.ietf.org/internet-drafts/draft-hallambaker-jsonbcd-13.txt>
[draft-hallambaker-udf]
Phillip Hallam-Baker "Uniform Data Fingerprint (UDF)" Internet-Draft draft-hallambaker-udf-10 <http://www.ietf.org/internet-drafts/draft-hallambaker-udf-10.txt>
[IANAJOSE]
"[Reference Not Found!]"

Informative References

[Davis2001]
Don Davis "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML"

Author's Address


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