Network Working Group                                    P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Informational                             July 13, 2018
Expires: January 14, 2019


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

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 January 14, 2019.

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 January 14, 2019                [Page 1]


Internet-Draft                DARE Message                     July 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  . . . . . . . . . . . . . . .  12
       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 . . . . . . . . . . .  15
       5.2.5.  Signature validation  . . . . . . . . . . . . . . . .  16
     5.3.  Detached Messages . . . . . . . . . . . . . . . . . . . .  16
     5.4.  Cloaked Messages  . . . . . . . . . . . . . . . . . . . .  16
   6.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Field: kwd  . . . . . . . . . . . . . . . . . . . . . . .  16
   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 January 14, 2019                [Page 2]


Internet-Draft                DARE Message                     July 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  . . . . . . . . . . . . . .  19
       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  . . . . . . . . . . . . . . . . . . . . . . . .  26

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 January 14, 2019                [Page 3]


Internet-Draft                DARE Message                     July 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 January 14, 2019                [Page 4]


Internet-Draft                DARE Message                     July 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 January 14, 2019                [Page 5]


Internet-Draft                DARE Message                     July 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 January 14, 2019                [Page 6]


Internet-Draft                DARE Message                     July 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 January 14, 2019                [Page 7]


Internet-Draft                DARE Message                     July 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 January 14, 2019                [Page 8]


Internet-Draft                DARE Message                     July 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.

   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 three
   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

   Body  The body is encoded as a base64url encoded string




Hallam-Baker            Expires January 14, 2019                [Page 9]


Internet-Draft                DARE Message                     July 2018


   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.

   o  Message Authentication Codes are supported as a means of
      authentication.






Hallam-Baker            Expires January 14, 2019               [Page 10]


Internet-Draft                DARE Message                     July 2018


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.

   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.





Hallam-Baker            Expires January 14, 2019               [Page 11]


Internet-Draft                DARE Message                     July 2018


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

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:



Hallam-Baker            Expires January 14, 2019               [Page 12]


Internet-Draft                DARE Message                     July 2018


   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.

   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.





Hallam-Baker            Expires January 14, 2019               [Page 13]


Internet-Draft                DARE Message                     July 2018


   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.

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



Hallam-Baker            Expires January 14, 2019               [Page 14]


Internet-Draft                DARE Message                     July 2018


   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.

5.2.4.  Process Enhanced Data Sequences

   Having recovered the Master Key, the recipient can decrypt whichever
   Enhanced Data Sequences it requires.







Hallam-Baker            Expires January 14, 2019               [Page 15]


Internet-Draft                DARE Message                     July 2018


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.

6.  Algorithms

6.1.  Field: kwd

   The key wrapping and derivation algorithms.





Hallam-Baker            Expires January 14, 2019               [Page 16]


Internet-Draft                DARE Message                     July 2018


   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.

   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




Hallam-Baker            Expires January 14, 2019               [Page 17]


Internet-Draft                DARE Message                     July 2018


   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?

   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




Hallam-Baker            Expires January 14, 2019               [Page 18]


Internet-Draft                DARE Message                     July 2018


      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

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.




Hallam-Baker            Expires January 14, 2019               [Page 19]


Internet-Draft                DARE Message                     July 2018


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 January 14, 2019               [Page 20]


