Network Working Group P. M. Hallam-Baker Internet-Draft ThresholdSecrets.com Intended status: Informational 6 October 2025 Expires: 9 April 2026 Data At Rest Envelope (DARE) draft-hallambaker-dare-00 Abstract This document describes the Data At Rest Envelope (DARE) Envelope and Sequence. The DARE Envelope syntax is used to package plaintext or encrypted content payload and metadata with JOSE decryption and signature data authenticating the payload and metadata. The DARE Sequence format comprises a sequence of DARE Envelopes. The binary encoding of DARE envelopes allows compact encoding of encrypted and signed payloads of unknown length in a single pass with minimal overhead. The binary encoding of DARE sequences is designed to support an append only write mode and efficient reading in either the forwards or backwards directions. The JSON encoding of DARE Envelopes and sequences allows envelopes and sequences to be incorporated in other JSON objects. This document does not cover construction of indexes or signatures over multiple entries in a sequence. 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 9 April 2026. Hallam-Baker Expires 9 April 2026 [Page 1] Internet-Draft Data At Rest Envelope October 2025 Copyright Notice Copyright (c) 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Serialization . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. JSON Serialization . . . . . . . . . . . . . . . . . 5 1.1.2. Binary Serialization . . . . . . . . . . . . . . . . 5 1.2. JOSE Signature and Encryption . . . . . . . . . . . . . . 6 1.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . 7 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Related Specifications . . . . . . . . . . . . . . . . . 7 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 8 2.3. Defined terms . . . . . . . . . . . . . . . . . . . . . . 8 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Security Enhancements . . . . . . . . . . . . . . . . 10 3.2. DARE Sequence . . . . . . . . . . . . . . . . . . . . . . 10 4. Serialization . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. JSON Serialization . . . . . . . . . . . . . . . . . . . 11 4.1.1. Dare Envelope . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Dare Sequence . . . . . . . . . . . . . . . . . . . . 12 4.2. Binary Serialization . . . . . . . . . . . . . . . . . . 12 4.2.1. Type Identifier . . . . . . . . . . . . . . . . . . . 13 4.2.2. Varint . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Known Length Field . . . . . . . . . . . . . . . . . 14 4.2.4. Variable Length Field . . . . . . . . . . . . . . . . 14 4.2.5. Frame wrapper . . . . . . . . . . . . . . . . . . . . 15 4.2.6. Envelope Serialization . . . . . . . . . . . . . . . 15 4.2.7. Sequence Serialization . . . . . . . . . . . . . . . 15 5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Algorithms Suites . . . . . . . . . . . . . . . . . . . . 16 5.2. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Exchanged Key Generation . . . . . . . . . . . . . . 17 5.2.2. Recipient Data Generation . . . . . . . . . . . . . . 18 5.3. Payload Encryption . . . . . . . . . . . . . . . . . . . 19 5.3.1. Encryption Parameters Derivation . . . . . . . . . . 19 5.3.2. Secure salt construction . . . . . . . . . . . . . . 19 5.3.3. Salt erasure . . . . . . . . . . . . . . . . . . . . 19 Hallam-Baker Expires 9 April 2026 [Page 2] Internet-Draft Data At Rest Envelope October 2025 5.4. Payload Format . . . . . . . . . . . . . . . . . . . . . 20 6. Signature . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Signature Preamble . . . . . . . . . . . . . . . . . . . 21 6.2. Calculating the Signature Value . . . . . . . . . . . . . 22 6.2.1. Signature Manifest . . . . . . . . . . . . . . . . . 22 6.2.2. Context String . . . . . . . . . . . . . . . . . . . 23 6.2.3. Example: . . . . . . . . . . . . . . . . . . . . . . 23 6.2.4. Signatures Header . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 25 7.1.1. Salt Reuse . . . . . . . . . . . . . . . . . . . . . 25 7.1.2. Exchanged Key Construction . . . . . . . . . . . . . 25 7.1.3. Side Channel . . . . . . . . . . . . . . . . . . . . 25 7.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2.1. Malicious Frame Length Indications . . . . . . . . . 25 7.2.2. Semantic Substitution Attack . . . . . . . . . . . . 25 7.3. Availability . . . . . . . . . . . . . . . . . . . . . . 25 7.3.1. Resource Exhaustion . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. Appendix A: Cryptographic Keys Used in Examples . . . . . . . 26 11. Appendix B: DARE Envelope Examples and Test Vectors . . . . . 26 11.1. Plaintext Unsigned . . . . . . . . . . . . . . . . . . . 26 11.2. Encrypted Unsigned . . . . . . . . . . . . . . . . . . . 26 11.3. Plaintext Signed . . . . . . . . . . . . . . . . . . . . 26 11.4. Encrypted Signed . . . . . . . . . . . . . . . . . . . . 26 12. Appendix C: DARE Sequence Examples and Test Vectors . . . . . 26 13. Appendix D: Outstanding Issues . . . . . . . . . . . . . . . 26 14. Normative References . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document describes the Data At Rest Envelope (DARE) Envelope and Sequence. The DARE Envelope syntax is used to package plaintext or encrypted content payload and metadata with JOSE decryption and signature data authenticating the payload and metadata. The DARE Sequence format comprises a sequence of DARE Envelopes. Two serializations are defined, a JSON serialization allowing envelopes and sequences to be included in other JSON objects and a binary serialization employing a simple {length, data} approach. This avoids the overhead of Base64 encoding signed and encrypted components. The envelope and sequence serializations are optimized for different purposes: Hallam-Baker Expires 9 April 2026 [Page 3] Internet-Draft Data At Rest Envelope October 2025 * The DARE envelope binary serialization allows payloads of unknown length to be efficiently encoded in a single pass with bounded memory overhead. * The DARE sequence binary serialization is designed to support append only writes and sequential reads in either the forward or the reverse direction. The envelope and sequence approaches are complimentary in that enveloped data MAY be efficiently added to a sequence and an individual entry in a sequence MAY be extracted as an envelope. A DARE Envelope is a sequence of exactly four fields: * Unsigned header * Signed header * Encrypted or plaintext payload * Trailer The unsigned header contains all the information required to process the signed header and payload. This includes the decryption information (if required) and the digest algorithm used to process the payload (if required). The signature value itself MAY be specified in either the unsigned header or the trailer. A DARE Sequence is a sequence of DARE envelope entries in which each entry contains exactly three fields, the contents of the unsigned header and trailer being combined: * Unsigned header * Signed header * Encrypted or plaintext payload 1.1. Serialization Two serialization formats are supported, a JSON serialization to allow DARE data to be exchanged within JSON objects and a binary serialization that avoids the need for Base64 encoding of cryptographic inputs and outputs. Unlike CBOR and the numerous flavors of 'Binary JSON' encodings, the DARE binary serialization is limited to specifying opaque binary blobs containing either JSON objects (headers, trailers) or payload data. Hallam-Baker Expires 9 April 2026 [Page 4] Internet-Draft Data At Rest Envelope October 2025 1.1.1. JSON Serialization The JSON serialization of a DARE envelope consists of an array of four entries in which the unsigned header and trailer are represented as a JSON object and the signed header and payload are represented as a string containing the Base64 encoding of the field. Minimal DARE Envelope: Envelope [null, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3QgZm9yIERhdGEgQXQgUmVzdCBFbnZlbG9wZQ", null ] The envelope serialization is designed to allow efficient encoding of streamed data of unknown length without the need for buffering with the signature information being split between the unsigned header and the trailer. The JSON serialization of a DARE sequence consists of a sequence of envelope entries. Each envelope containing three entries, an unsigned header, a signed header and a payload. Minimal DARE Sequence: Sequence [[null, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3QgZm9yIERhdGEgQXQgUmVzdCBFbnZlbG9wZQ", null ] ] The sequence serialization does not support separation of the signature data 1.1.2. Binary Serialization The binary serialization of the envelope consists of a Type Identifier sequence specifying a DARE Envelope followed by the same four entries from the JSON encoding encoded as a series of {length, data} items in which the length entries are encoded as variable length integers. Hallam-Baker Expires 9 April 2026 [Page 5] Internet-Draft Data At Rest Envelope October 2025 Minimal DARE Envelope: Envelope F8 00 18 7B 0A 20 20 22 63 74 79 22 3A 20 22 74 65 78 74 2F 70 6C 61 69 6E 22 7D 28 54 68 69 73 20 69 73 20 61 20 74 65 73 74 20 66 6F 72 20 44 61 74 61 20 41 74 20 52 65 73 74 20 45 6E 76 65 6C 6F 70 65 00 00 The binary serialization of a DARE Sequence follows the same pattern. The sequence begins with a Type Identifier sequence specifying a DARE Sequence followed by a sequence of wrapped frames, each consisting of three parts: * Forward length indicator * Envelope entry * Reverse length indicator The forward and reverse length indicators are both encoded as variable length integers but with the bytes of the reverse length indicator written backwards to enable the sequence to be read efficiently in either the forward or reverse direction. Minimal DARE Sequence: Sequence F9 00 40 43 00 18 7B 0A 20 20 22 63 74 79 22 3A 20 22 74 65 78 74 2F 70 6C 61 69 6E 22 7D 28 54 68 69 73 20 69 73 20 61 20 74 65 73 74 20 66 6F 72 20 44 61 74 61 20 41 74 20 52 65 73 74 20 45 6E 76 65 6C 6F 70 65 43 40 1.2. JOSE Signature and Encryption The DARE Envelope and Sequence constructions make use of JOSE signature and encryption but with modifications designed to support efficient processing of very large payloads and to facilitate use in incremental encryption of sequences. In the DARE model, an envelope presents all the information necessary to process the payload. In a typical workflow a processor needs to know what type of content is to be processed and which party vouches for it before processing the payload itself. The security enhancements supported are correspondingly limited, the only field that can be encrypted is the payload field and the signature value is always computed over a manifest consisting of the digest of the signed header and the digest of the envelope payload Hallam-Baker Expires 9 April 2026 [Page 6] Internet-Draft Data At Rest Envelope October 2025 value. If a different processing order is required, this is achieved by nesting. While nested constructions result in a very serious space overhead when using JSON encoding (33% increase in encoding size per pass), this is not a concern when the binary encoding is used. 1.3. Extensions The DARE Sequence Format is intended to be used as the basis for append only data structures offering a wide range of index and signature capabilities. These capabilities are outside the scope of this document as the range of approaches is very large. For example, a simple file archive format based on DARE Sequence might consist of an initial entry describing the collection as a whole, a sequence of entries containing data from a single file and a final entry containing an index of the entire collection and a signature over the list of digest values of each entry. This approach is optimal for read access but incurs a penalty on writes. Applications involving frequent write operations are likely to be better served by some form of Haber-Stornetta chained digest construction. Merkel Tree offers an acceptable balance of space efficiency, read performance and write performance for most purposes but is not necessarily ideal for all. A system logging application in which a server writes out reports on each transaction as it is performed, might be better served by a construction in which large numbers of entries are authenticated in a chained digest construction, the result of which is periodically signed by some relevant authority. 2. Definitions 2.1. Related Specifications The DARE Envelope and Sequence formats are based on the following existing standards and specifications. 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. Cryptographic algorithms The cryptographic algorithms and Hallam-Baker Expires 9 April 2026 [Page 7] Internet-Draft Data At Rest Envelope October 2025 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]. 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 Envelope A DARE Envelope that contains an Annotations field with at least one entry. Authentication Data A Message Authentication Code or authentication tag. Complete Envelope A DARE envelope that contains the key exchange information necessary for the intended recipient(s) to decrypt it. Detached Envelope A DARE envelope 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. 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 envelope. 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. Hallam-Baker Expires 9 April 2026 [Page 8] Internet-Draft Data At Rest Envelope October 2025 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 envelope. Related Envelope A set of DARE envelopes 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-mesh-udf] 3. Architecture DARE Envelope and DARE Sequence provide a means of efficiently serializing cryptographic payloads without the complexity of a full binary serialization format such as ASN.1 or CBOR. The cryptographic processing model follows the same pattern as JSON Web Encryption and JSON Web Signature but only supporting modern cryptographic algorithms and cipher modes: * Key Exchange mechanisms MUST support use of context information. * Signature mechanisms are used in pure mode. * Bulk encryption algorithms MUST support Authenticated Encryption with Associated Data (AEAD). 3.1. DARE Envelope A DARE envelope is a sequence of exactly four fields: Unsigned header MUST provide all the information required to begin processing the security enhancements to the payload. This includes the digest algorithm (if used) and the information required to decrypt the payload. MAY provide the signature and/or digest values. Signed header MAY be used to specify content metadata and/or any other information to be included within the scope of the signature. Hallam-Baker Expires 9 April 2026 [Page 9] Internet-Draft Data At Rest Envelope October 2025 Payload Contains the content data in the case of an unencrypted envelope and the encrypted content data and associated integrity tag (if required) in the case of encrypted data. Trailer MUST be present, even if empty. MAY be used to specify the signature value(s). Allowing signature data to be split between the unsigned header and the trailer allows implementations to support efficient single pass processing of streamed data of indeterminate length without the need to buffer large quantities of data. 3.1.1. Security Enhancements A core principle of the DARE architecture is that the security enhancements all pertain to the sequence of octets specified in the envelope payload. * If the envelope is signed, the signature is computed over the digest of the payload octets. That is, the ciphertext if the envelope is encrypted and the content data itself otherwise. * The headers and trailer are always cleartext. If an application requires the combination of encryption and a signature over the plaintext, this MAY be achieved through nesting with an outer encrypted envelope containing an inner envelope with the content plaintext and signature data. The same approach MAY be applied to encrypt content metadata. 3.2. DARE Sequence A DARE Sequence is a sequence of DARE Envelope entries consisting of three fields: Unsigned header MUST provide all the information required to process the security enhancements to the payload including the signature values. Signed header As for envelope Signed Header. Payload As for envelope payload except that the payload is encoded as a single chunk. Hallam-Baker Expires 9 April 2026 [Page 10] Internet-Draft Data At Rest Envelope October 2025 Splitting the signature data into two parts does not provide a useful advantage when processing sequence entries as each envelope entry is wrapped in a frame beginning and ending with fixed length specifiers to allow efficient read operations in either the forwards or reverse directions. 4. Serialization Two serialization formats are defined JSON Serialization Yada, 33% payload expansion Binary Serialization Very small overhead, minimum of 6 bytes, maximum of 40 bytes + 8 bytes per chunk. 4.1. JSON Serialization DARE Envelopes and Sequences are encoded as JSON sequences. 4.1.1. Dare Envelope A DARE Envelope in JSON serialization consists of a sequence with four entries: Unsigned header The unsigned header as a JSON object. Signed header A string containing the base64url encoded value of the JSON serialization of the signed header. Encrypted or plaintext payload A string containing the base64url encoded value of the JSON serialization of the payload. Trailer The trailer as a JSON object or the value null. For example, the following envelope contains a payload containing the text 'This is a test' and a header specifying that the content type is text/plain: Hallam-Baker Expires 9 April 2026 [Page 11] Internet-Draft Data At Rest Envelope October 2025 Envelope [null, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3Q", null ] Signed Header: { "cty": "text/plain"} Payload: This is a test 4.1.2. Dare Sequence A DARE Sequence in JSON serialization consists of a sequence of sequences. Each entry in the outer sequence containing a single envelope entry with exactly three fields: Unsigned header The unsigned header as a JSON object. Signed header A string containing the base64url encoded value of the JSON serialization of the signed header. Encrypted or plaintext payload A string containing the base64url encoded value of the JSON serialization of the payload. For example, the following sequence contains the envelopes presented in the previous two examples: Sequence [[null, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3QgZm9yIERhdGEgQXQgUmVzdCBFbnZlbG9wZQ", null ], [null, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3Q", null ] ] 4.2. Binary Serialization The binary serialization is the preferred serialization for DARE Envelopes and Sequences allowing use of cryptographic enhancements without the need for Base64 encoding of cryptographic inputs or outputs. Hallam-Baker Expires 9 April 2026 [Page 12] Internet-Draft Data At Rest Envelope October 2025 4.2.1. Type Identifier Type Identifiers are a sequence of zero or more odd octets (bit 0 is set) terminated by a single even octet (bit 0 is clear). This definition allows for an unlimited number of type identifiers to be defined. This document specifies the following Type Identifiers: +===========+==================================+ | Type | Purpose | +===========+==================================+ | [248] | DARE Envelope with JSON metadata | +-----------+----------------------------------+ | [249][00] | DARE Sequence with JSON metadata | +-----------+----------------------------------+ Table 1 The assignment of a single byte Type Identifier for DARE Envelope is justified by the need for compactness when used in nested encodings and to allow an entire envelope to specified in highly constrained messaging contexts (e.g. NFC tag, QR Code). Since it is the nature of sequences to contain large numbers of items, this use does not justify assignment of a single byte identifier. Applications MAY specify additional Type Identifiers to be used in place of the defaults above to specify particular data formats using DARE Encodings. For example, a content archive format based on DARE Sequence might use its own Type Identifier so that files can be identified as being in that particular format. 4.2.2. Varint It is intended that the variable length integer encoding used in DARE be the same as the encoding used in MOQ. Currently, MOQ uses the same encoding as QUIC which allows one byte encoding of the integers 0-63, but there is an outstanding proposal to switch to an encoding that would allow single byte encoding of the integers 0-127. When used to specify the lengths of DARE sequence frames, the octets of the final, varint are written in reverse order to allow the value to be read backwards. This encoding is referred to in this document as a _ravint_. Hallam-Baker Expires 9 April 2026 [Page 13] Internet-Draft Data At Rest Envelope October 2025 For convenience of readers, the QUIC definition, as used in the examples is presented here: The QUIC variable-length integer encoding reserves the two most significant bits of the first byte to encode the base-2 logarithm of the integer encoding length in bytes. The integer value is encoded on the remaining bits, in network byte order. This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. The following summarizes the encoding properties. +======+========+=============+=======================+ | 2MSB | Length | Usable Bits | Range | +======+========+=============+=======================+ | 00 | 1 | 6 | 0-63 | +------+--------+-------------+-----------------------+ | 01 | 2 | 14 | 0-16383 | +------+--------+-------------+-----------------------+ | 10 | 4 | 30 | 0-1073741823 | +------+--------+-------------+-----------------------+ | 11 | 8 | 62 | 0-4611686018427387903 | +------+--------+-------------+-----------------------+ Table 2 4.2.3. Known Length Field All fields in a DARE Envelope or DARE Sequence envelope entry except for the payload are serialized as known length fields. This comprises a Length: Data form as follows: Length A varint specifying the number of data octets that follow. Data A sequence of [length] octets. 4.2.4. Variable Length Field The payload field in a DARE Envelope or DARE Sequence envelope entry is serialized as a variable length field. This consists of zero or more known length fields of length greater than zero followed by the varint zero. The payload data consists of the concatenation of the data sections of the fixed length fields. Hallam-Baker Expires 9 April 2026 [Page 14] Internet-Draft Data At Rest Envelope October 2025 4.2.5. Frame wrapper A frame wrapper consists of a sequence of three entries: Forward length The number of octets of frame data Frame data entry A sequence of [Forward Length] octets. Reverse length number of octets of frame data written as a ravint. The value of the forward and reverse length indicators MUST be equal and MUST use the same number of encoding bytes. 4.2.6. Envelope Serialization For example, the binary encoding of the envelope shown in the previous example is: Envelope F8 00 18 7B 0A 20 20 22 63 74 79 22 3A 20 22 74 65 78 74 2F 70 6C 61 69 6E 22 7D 0E 54 68 69 73 20 69 73 20 61 20 74 65 73 74 00 00 4.2.7. Sequence Serialization For example, the binary encoding of the sequence shown in the previous example is: ~~~~ DARE Sequence in Binary Serialization: Sequence F9 00 40 43 00 18 7B 0A 20 20 22 63 74 79 22 3A 0. 69 73 20 69 73 20 61 20 74 65 73 74 20 66 6F 1. 20 44 61 74 61 20 41 74 20 52 65 73 74 20 45 2. E 76 65 6C 6F 70 65 43 40 29 00 18 7B 0A 20 20 3. 63 74 79 22 3A 20 22 74 65 78 74 2F 70 6C 61 4. 6E 22 7D 0E 54 68 69 73 20 69 73 20 61 20 74 5. 73 74 29 ~~~~ Hallam-Baker Expires 9 April 2026 [Page 15] Internet-Draft Data At Rest Envelope October 2025 5. Encryption DARE Encryption is designed to allow the use of a single key exchange to encrypt multiple envelope entries in a sequence. This avoids the computation and data overhead of repeated public key operations. JOSE Web Encryption supports use of the industry standard algorithms and approaches current at the time development began. DARE Encryption narrows the scope of the supported encryption algorithms and cipher modes to those considered state of the art in 2025. Instead of supporting many approaches to key exchange to avoid unnecessary processing, the same key exchange construction is used regardless of the number of recipients or the number of items to be encrypted: * The symmetric cipher mode used MUST provide Authenticated Encryption with Associated Data. * Support for the X25519 and X448 algorithms is REQUIRED The DARE encryption process has two stages: Key Exchange A random value that will become the exchanged key is generated using a sufficiently random technique and assigned a unique key identifier. An ephemeral public key pair is generated for each of the intended public encryption keys, the ephemeral key and encryption key is then used to establish a shared secret which is in turn used as an encryption key in a key wrapping operation on the exchanged key. Encryption Parameters Derivation A salt value is computed for each plaintext to be enciphered. It is sufficient that the salt value be guaranteed to be unique for each plaintext. A Key Derivation Function is used to combine the exchanged key and the salt to derive the encryption key and initialization vector to be used to encrypt the plaintext to obtain the ciphertext. 5.1. Algorithms Suites The algorithms used in these examples are sub-optimal. The following table shows the algorithms currently used and the proposed replacements. Hallam-Baker Expires 9 April 2026 [Page 16] Internet-Draft Data At Rest Envelope October 2025 +================+============================+=============+ | Purpose | Current | Proposed | +================+============================+=============+ | Key Identifier | UDF of PKIX subjectKeyInfo | UDF of JOSE | | | | Thumbprint | +----------------+----------------------------+-------------+ | Key Wrap | A256KW | A256GCMKW | +----------------+----------------------------+-------------+ | Key Derivation | SHAKE256 | SHAKE256 | | Function | | | +----------------+----------------------------+-------------+ +----------------+----------------------------+-------------+ Table 3 The rationale for these changes is that the SHAKE functions defined in SHA3 offer a considerably simpler approach than the HKDF approach used in the earlier version of DARE. 5.2. Key Exchange The key exchange process comprises the following steps: * A random value that will become the exchanged key is generated using a sufficiently random technique and assigned a unique key identifier. * An ephemeral public key pair is generated for each of the intended public encryption keys, the ephemeral key and encryption key is then used to establish a shared secret which is in turn used as an encryption key in a key wrapping operation on the exchanged key. 5.2.1. Exchanged Key Generation The exchanged key is a random sequence of octets containing at least as many bits as the symmetric cipher encryption key. Each exchanged key is assigned a unique identifier. The generation technique MUST ensure that the exchanged key is: * Sufficiently random * Does not leak information that might be useful to an attacker. Hallam-Baker Expires 9 April 2026 [Page 17] Internet-Draft Data At Rest Envelope October 2025 One means of satisfying these constraints is to use a strong Key Derivation Function to combine a random value provided by the platform with a secret value obtained from an independent source. This ensures that the exchanged key cannot be used as a side channel. [Move this to an appendix and reference each time] The Key Exchange information comprises: * The Exchanged Key Identifier [Optional]. * The list of Recipient Key Information entries. In the case that the exchanged key is only used to encrypt the payload of the envelope in which the Key Exchange Information is specified, the Exchanged Key Identifier MAY be omitted. Exchanged Key 14 C3 88 28 3F 62 FC 2D 09 77 5D 02 BD B3 79 8C F0 AF 8A 8B 4F 73 F0 2C CB ED D3 24 C6 E2 EF 80 Exchanged Key Identifier MCFX-KXN4-4Z6Q-D2OO-AJW2-FRLH-PDIV 5.2.2. Recipient Data Generation Recipient key information is calculated for each decryption key as follows: * An ephemeral key is generated with the same algorithm parameters as the decryption key. * The private component of the ephemeral key and the decryption key are used to compute the shared secret for the recipient. * A KDF is used to calculate the key wrap parameters for the recipient. * The key wrap algorithm and parameters are applied to the Exchanged Key to create the wrapped key data for the recipient. The recipient key information comprises: * The Recipient Key Identifier. * The public component of the ephemeral key. * The wrapped exchanged key data. * The key wrap algorithm identifier. Hallam-Baker Expires 9 April 2026 [Page 18] Internet-Draft Data At Rest Envelope October 2025 Recipient Public Key MAY4-Y4CP-ZNS5-XUIB-2ZYL-QVRI-UTC3 Ephemeral Key Pair: Envelope { "crv": "X25519", "Public": "HNDDtrjgh7VqFhMD2zMmxeoN3dan1Us-KWVyxLHcODE"} SharedSecret 19 6A 8E FF 00 81 D8 F8 CD E6 3C 1D 40 29 7D 4E 5D 4E F4 19 4D C6 CF CD 0E E9 7A 80 49 C6 0B 14 Wrapped Exchanged Key E8 BC CC 09 B1 AB 26 86 EB CF 90 F4 C7 3A AF D7 AE 73 B3 9C 87 B1 15 68 B9 58 BB D1 13 BD 82 B4 59 5D 77 FF BE 17 86 44 Recipient Information: Envelope { "kid": "MAY4-Y4CP-ZNS5-XUIB-2ZYL-QVRI-UTC3", "epk": { "PublicKeyECDH": { "crv": "X25519", "Public": "HNDDtrjgh7VqFhMD2zMmxeoN3dan1Us-KWVyxLHcODE"}}, "wmk": "6LzMCbGrJobrz5D0xzqv165zs5yHsRVouVi70RO9grRZXXf_vheGRA"} 5.3. Payload Encryption 5.3.1. Encryption Parameters Derivation The encryption key and nonce are obtained by applying a Key Derivation Function to the concatenation of a salt value and the exchanged key. The Associated Data used in the AEAD encryption algorithm is the Signed Header. 5.3.2. Secure salt construction Implementations MUST ensure that each salt value used is unique. Salt 93 E5 A0 2B 93 93 A6 6B 8B BF B7 B0 28 DF 00 F1 3E 69 47 6E AD FB 31 3E B2 C7 02 10 A4 84 2E 19 5.3.3. Salt erasure If the salt value contains sufficient unpredictable information, erasure of the salt value in a data sequence renders decryption of the payload value infeasible. Hallam-Baker Expires 9 April 2026 [Page 19] Internet-Draft Data At Rest Envelope October 2025 5.4. Payload Format The input to the KDF is the concatenation of the Salt value and the Exchanged Key: KDF Input 93 E5 A0 2B 93 93 A6 6B 8B BF B7 B0 28 DF 00 F1 3E 69 47 6E AD FB 31 3E B2 C7 02 10 A4 84 2E 19 14 C3 88 28 3F 62 FC 2D 09 77 5D 02 BD B3 79 8C F0 AF 8A 8B 4F 73 F0 2C CB ED D3 24 C6 E2 EF 80 Since we require a 256 bit key and 96 bit nonce, 352 bits of KDF output are required: KDF Output = SHAKE256(KDF Input,352) 7A E2 8F C3 A4 FE 57 FC CA C4 E5 D2 B3 4D CF F2 3F DC 51 8A FC D7 B7 D9 59 B3 29 37 CF 77 45 EA 0A D8 DA 5C 34 A1 45 5C EB D9 20 1E The first 96 bits of the output provide the nonce, the following 256 bits provide the key: Encryption Nonce 7A E2 8F C3 A4 FE 57 FC CA C4 E5 D2 Encryption Key B3 4D CF F2 3F DC 51 8A FC D7 B7 D9 59 B3 29 37 CF 77 45 EA 0A D8 DA 5C 34 A1 45 5C EB D9 20 1E The plaintext payload is the string 'This is a test'. The ciphertext is obtained by applying AES-GCM to the plaintext payload using the key and nonce derrived using the KDF and the Signed header as Associated Data. Associated Data 7B 0A 20 20 22 63 74 79 22 3A 20 22 74 65 78 74 2F 70 6C 61 69 6E 22 7D Ciphertext 7F 34 BA 07 B7 41 83 62 4A 50 1A 8C 4E 12 0E 53 FC 29 E6 5D BE 8B D5 39 12 A9 A0 84 10 01 97 B1 B0 43 F6 9A 8E 87 24 FB D7 8E A8 B8 71 93 CA 8C 4E 29 AA 23 3C 6C 33 01 The complete encryption envelope is: Hallam-Baker Expires 9 April 2026 [Page 20] Internet-Draft Data At Rest Envelope October 2025 DARE Envelope With Encrypted Payload: Envelope [{ "enc": "A256GCM", "Salt": "k-WgK5OTpmuLv7ewKN8A8T5pR26t-zE-sscCEKSELhk", "recipients": [{ "kid": "MAY4-Y4CP-ZNS5-XUIB-2ZYL-QVRI-UTC3", "epk": { "PublicKeyECDH": { "crv": "X25519", "Public": "HNDDtrjgh7VqFhMD2zMmxeoN3dan1Us-KWVyxLHcOD E"}}, "wmk": "6LzMCbGrJobrz5D0xzqv165zs5yHsRVouVi70RO9grRZXXf_v heGRA"} ]}, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "fzS6B7dBg2JKUBqMThIOU_wp5l2-i9U5EqmghBABl7GwQ_aajock-9eOqLhxk8 qMTimqIzxsMwE", null ] 6. Signature The DARE signature scheme is designed to provide a simple and efficient means of signing a DARE Envelope or Envelope Entry Payload and associated content metadata. As with the approach to encryption, the opportunity is taken to make use of the full capabilities of modern signature algorithms: * The signature algorithm MUST support context strings. * The signature value is computed over a manifest consisting of a digest algorithm identifier, the digest of the signed header, and the digest of the payload bytes using the pure version of the signature algorithm (not pre-hashed). The DARE signature approach intentionally removes much of the flexibility provided by the JWS signature approach. 6.1. Signature Preamble Signed DARE Envelopes MAY separate signature data presenting only the information required to process the signature * The digest algorithm used to digest the Signed Header and Payload. * The Key Identifier of the Signature Key * An application context specifier (optional) Hallam-Baker Expires 9 April 2026 [Page 21] Internet-Draft Data At Rest Envelope October 2025 Signature Preamble: Envelope { "signatures": [{ "dig": "SHA3512", "alg": "ED25519", "kid": "MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN"}]} 6.2. Calculating the Signature Value The signature algorithm takes three inputs: * The private signature key * The signature manifest * A Context String denoting the purpose for which the signature was created. 6.2.1. Signature Manifest The signature manifest consists of the concatenation of the following octet sequences: * The ASCII encoding of the digest algorithm identifier. * A zero octet. * The digest value of the unsigned header octets as specified in the envelope. * The digest value of the payload octets as specified in the envelope. Note that the signature value presented in DARE envelope is always a signature over the payload octets presented in that envelope. If the envelope is signed and encrypted, the signature value is calculated over the ciphertext, not the plaintext. If the application requires a signature over a plaintext payload, the only way this can be achieved using DARE envelope is to nest an envelope containing the signature information inside an envelope containing the encryption information. This approach has the advantage of ensuring that the signature information does not leak any information regarding the plaintext. The construction of DARE Envelope permits this to be achieved in a single pass provided that the encryption mode supports single pass processing. Hallam-Baker Expires 9 April 2026 [Page 22] Internet-Draft Data At Rest Envelope October 2025 6.2.2. Context String If the application context specifier is not specified, the context string is the string "DARE-Signature". Otherwise the context string is the concatenation of the string "DARE-Application:" and the application contact specifier. 6.2.3. Example: Signed Header Digest C5 13 F0 84 4F 74 3D 9B 50 F8 1B EB 06 41 2D AA C6 58 3D D5 F5 83 40 FA 15 D4 69 12 09 EB 2A 13 93 E2 F8 5B A8 56 F3 13 60 A8 23 EE 58 68 62 B1 14 BC 84 C9 58 1D 57 C5 FA 5D 71 D2 9F 9D B6 7E Payload Digest 95 94 53 1C F4 B5 84 AB AA CD 7C 93 BD 4E E1 00 0C 86 A5 84 5F E5 F3 DD 99 C1 4B 96 97 F7 1E 22 8B 1F 77 79 B9 C9 B9 C4 41 4C 05 F4 7D 29 1E 78 8F 28 C9 ED 88 AF 06 D0 9A 37 83 E7 65 48 35 CB Signature Manifest 53 48 41 33 35 31 32 00 C5 13 F0 84 4F 74 3D 9B 50 F8 1B EB 06 41 2D AA C6 58 3D D5 F5 83 40 FA 15 D4 69 12 09 EB 2A 13 93 E2 F8 5B A8 56 F3 13 60 A8 23 EE 58 68 62 B1 14 BC 84 C9 58 1D 57 C5 FA 5D 71 D2 9F 9D B6 7E C5 13 F0 84 4F 74 3D 9B 50 F8 1B EB 06 41 2D AA C6 58 3D D5 F5 83 40 FA 15 D4 69 12 09 EB 2A 13 93 E2 F8 5B A8 56 F3 13 60 A8 23 EE 58 68 62 B1 14 BC 84 C9 58 1D 57 C5 FA 5D 71 D2 9F 9D B6 7E ContextString 44 41 52 45 2D 53 69 67 6E 61 74 75 72 65 Signature Key Id MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN Signature Value F5 E6 FB 00 E1 46 C9 17 89 96 68 44 CC A1 3E 5F F6 DA 93 B8 B5 A6 A2 D0 6B 22 2B 96 FF E5 DA 90 AD E6 3B 76 2A EB A1 0C 01 D7 D5 1F 35 A5 F0 5E C5 E4 CF B5 C8 A2 4C DC BE 92 3D 18 9D 51 5D 0E 6.2.4. Signatures Header When specified in an Unsigned Header, the Signatures Header contains all the information specified in the signature preamble plus the signature values. When specified in a Trailer, the Signatures Header contains only the signature key identifiers and the corresponding signature values. Each signature entry consists of the following information: Hallam-Baker Expires 9 April 2026 [Page 23] Internet-Draft Data At Rest Envelope October 2025 * The Key Identifier of the Signature Key * The Digest Algorithm * The Signature Algorithm * The Signature Value Signature Trailer: Envelope { "signatures": [{ "dig": "SHA3512", "alg": "ED25519", "kid": "MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN", "signature": "9eb7AOFGyReJlmhEzKE-X_bak7i1pqLQayIrlv_l2pCt5jt2K uuhDAHX1R81pfBexeTPtciiTNy-kj0YnVFdDg"}]} The complete envelope is thus: Envelope [{ "signatures": [{ "dig": "SHA3512", "alg": "ED25519", "kid": "MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN"} ]}, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3QgZm9yIERhdGEgQXQgUmVzdCBFbnZlbG9wZQ", { "signatures": [{ "dig": "SHA3512", "alg": "ED25519", "kid": "MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN", "signature": "9eb7AOFGyReJlmhEzKE-X_bak7i1pqLQayIrlv_l2pC t5jt2KuuhDAHX1R81pfBexeTPtciiTNy-kj0YnVFdDg"} ]} ] When a signed envelope is added to a sequence, the signature properties from the Header and Trailer are combined: Hallam-Baker Expires 9 April 2026 [Page 24] Internet-Draft Data At Rest Envelope October 2025 Signature In Sequence: Sequence [[{ "signatures": [{ "dig": "SHA3512", "alg": "ED25519", "kid": "MBN5-OA3P-7DRU-FLK3-PTP2-OAUC-PXJN", "signature": "9eb7AOFGyReJlmhEzKE-X_bak7i1pqLQayIrlv_l2 pCt5jt2KuuhDAHX1R81pfBexeTPtciiTNy-kj0YnVFdDg"} ]}, "ewogICJjdHkiOiAidGV4dC9wbGFpbiJ9", "VGhpcyBpcyBhIHRlc3QgZm9yIERhdGEgQXQgUmVzdCBFbnZlbG9wZQ", null ] ] 7. Security Considerations 7.1. Confidentiality 7.1.1. Salt Reuse 7.1.2. Exchanged Key Construction 7.1.3. Side Channel 7.2. Integrity 7.2.1. Malicious Frame Length Indications 7.2.2. Semantic Substitution Attack 7.3. Availability 7.3.1. Resource Exhaustion 8. IANA Considerations [Create registry of DARE encoded object types, prepopulate with code points for JOSE envelope and sequence, reserving code points for CBOR, XML and ASN.1] [Add entries for any new JOSE headers] [New JOSE Header - witness] [Assign the Type Indicator registrations] Hallam-Baker Expires 9 April 2026 [Page 25] Internet-Draft Data At Rest Envelope October 2025 9. Acknowledgements The name Data At Rest Encryption was proposed by Melhi Abdulhayo?lu. 10. Appendix A: Cryptographic Keys Used in Examples Recipient Public Key : Envelope { "crv": "X25519", "Public": "rlq57sHnbb_f8SoOid_YgYlqLA-F0U2jSeXG5AfNkWI"} Signature Key: Envelope 11. Appendix B: DARE Envelope Examples and Test Vectors 11.1. Plaintext Unsigned * Encryption Algorithm: none 11.2. Encrypted Unsigned * Encryption Algorithm: X25519 * Encryption Algorithm: none 11.3. Plaintext Signed * Encryption Algorithm: none * Encryption Algorithm: Ed25519 11.4. Encrypted Signed * Encryption Algorithm: X25519 * Encryption Algorithm: Ed25519 12. Appendix C: DARE Sequence Examples and Test Vectors 13. Appendix D: Outstanding Issues The following issues need to be addressed. Hallam-Baker Expires 9 April 2026 [Page 26] Internet-Draft Data At Rest Envelope October 2025 +================+================================================+ | Issue | Description | +================+================================================+ | Algorithms | Need to audit the algorithm choices | +----------------+------------------------------------------------+ | Test Vectors | Produce test vectors for additional algorithms | +----------------+------------------------------------------------+ | Extensions | Need work | +----------------+------------------------------------------------+ | Security | Need work | | Considerations | | +----------------+------------------------------------------------+ | IANA | Need work | | Considerations | | +----------------+------------------------------------------------+ | Thumbprints | Use UDFs of thumbprints | +----------------+------------------------------------------------+ +----------------+------------------------------------------------+ +----------------+------------------------------------------------+ +----------------+------------------------------------------------+ Table 4 14. Normative References [draft-hallambaker-mesh-udf] Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-19, 14 October 2024, . [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, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . Hallam-Baker Expires 9 April 2026 [Page 27] Internet-Draft Data At Rest Envelope October 2025 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [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, . Author's Address Phillip Hallam-Baker ThresholdSecrets.com Email: phill@hallambaker.com Hallam-Baker Expires 9 April 2026 [Page 28]