Internet-Draft                DARE Message                     July 2018


   {
     "PrivateKeyDH":{
       "kid":"MDD7L-HSRZY-6DYKQ-7FHIW-PS6I5-VOC4F-A",
       "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
       "Public":"LnHmYAeS4RrQ5rOe2p7UlMpgqFs84ySt0vHm7XexZXjuywdJ6sMG9
     _CPAOC6ZSeRgKhM7QkNeYbTutFKJQwOE0KJ8inMFXFHVQ4_xOy6tJOLJg6Km6QNHv
     GDNH2yOZk_r5pSEysWr8p50QZXP5vkLtMlqHlwcwQ5NsZJgedW_6lL-9T8n6oOQTH
     9ZkkDNfILNV7Nr1iSJvaZx56u-dpWLnI-0yRbr9EKEmQf3b-MU4dOIj3IclcXXLxU
     mxG44TkRyGfqVLvg4llCYaicGE1SESrdy0T_VMxNn9NO3nmV6tGgVrE6jad7-y7w-
     PAoMoSZ7PUk-o19hzk58kVftjd1HQ",
       "Private":"SZzvjY85RigTp2CTu_N7M-CxOZsFAkVyd9Da-tQV3A6lsNj7On2e
     JN61DOlt1xwSvcXUSTzx29b4LskAWvlOamEytaYq9rmlEWt_boeP9KLTHFLlfEmno
     -xiP3ZBdOD5NNNjJBE6DYc6eteXWIG-JHMVxF70NHu_fS9kFqh_gfLHqTXDAVrL-L
     ZNTybnAJCW38elZbwfERfS13Dmlc9y9TDRJzhMgviApb4l07rrgNHMZpusgKZMtgy
     s9odayl6ar-smLfPI18FjwVzot-Pvs-r7sQJlyede-tUhkRzSqbit4fbzpVdPxyJw
     nQycarQd7BLEVu8YSfxSzsLTpJtdSQ"}}

                                 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":[{},
       "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
     BibG9ja3M"
       ]}

                                 Figure 5





Hallam-Baker            Expires January 14, 2019               [Page 21]


Internet-Draft                DARE Message                     July 2018


11.2.  Plaintext Message with EDS

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

   {
     "DAREMessage":[{
         "edss":["iAEAiC1TdWJqZWN0OiBNZXNzYWdlIG1ldGFkYXRhIHNob3VsZCBiZ
     SBlbmNyeXB0ZWSIAA",
           "iAEAiAoyMDE4LTAyLTAxiAA"
           ]},
       "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
     BibG9ja3M"
       ]}

                                 Figure 6

11.3.  Encrypted Message

   The creator generates a master session key:


     0A CE 34 A2  D3 12 1C 06  B0 72 FB 4C  50 47 1F B6
     19 0B E0 06  C5 5E 70 F9  CC 6F 11 D6  71 52 37 26

                                 Figure 7

   The creator generates an ephemeral key:

   {
     "PrivateKeyDH":{
       "kid":"MADSN-KKGHV-3TV37-2U2VW-UT6BX-WTYML-A",
       "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
       "Public":"zTwurVdG03ELMaB-hAI-pW_Prin0OfQZBpTmaXbnZo0G1j22hcr7R
     UYoluMViJCsuQBH14Qrxv7LcCO6vM1kU2mQsZdf71gkQ7MhPLgNknwUE8T-mOP_qn
     rIe3gOjobKKbT9g_Nv1l0gmPSN_R1-8XxHBCSSVcygQ1pZ0KfXReDwAoNzDm-jjh3
     6sQqbBFrJWWjOBWNi56rkcMavHXmVgK3MOdKAgyeO3_Q4ZwtQ-Pc8em0reJCjcIUR
     b_k8m5D3uG9cQQ6sFn7cFp66lExDOcIyTYqqFsp7ss7PJn3zCX_HQoMpm34-1FwM6
     BOOWd9LG8uXVn_guJV4BM80JIBUVg",
       "Private":"ZJeUOQwkzcke1RLZnxz-mSB0N2jRA606BoKFoaI4sG2UD-qTv1d0
     FzU2J5U8Td38TUNtf9Cdt-lMMzD3N8ZGqoo0UsyumyeckiMzZodKIstHiKvdaGvRO
     vrQBQVnjF-g_NCpSj-Y0sRyJfNcGefmE443QwL-E_rYOh3Azi4zLwtWOIDj_Ya3ii
     sBu9cFEnasSYTT4p1RoVfLSvMVQU_F-cOqQRpFEKYNZKSAxrqlOJ24X0CHwiNYqHS
     PcETUmO77Bh-1YyasLlUgVjK8cEI3SuHn6L2wuq6y0yfAErIcEq2zWQbgC7maX24M
     cPhNXE22_it-DEoKXKFKTeYJn-7l7AA"}}

                                 Figure 8




Hallam-Baker            Expires January 14, 2019               [Page 22]


Internet-Draft                DARE Message                     July 2018


   The key agreement value is calculated:

   249775263816487483931896010299097564854454347516831840756453977145862
   774009093007097779281910260145784886411647160269599615422500039748492
   444179619394328116490036117795948984185835682430902489631851978778082
   278854607598715893992438196224826238817756762677634888396284748681710
   943583624743939396835460628460290095419061008573813653124401427422872
   330169175818408031753756082153864435963738210046522095495994111881975
   127191421307826283359719837317669393381464188247341690048493579073631
   562885821436525380302849739889927476167265009606070422023062572146801
   002551443229480737511384690916393012771976659473341526524

                                 Figure 9

   The key agreement value is used as the input to a HKDF key derivation
   function with the info parameter "master".


     FA CD 02 3D  07 66 BE 56  84 2E 85 8A  E1 8A 54 AB
     C2 67 5F E4  40 DC CD 0E  D8 2D 14 AF  7B A1 64 EA

                                 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 40 FE 3E  DB 48 01 BB  46 32 95 31  D2 2B 32 E0
     D5 93 8D 3C  25 80 7E E5  6F 46 BD 84  B8 C8 86 1F
     45 88 F2 3C  CC F6 3F 13  17 AD 5E 1B  09 53 6C 88
     04 AF 31 F9  CE 4F 7F BD  26 C6 65 11  48 B2 74 8B
     38 86

                                 Figure 12



Hallam-Baker            Expires January 14, 2019               [Page 23]


Internet-Draft                DARE Message                     July 2018


   The completed message is:

   {
     "DAREMessage":[{
         "recipients":[{
             "kid":"MDD7L-HSRZY-6DYKQ-7FHIW-PS6I5-VOC4F-A",
             "epk":{
               "PublicKeyDH":{
                 "kid":"MADSN-KKGHV-3TV37-2U2VW-UT6BX-WTYML-A",
                 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA",
                 "Public":"zTwurVdG03ELMaB-hAI-pW_Prin0OfQZBpTmaXbnZo0
     G1j22hcr7RUYoluMViJCsuQBH14Qrxv7LcCO6vM1kU2mQsZdf71gkQ7MhPLgNknwU
     E8T-mOP_qnrIe3gOjobKKbT9g_Nv1l0gmPSN_R1-8XxHBCSSVcygQ1pZ0KfXReDwA
     oNzDm-jjh36sQqbBFrJWWjOBWNi56rkcMavHXmVgK3MOdKAgyeO3_Q4ZwtQ-Pc8em
     0reJCjcIURb_k8m5D3uG9cQQ6sFn7cFp66lExDOcIyTYqqFsp7ss7PJn3zCX_HQoM
     pm34-1FwM6BOOWd9LG8uXVn_guJV4BM80JIBUVg"}},
             "wmk":"jjd4k069eAyUZUBB6RizaPW9u5b_Fq6PPc9Xk9HfjCx6J1HIwU
     mLdA"}
           ]},
       "iED-PttIAbtGMpUx0isy4NWTjTwlgH7lb0a9hLjIhh9FiPI8zPY_ExetXhsJU2
     yIBK8x-c5Pf70mxmURSLJ0iziG"
       ]}

                                 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-12 (work in progress), May 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.



Hallam-Baker            Expires January 14, 2019               [Page 24]


Internet-Draft                DARE Message                     July 2018


   [RFC2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax
              Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998.

   [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







Hallam-Baker            Expires January 14, 2019               [Page 25]


Internet-Draft                DARE Message                     July 2018


Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com













































Hallam-Baker            Expires January 14, 2019               [Page 26]