< draft-hallambaker-mesh-dare-01.txt   draft-hallambaker-mesh-dare-02.txt >
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft April 4, 2019 Internet-Draft July 3, 2019
Intended status: Informational Intended status: Informational
Expires: October 6, 2019 Expires: January 4, 2020
Mathematical Mesh Part III : Data At Rest Encryption (DARE) Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)
draft-hallambaker-mesh-dare-01 draft-hallambaker-mesh-dare-02
Abstract Abstract
This document describes the Data At Rest Encryption (DARE) Message This document describes the Data At Rest Encryption (DARE) Envelope
and Container syntax. and Container syntax.
The DARE Message syntax is used to digitally sign, digest, The DARE Envelope syntax is used to digitally sign, digest,
authenticate, or encrypt arbitrary message content. authenticate, or encrypt arbitrary content data.
The DARE Container syntax describes an append-only sequence of data The DARE Container syntax describes an append-only sequence of
frames, each containing a DARE Message. DARE Containers may support entries, each containing a DARE Envelope. DARE Containers may
cryptographic integrity verification of the entire data container support cryptographic integrity verification of the entire data
content by means of a Merkle tree. container content by means of a Merkle tree.
This document is also available online at This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [1] . http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [1] .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Encryption and Integrity . . . . . . . . . . . . . . . . 4 1.1. Encryption and Integrity . . . . . . . . . . . . . . . . 5
1.1.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 5 1.1.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 5
1.1.2. Data Erasure . . . . . . . . . . . . . . . . . . . . 6 1.1.2. Data Erasure . . . . . . . . . . . . . . . . . . . . 6
1.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. Signing Individual Plaintext Messages . . . . . . . . 7 1.2.1. Signing Individual Plaintext Envelopes . . . . . . . 7
1.2.2. Signing Individual Encrypted Messages . . . . . . . . 7 1.2.2. Signing Individual Encrypted Envelopes . . . . . . . 7
1.2.3. Signing Sequences of Messages . . . . . . . . . . . . 7 1.2.3. Signing sequences of envelopes . . . . . . . . . . . 8
1.3. Container . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Container . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1. Container Format . . . . . . . . . . . . . . . . . . 8 1.3.1. Container Format . . . . . . . . . . . . . . . . . . 8
1.3.2. Write . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.2. Write . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3. Encryption and Authentication . . . . . . . . . . . . 9 1.3.3. Encryption and Authentication . . . . . . . . . . . . 10
1.3.4. Integrity and Signature . . . . . . . . . . . . . . . 10 1.3.4. Integrity and Signature . . . . . . . . . . . . . . . 10
1.3.5. Redaction . . . . . . . . . . . . . . . . . . . . . . 10 1.3.5. Redaction . . . . . . . . . . . . . . . . . . . . . . 11
1.3.6. Alternative approaches . . . . . . . . . . . . . . . 11 1.3.6. Alternative approaches . . . . . . . . . . . . . . . 11
1.3.7. Efficiency . . . . . . . . . . . . . . . . . . . . . 11 1.3.7. Efficiency . . . . . . . . . . . . . . . . . . . . . 12
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Related Specifications . . . . . . . . . . . . . . . . . 12 2.1. Related Specifications . . . . . . . . . . . . . . . . . 12
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 13 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 13
2.3. Defined terms . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Defined terms . . . . . . . . . . . . . . . . . . . . . . 13
3. DARE Message Architecture . . . . . . . . . . . . . . . . . . 14 3. DARE Envelope Architecture . . . . . . . . . . . . . . . . . 14
3.1. Processing Considerations . . . . . . . . . . . . . . . . 15 3.1. Processing Considerations . . . . . . . . . . . . . . . . 15
3.2. Content Metadata and Annotations . . . . . . . . . . . . 15 3.2. Content Metadata and Annotations . . . . . . . . . . . . 15
3.3. Encoded Data Sequence . . . . . . . . . . . . . . . . . . 16 3.3. Encoded Data Sequence . . . . . . . . . . . . . . . . . . 16
3.4. Encryption and Integrity . . . . . . . . . . . . . . . . 17 3.4. Encryption and Integrity . . . . . . . . . . . . . . . . 17
3.4.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 17 3.4.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 18
3.4.2. Key Identifiers . . . . . . . . . . . . . . . . . . . 18 3.4.2. Key Identifiers . . . . . . . . . . . . . . . . . . . 18
3.4.3. Salt Derivation . . . . . . . . . . . . . . . . . . . 19 3.4.3. Salt Derivation . . . . . . . . . . . . . . . . . . . 19
3.4.4. Key Derivation . . . . . . . . . . . . . . . . . . . 19 3.4.4. Key Derivation . . . . . . . . . . . . . . . . . . . 19
3.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 20 3.6. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.1. Field: kwd . . . . . . . . . . . . . . . . . . . . . 20 3.6.1. Field: kwd . . . . . . . . . . . . . . . . . . . . . 20
4. DARE Container Architecture . . . . . . . . . . . . . . . . . 21 4. DARE Container Architecture . . . . . . . . . . . . . . . . . 21
4.1. Container Navigation . . . . . . . . . . . . . . . . . . 21 4.1. Container Navigation . . . . . . . . . . . . . . . . . . 21
4.1.1. Tree . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Tree . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Position Index . . . . . . . . . . . . . . . . . . . 22 4.1.2. Position Index . . . . . . . . . . . . . . . . . . . 22
4.1.3. Metadata Index . . . . . . . . . . . . . . . . . . . 22 4.1.3. Metadata Index . . . . . . . . . . . . . . . . . . . 22
4.2. Integrity Mechanisms . . . . . . . . . . . . . . . . . . 22 4.2. Integrity Mechanisms . . . . . . . . . . . . . . . . . . 23
4.2.1. Digest Chain calculation . . . . . . . . . . . . . . 23 4.2.1. Digest Chain calculation . . . . . . . . . . . . . . 23
4.2.2. Binary Merkle tree calculation . . . . . . . . . . . 23 4.2.2. Binary Merkle tree calculation . . . . . . . . . . . 23
4.2.3. Signature . . . . . . . . . . . . . . . . . . . . . . 23 4.2.3. Signature . . . . . . . . . . . . . . . . . . . . . . 23
5. DARE Message Schema . . . . . . . . . . . . . . . . . . . . . 24 5. DARE Message Schema . . . . . . . . . . . . . . . . . . . . . 24
5.1. Message Classes . . . . . . . . . . . . . . . . . . . . . 24 5.1. Message Classes . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Structure: DareMessageSequence . . . . . . . . . . . 24 5.1.1. Structure: DareMessageSequence . . . . . . . . . . . 24
5.2. Header and Trailer Classes . . . . . . . . . . . . . . . 25 5.2. Header and Trailer Classes . . . . . . . . . . . . . . . 25
5.2.1. Structure: DareTrailer . . . . . . . . . . . . . . . 25 5.2.1. Structure: DareTrailer . . . . . . . . . . . . . . . 25
5.2.2. Structure: DareHeader . . . . . . . . . . . . . . . . 25 5.2.2. Structure: DareHeader . . . . . . . . . . . . . . . . 25
5.3. Cryptographic Data . . . . . . . . . . . . . . . . . . . 27 5.3. Cryptographic Data . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 32 skipping to change at page 3, line 32
6.1.1. Structure: ContainerEntry . . . . . . . . . . . . . . 28 6.1.1. Structure: ContainerEntry . . . . . . . . . . . . . . 28
6.1.2. Structure: ContainerHeaderFirst . . . . . . . . . . . 28 6.1.2. Structure: ContainerHeaderFirst . . . . . . . . . . . 28
6.1.3. Structure: ContainerHeader . . . . . . . . . . . . . 29 6.1.3. Structure: ContainerHeader . . . . . . . . . . . . . 29
6.2. Content Metadata Structure . . . . . . . . . . . . . . . 30 6.2. Content Metadata Structure . . . . . . . . . . . . . . . 30
6.2.1. Structure: ContentMeta . . . . . . . . . . . . . . . 30 6.2.1. Structure: ContentMeta . . . . . . . . . . . . . . . 30
6.3. Index Structures . . . . . . . . . . . . . . . . . . . . 30 6.3. Index Structures . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Structure: ContainerIndex . . . . . . . . . . . . . . 30 6.3.1. Structure: ContainerIndex . . . . . . . . . . . . . . 30
6.3.2. Structure: IndexPosition . . . . . . . . . . . . . . 30 6.3.2. Structure: IndexPosition . . . . . . . . . . . . . . 30
6.3.3. Structure: KeyValue . . . . . . . . . . . . . . . . . 31 6.3.3. Structure: KeyValue . . . . . . . . . . . . . . . . . 31
6.3.4. Structure: IndexMeta . . . . . . . . . . . . . . . . 31 6.3.4. Structure: IndexMeta . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Dare Container Applications . . . . . . . . . . . . . . . . . 31
7.1. Encryption/Signature nesting . . . . . . . . . . . . . . 31 7.1. Catalog . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Side channel . . . . . . . . . . . . . . . . . . . . . . 31 7.2. Spool . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Salt reuse . . . . . . . . . . . . . . . . . . . . . . . 31 7.3. Archive . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Terminal integrity check . . . . . . . . . . . . . . . . 33
10. Appendix A: DARE Message Examples and Test Vectors . . . . . 31 8.2. Terminal index record . . . . . . . . . . . . . . . . . . 33
11. Test Examples . . . . . . . . . . . . . . . . . . . . . . . . 32 8.3. Deferred indexing . . . . . . . . . . . . . . . . . . . . 33
11.1. Plaintext Message . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11.2. Plaintext Message with EDS . . . . . . . . . . . . . . . 32 9.1. Encryption/Signature nesting . . . . . . . . . . . . . . 34
11.3. Encrypted Message . . . . . . . . . . . . . . . . . . . 33 9.2. Side channel . . . . . . . . . . . . . . . . . . . . . . 34
11.4. Signed Message . . . . . . . . . . . . . . . . . . . . . 35 9.3. Salt reuse . . . . . . . . . . . . . . . . . . . . . . . 34
11.5. Signed and Encrypted Message . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Appendix B: DARE Container Examples and Test Vectors . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Simple container . . . . . . . . . . . . . . . . . . . . 36 12. Appendix A: DARE Envelope Examples and Test Vectors . . . . . 34
12.2. Payload and chain digests . . . . . . . . . . . . . . . 37 13. Test Examples . . . . . . . . . . . . . . . . . . . . . . . . 34
12.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Plaintext Message . . . . . . . . . . . . . . . . . . . 35
12.4. Signed container . . . . . . . . . . . . . . . . . . . . 40 13.2. Plaintext Message with EDS . . . . . . . . . . . . . . . 35
12.5. Encrypted container . . . . . . . . . . . . . . . . . . 41 13.3. Encrypted Message . . . . . . . . . . . . . . . . . . . 35
13. Appendix C: Previous Frame Function . . . . . . . . . . . . . 43 13.4. Signed Message . . . . . . . . . . . . . . . . . . . . . 37
14. Appendix D: Outstanding Issues . . . . . . . . . . . . . . . 44 13.5. Signed and Encrypted Message . . . . . . . . . . . . . . 38
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 14. Appendix B: DARE Container Examples and Test Vectors . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . 44 14.1. Simple container . . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . 45 14.2. Payload and chain digests . . . . . . . . . . . . . . . 40
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 14.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46 14.4. Signed container . . . . . . . . . . . . . . . . . . . . 43
14.5. Encrypted container . . . . . . . . . . . . . . . . . . 44
15. Appendix C: Previous Frame Function . . . . . . . . . . . . . 46
16. Appendix D: Outstanding Issues . . . . . . . . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.1. Normative References . . . . . . . . . . . . . . . . . . 47
17.2. Informative References . . . . . . . . . . . . . . . . . 48
17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This document describes the Data At Rest Encryption (DARE) Message This document describes the Data At Rest Encryption (DARE) Envelope
and Container Syntax. The DARE Message syntax is used to digitally and Container Syntax. The DARE Envelope syntax is used to digitally
sign, digest, authenticate, or encrypt arbitrary message content. sign, digest, authenticate, or encrypt arbitrary message content.
The DARE Container syntax describes an append-only sequence of data The DARE Container syntax describes an append-only sequence of data
frames, each containing a DARE Message that supports efficient frames, each containing a DARE Envelope that supports efficient
incremental signature and encryption. incremental signature and encryption.
The DARE Message Syntax is based on a subset of the JSON Web The DARE Envelope Syntax is based on a subset of the JSON Web
Signature [RFC7515] and JSON Web Encryption [RFC7516] standards and Signature [RFC7515] and JSON Web Encryption [RFC7516] standards and
shares many fields and semantics. The processing model and data shares many fields and semantics. The processing model and data
structures have been streamlined to remove alternative means of structures have been streamlined to remove alternative means of
specifying the same content and to enable multiple data sequences to specifying the same content and to enable multiple data sequences to
be signed and encrypted under a single master encryption key without be signed and encrypted under a single master encryption key without
compromise to security. compromise to security.
A DARE Message consists of a Header, Payload and an optional Trailer. A DARE Envelope consists of a Header, Payload and an optional
To enable single pass encoding and decoding, the Header contains all Trailer. To enable single pass encoding and decoding, the Header
the information required to perform cryptographic processing of the contains all the information required to perform cryptographic
Payload and authentication data (digest, MAC, signature values) MAY processing of the Payload and authentication data (digest, MAC,
be deferred to the Trailer section. signature values) MAY be deferred to the Trailer section.
A DARE Container is an append-only log format consisting of a A DARE Container is an append-only log format consisting of a
sequence of frames. Cryptographic enhancements (signature, sequence of frames. Cryptographic enhancements (signature,
encryption) may be applied to individual frames or to sets of frames. encryption) may be applied to individual frames or to sets of frames.
Thus, a single key exchange may be used to provide a master key to Thus, a single key exchange may be used to provide a master key to
encrypt multiple frames and a single signature may be used to encrypt multiple frames and a single signature may be used to
authenticate all the frames in the container up to and including the authenticate all the frames in the container up to and including the
frame in which the signature is presented. frame in which the signature is presented.
The DARE Message syntax may be used either as a standalone The DARE Envelope syntax may be used either as a standalone
cryptographic message syntax or as a means of presenting a single cryptographic message syntax or as a means of presenting a single
DARE Container frame together with the complete cryptographic context DARE Container frame together with the complete cryptographic context
required to verify the contents and decrypt them. required to verify the contents and decrypt them.
1.1. Encryption and Integrity 1.1. Encryption and Integrity
An important innovation in the DARE Message Syntax is the separation A key innovation in the DARE Envelope Syntax is the separation of key
of key exchange and data encryption operations so that a Master Key exchange and data encryption operations so that a Master Key (MK)
(MK) established in a single exchange to be applied to multiple data established in a single exchange to be applied to multiple data
sequences. This means that a single public key operation MAY be used sequences. This means that a single public key operation MAY be used
to encrypt and/or authenticate multiple parts of the same DARE to encrypt and/or authenticate multiple parts of the same DARE
Message or multiple frames in a DARE Container. Envelope or multiple frames in a DARE Container.
To avoid reuse of the key and to avoid the need to communicate To avoid reuse of the key and to avoid the need to communicate
separate IVs, each octet sequence is encrypted under a different separate IVs, each octet sequence is encrypted under a different
encryption key (and IV if required) derived from the Master Key by encryption key (and IV if required) derived from the Master Key by
means of a salt that is unique for each octet sequence that is means of a salt that is unique for each octet sequence that is
encrypted. The same approach is used to generate keys for encrypted. The same approach is used to generate keys for
calculating a MAC over the octet sequence if required. This approach calculating a MAC over the octet sequence if required. This approach
allows encryption and integrity protections to be applied to the allows encryption and integrity protections to be applied to the
message payload, to header or trailer fields or to application envelope payload, to header or trailer fields or to application
defined Enhanced Data Sequences in the header or trailer. defined Enhanced Data Sequences in the header or trailer.
1.1.1. Key Exchange 1.1.1. Key Exchange
Traditional cryptographic containers describe the application of a Traditional cryptographic containers describe the application of a
single key exchange to encryption of a single octet sequence. single key exchange to encryption of a single octet sequence.
Examples include PCKS#7/CMS [RFC2315] , OpenPGP [RFC4880] and JSON Examples include PCKS#7/CMS [RFC2315] , OpenPGP [RFC4880] and JSON
Web Encryption [RFC7516] . Web Encryption [RFC7516] .
To encrypt a message using RSA, the encoder first generates a random To encrypt data using RSA, the encoder first generates a random
encryption key and initialization vector (IV). The encryption key is encryption key and initialization vector (IV). The encryption key is
encrypted under the public key of each recipient to create a per- encrypted under the public key of each recipient to create a per-
recipient decryption entry. The encryption key, plaintext and IV are recipient decryption entry. The encryption key, plaintext and IV are
used to generate the ciphertext (figure 1). used to generate the ciphertext (figure 1).
[[This figure is not viewable in this format. The figure is [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
dare.html [2].]] dare.html [2].]]
Monolithic Key Exchange and Encrypt Monolithic Key Exchange and Encrypt
skipping to change at page 6, line 34 skipping to change at page 6, line 44
dare.html [4].]] dare.html [4].]]
Data item encryption under Master Key and per-item salt. Data item encryption under Master Key and per-item salt.
This approach to encryption offers considerably greater flexibility This approach to encryption offers considerably greater flexibility
allowing the same format for data item encryption to be applied at allowing the same format for data item encryption to be applied at
the transport, message or field level. the transport, message or field level.
1.1.2. Data Erasure 1.1.2. Data Erasure
Each encrypted DARE Message specifies a unique Master Salt value of Each encrypted DARE Envelope specifies a unique Master Salt value of
at least 128 bits which is used to derive the salt values used to at least 128 bits which is used to derive the salt values used to
derive cryptographic keys for the message payload and annotations. derive cryptographic keys for the envelope payload and annotations.
Erasure of the Master Salt value MAY be used to effectively render Erasure of the Master Salt value MAY be used to effectively render
the message payload and annotations undecipherable without altering the envelope payload and annotations undecipherable without altering
the message payload data. The work factor for decryption will be the envelope payload data. The work factor for decryption will be
O(2^128) even if the decryption key is compromised. O(2^128) even if the decryption key is compromised.
1.2. Signature 1.2. Signature
As with encryption, DARE Message signatures MAY be applied to an As with encryption, DARE Envelope signatures MAY be applied to an
individual message or a sequence of messages. individual envelope or a sequence of envelope.
1.2.1. Signing Individual Plaintext Messages 1.2.1. Signing Individual Plaintext Envelopes
When an individual plaintext message is signed, the digest value used When an individual plaintext envelope is signed, the digest value
to create the signature is calculated over the binary value of the used to create the signature is calculated over the binary value of
payload data. That is, the value of the payload before the encoding the payload data. That is, the value of the payload before the
(Base-64, JSON-B) is applied. encoding (Base-64, JSON-B) is applied.
1.2.2. Signing Individual Encrypted Messages 1.2.2. Signing Individual Encrypted Envelopes
When an individual plaintext message is signed, the digest value used When an individual plaintext envelope is signed, the digest value
to create the signature is calculated over the binary value of the used to create the signature is calculated over the binary value of
payload data. That is, the value of the payload after encryption but the payload data. That is, the value of the payload after encryption
before the encoding (Base-64, JSON-B) is applied. but before the encoding (Base-64, JSON-B) is applied.
Use of signing and encryption in combination presents the risk of Use of signing and encryption in combination presents the risk of
subtle attacks depending on the order in which signing and encryption subtle attacks depending on the order in which signing and encryption
take place [Davis2001] . take place [Davis2001] .
Na?ve approaches in which a message is encrypted and then signed Na?ve approaches in which an envelope is encrypted and then signed
present the possibility of a surreptitious forwarding attack. For present the possibility of a surreptitious forwarding attack. For
example, Alice signs a message and sends it to Mallet who then strips example, Alice signs an envelope and sends it to Mallet who then
off Alice's signature and sends the message to Bob. strips off Alice's signature and sends the envelope to Bob.
Na?ve approaches in which a message is signed and then encrypted Na?ve approaches in which an envelope is signed and then encrypted
present the possibility of an attacker claiming authorship of a present the possibility of an attacker claiming authorship of a
ciphertext. For example, Alice encrypts a ciphertext for Bob and ciphertext. For example, Alice encrypts a ciphertext for Bob and
then signs it. Mallet then intercepts the message and sends it to then signs it. Mallet then intercepts the envelope and sends it to
Bob. Bob.
While neither attack is a concern in all applications, both attacks While neither attack is a concern in all applications, both attacks
pose potential hazards for the unwary and require close inspection of pose potential hazards for the unwary and require close inspection of
application protocol design to avoid exploitation. application protocol design to avoid exploitation.
To prevent these attacks, each signature on a message that is signed To prevent these attacks, each signature on an envelope that is
and encrypted MUST include a witness value that is calculated by signed and encrypted MUST include a witness value that is calculated
applying a MAC function to the signature value as described in by applying a MAC function to the signature value as described in
section XXX. section XXX.
1.2.3. Signing Sequences of Messages 1.2.3. Signing sequences of envelopes
To sign multiple messages with a single signature, we first construct To sign multiple envelopes with a single signature, we first
a Merkle tree of the message payload digest values and then sign the construct a Merkle tree of the envelope payload digest values and
root of the Merkle tree. then sign the root of the Merkle tree.
[This is not yet implemented but will be soon.] [This is not yet implemented but will be soon.]
1.3. Container 1.3. Container
DARE Container is a message and file syntax that allows a sequence of DARE Container is a message and file syntax that allows a sequence of
data frames to be represented with cryptographic integrity, data frames to be represented with cryptographic integrity,
signature, and encryption enhancements to be constructed in an append signature, and encryption enhancements to be constructed in an append
only format. only format.
skipping to change at page 8, line 41 skipping to change at page 8, line 49
reverse length indicator. The reverse length indicator is written reverse length indicator. The reverse length indicator is written
out backwards allowing the length and thus the frame to be read in out backwards allowing the length and thus the frame to be read in
the reverse direction: the reverse direction:
[[This figure is not viewable in this format. The figure is [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
dare.html [5].]] dare.html [5].]]
JBCD Bidirectional Frame JBCD Bidirectional Frame
Each frame contains a single DARE Message consisting of a Header, Each frame contains a single DARE Envelope consisting of a Header,
Payload and Trailer (if required). The first frame in a container Payload and Trailer (if required). The first frame in a container
describes the container format options and defaults. These include describes the container format options and defaults. These include
the range of encoding options for frame metadata supported and the the range of encoding options for frame metadata supported and the
container profiles to which the container conforms. container profiles to which the container conforms.
All internal data formats support use of pointers of up to 64 bits All internal data formats support use of pointers of up to 64 bits
allowing containers of up to 18 exabytes to be written. allowing containers of up to 18 exabytes to be written.
Five container types are currently specified: Five container types are currently specified:
skipping to change at page 9, line 32 skipping to change at page 9, line 39
Merkle Tree Frame headers contain entries that specify the start Merkle Tree Frame headers contain entries that specify the start
position of previous frames at the apex of the immediately position of previous frames at the apex of the immediately
enclosing binary tree. Frame Trailers contain enclosing binary tree. Frame Trailers contain
TreeDigestPartial and TreeDigestFinal entries forming a Merkle TreeDigestPartial and TreeDigestFinal entries forming a Merkle
digest tree. digest tree.
1.3.2. Write 1.3.2. Write
In normal circumstances, Containers are written as an append only In normal circumstances, Containers are written as an append only
log. As with Messages, integrity information (payload digest, log. As with Envelopes, integrity information (payload digest,
signatures) is written to the message trailer. Thus, large payloads signatures) is written to the entry trailer. Thus, large payloads
may be written without the need to buffer the payload data provided may be written without the need to buffer the payload data provided
that the content length is known in advance. that the content length is known in advance.
Should exceptional circumstances require, Container entries MAY be Should exceptional circumstances require, Container entries MAY be
erased by overwriting the Payload and/or parts of the Header content erased by overwriting the Payload and/or parts of the Header content
without compromising the ability to verify other entries in the without compromising the ability to verify other entries in the
container. If the entry Payload is encrypted, it is sufficient to container. If the entry Payload is encrypted, it is sufficient to
erase the container salt value to render the container entry erase the container salt value to render the container entry
effectively inaccessible (though recovery might still be possible if effectively inaccessible (though recovery might still be possible if
the original salt value can be recovered from the storage media. the original salt value can be recovered from the storage media.
1.3.3. Encryption and Authentication 1.3.3. Encryption and Authentication
Frame payloads and associated attributes MAY be encrypted and/or Frame payloads and associated attributes MAY be encrypted and/or
authenticated in the same manner as Messages. authenticated in the same manner as Envelopes.
Incremental encryption is supported allowing encryption parameters Incremental encryption is supported allowing encryption parameters
from a single public key exchange operation to be applied to encrypt from a single public key exchange operation to be applied to encrypt
multiple frames. The public key exchange information is specified in multiple frames. The public key exchange information is specified in
the first encrypted frame and subsequent frames encrypted under those the first encrypted frame and subsequent frames encrypted under those
parameters specify the location at which the key exchange information parameters specify the location at which the key exchange information
is to be found by means of the ExchangePosition field which MUST is to be found by means of the ExchangePosition field which MUST
specify a location that is earlier in the file. specify a location that is earlier in the file.
To avoid cryptographic vulnerabilities resulting from key re-use, the To avoid cryptographic vulnerabilities resulting from key re-use, the
DARE key exchange requires that each encrypted sequence use an DARE key exchange requires that each encrypted sequence use an
encryption key and initialization vector derived from the master key encryption key and initialization vector derived from the master key
established in the public key exchange by means of a unique salt. established in the public key exchange by means of a unique salt.
Each Message and by extension, each Container frame MUST specify a Each Envelope and by extension, each Container frame MUST specify a
unique salt value of at least 128 bits. Since the encryption key is unique salt value of at least 128 bits. Since the encryption key is
derived from the salt value by means of a Key Derivation Function, derived from the salt value by means of a Key Derivation Function,
erasure of the salt MAY be used as a means of rendering the payload erasure of the salt MAY be used as a means of rendering the payload
plaintext value inaccessible without changing the payload value. plaintext value inaccessible without changing the payload value.
1.3.4. Integrity and Signature 1.3.4. Integrity and Signature
Signatures MAY be applied to a payload digest, the final digest in a Signatures MAY be applied to a payload digest, the final digest in a
chain or tree. The chain and tree digest modes allow a single chain or tree. The chain and tree digest modes allow a single
signature to be used to authenticate all frame payloads in a signature to be used to authenticate all frame payloads in a
container. container.
The tree signature mode is particularly suited to applications such The tree signature mode is particularly suited to applications such
as file archives as it allows files to be verified individually as file archives as it allows files to be verified individually
without requiring the signer to sign each individually. Furthermore, without requiring the signer to sign each individually. Furthermore,
in applications such as code signing, it allows a single signature to in applications such as code signing, it allows a single signature to
be used to verify both the integrity of the code and its membership be used to verify both the integrity of the code and its membership
of the distribution. of the distribution.
As with DARE Message, the signature mechanism does not specify the As with DARE Envelope, the signature mechanism does not specify the
interpretation of the signature semantics. The presence of a interpretation of the signature semantics. The presence of a
signature demonstrates that the holder of the private key applied it signature demonstrates that the holder of the private key applied it
to the specified digest value but not their motive for doing so. to the specified digest value but not their motive for doing so.
Describing such semantics is beyond the scope of this document and is Describing such semantics is beyond the scope of this document and is
deferred to future work. deferred to future work.
1.3.5. Redaction 1.3.5. Redaction
The chief disadvantage of using an append-only format is that The chief disadvantage of using an append-only format is that
containers only increase in size. In many applications, much of the containers only increase in size. In many applications, much of the
skipping to change at page 12, line 22 skipping to change at page 12, line 35
past decades, so has the amount of data to be stored. DARE Container past decades, so has the amount of data to be stored. DARE Container
represents a pragmatic balance of these considerations for current represents a pragmatic balance of these considerations for current
technology. In particular, since payload volumes are likely to be technology. In particular, since payload volumes are likely to be
very large, memory and operational efficiency are considered higher very large, memory and operational efficiency are considered higher
priorities than compactness. priorities than compactness.
2. Definitions 2. Definitions
2.1. Related Specifications 2.1. Related Specifications
The DARE Message and Container formats are based on the following The DARE Envelope and Container formats are based on the following
existing standards and specifications. existing standards and specifications.
DARE Container makes use of the following related standards and
specifications.
Object serialization The JSON-B [draft-hallambaker-jsonbcd] encoding Object serialization The JSON-B [draft-hallambaker-jsonbcd] encoding
is used for object serialization. This encoding is an extension is used for object serialization. This encoding is an extension
of the JavaScript Object Notation (JSON) [RFC7159] . of the JavaScript Object Notation (JSON) [RFC7159] .
Message syntax The cryptographic processing model is based on JSON Message syntax The cryptographic processing model is based on JSON
Web Signature (JWS) [RFC7515] , JSON Web Encryption (JWE) Web Signature (JWS) [RFC7515] , JSON Web Encryption (JWE)
[RFC7516] and JSON Web Key (JWK) [RFC7517] . [RFC7516] and JSON Web Key (JWK) [RFC7517] .
Cryptographic primitives. The HMAC-based Extract-and-Expand Key Cryptographic primitives. The HMAC-based Extract-and-Expand Key
Derivation Function [RFC5869] and Advanced Encryption Standard Derivation Function [RFC5869] and Advanced Encryption Standard
skipping to change at page 13, line 23 skipping to change at page 13, line 28
The terms "Authentication Tag", "Content Encryption Key", "Key The terms "Authentication Tag", "Content Encryption Key", "Key
Management Mode", "Key Encryption", "Direct Key Agreement", "Key Management Mode", "Key Encryption", "Direct Key Agreement", "Key
Agreement with Key Wrapping" and "Direct Encryption" are defined in Agreement with Key Wrapping" and "Direct Encryption" are defined in
the JWE specification [RFC7516] . the JWE specification [RFC7516] .
The terms "Authentication", "Ciphertext", "Digital Signature", The terms "Authentication", "Ciphertext", "Digital Signature",
"Encryption", "Initialization Vector (IV)", "Message Authentication "Encryption", "Initialization Vector (IV)", "Message Authentication
Code (MAC)", "Plaintext" and "Salt" are defined by the Internet Code (MAC)", "Plaintext" and "Salt" are defined by the Internet
Security Glossary, Version 2 [RFC4949] . Security Glossary, Version 2 [RFC4949] .
Annotated Message A DARE Message that contains an Annotations field Annotated Envelope A DARE Envelope that contains an Annotations
with at least one entry. field with at least one entry.
Authentication Data A Message Authentication Code or authentication Authentication Data A Message Authentication Code or authentication
tag. tag.
Complete Message A DARE message that contains the key exchange Complete Envelope A DARE envelope that contains the key exchange
information necessary for the intended recipient(s) to decrypt it. information necessary for the intended recipient(s) to decrypt it.
Detached Message A DARE message that does not contain the key Detached Envelope A DARE envelope that does not contain the key
exchange information necessary for the intended recipient(s) to exchange information necessary for the intended recipient(s) to
decrypt it. decrypt it.
Encryption Context The master key, encryption algorithms and Encryption Context The master key, encryption algorithms and
associated parameters used to generate a set of one or more associated parameters used to generate a set of one or more
enhanced data sequences. enhanced data sequences.
Encoded data sequence (EDS) A sequence consisting of a salt, content Encoded data sequence (EDS) A sequence consisting of a salt, content
data and authentication data (if required by the encryption data and authentication data (if required by the encryption
context). context).
Enhancement Applying a cryptographic operation to a data sequence. Enhancement Applying a cryptographic operation to a data sequence.
This includes encryption, authentication and both at the same This includes encryption, authentication and both at the same
time. time.
Generator The party that generates a DARE message. Generator The party that generates a DARE envelope.
Group Encryption Key A key used to encrypt data to be read by a 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 group of users. This is typically achieved by means of some form
of proxy re-encryption or distributed key generation. of proxy re-encryption or distributed key generation.
Group Encryption Key Identifier A key identifier for a group Group Encryption Key Identifier A key identifier for a group
encryption key. encryption key.
Master Key (MK) The master secret from which keys are derived for Master Key (MK) The master secret from which keys are derived for
authenticating enhanced data sequences. authenticating enhanced data sequences.
Recipient Any party that receives and processes at least some part Recipient Any party that receives and processes at least some part
of a DARE message. of a DARE envelope.
Related Message A set of DARE messages that share the same key Related Envelope A set of DARE envelopes that share the same key
exchange information and hence the same Master Key. exchange information and hence the same Master Key.
Uniform Data Fingerprint (UDF) The means of presenting the result of Uniform Data Fingerprint (UDF) The means of presenting the result of
a cryptographic digest function over a data sequence and content a cryptographic digest function over a data sequence and content
type identifier specified in the Uniform Data Fingerprint type identifier specified in the Uniform Data Fingerprint
specification [draft-hallambaker-mesh-udf] specification [draft-hallambaker-mesh-udf]
3. DARE Message Architecture 3. DARE Envelope Architecture
A DARE Message is a sequence of three parts: A DARE Envelope is a sequence of three parts:
Header A JSON object containing information a reader requires to Header A JSON object containing information a reader requires to
begin processing the message. begin processing the envelope.
Payload An array of octets. Payload An array of octets.
Trailer A JSON object containing information calculated from the Trailer A JSON object containing information calculated from the
message payload. envelope payload.
For example, the following sequence is a JSON encoded Message with an For example, the following sequence is a JSON encoded Envelope with
empty header, a payload of zero length and an empty trailer: an empty header, a payload of zero length and an empty trailer:
[ {}, "", {} ] [ {}, "", {} ]
DARE Messages MAY be encoded using JSON serialization or a binary DARE Envelopes MAY be encoded using JSON serialization or a binary
serialization for greater efficiency. serialization for greater efficiency.
JSON Offers compatibility with applications and libraries that JSON Offers compatibility with applications and libraries that
support JSON. Payload data is encoded using Base64 incurring a support JSON. Payload data is encoded using Base64 incurring a
33% overhead. 33% overhead.
JSON-B A superset of JSON encoding that permits binary data to be JSON-B A superset of JSON encoding that permits binary data to be
encoded as a sequence of length-data segments. This avoids the encoded as a sequence of length-data segments. This avoids the
Base64 overhead incurred by JSON encoding. Since JSON-B is a Base64 overhead incurred by JSON encoding. Since JSON-B is a
superset of JSON encoding, an application can use a single decoder superset of JSON encoding, an application can use a single decoder
for either format. for either format.
JSON-C A superset of JSON-C which provides additional efficiency by JSON-C A superset of JSON-C which provides additional efficiency by
allowing field tags and other repeated string data to be encoded allowing field tags and other repeated string data to be encoded
by reference to a dictionary. Since JSON-C is a superset of JSON by reference to a dictionary. Since JSON-C is a superset of JSON
and JSON-B encodings, an application can use a single decoder for and JSON-B encodings, an application can use a single decoder for
all three formats. all three formats.
DARE Message processors MUST support JSON serialization and SHOULD DARE Envelope processors MUST support JSON serialization and SHOULD
support JSON-B serialization. support JSON-B serialization.
3.1. Processing Considerations 3.1. Processing Considerations
The DARE Message Syntax supports single pass encoding and decoding The DARE Envelope Syntax supports single pass encoding and decoding
without buffering of data. All the information required to begin without buffering of data. All the information required to begin
processing a DARE message (key agreement information, digest processing a DARE envelope (key agreement information, digest
algorithms), is provided in the message header. All the information algorithms), is provided in the envelope header. All the information
that is derived from message processing (authentication codes, digest that is derived from envelope processing (authentication codes,
values, signatures) is presented in the message trailer. digest values, signatures) is presented in the envelope trailer.
The choice of message encoding does not affect the semantics of The choice of envelope encoding does not affect the semantics of
message processing. A DARE Message MAY be reserialized under the envelope processing. A DARE Envelope MAY be reserialized under the
same serialization or converted from any of the specified same serialization or converted from any of the specified
serialization to any other serialization without changing the serialization to any other serialization without changing the
semantics or integrity properties of the message. semantics or integrity properties of the envelope.
3.2. Content Metadata and Annotations 3.2. Content Metadata and Annotations
A header MAY contain header fields describing the payload content. A header MAY contain header fields describing the payload content.
These include: These include:
ContentType Specifies the IANA Media Type [RFC6838] . ContentType Specifies the IANA Media Type [RFC6838] .
Annotations A list of Encoded Data Sequences that provide Annotations A list of Encoded Data Sequences that provide
application specific annotations to the message. application specific annotations to the envelope.
For example, consider the following mail message: For example, consider the following mail message:
From: Alice@example.com From: Alice@example.com
To: bob@example.com To: bob@example.com
Subject: TOP-SECRET Product Launch Today! Subject: TOP-SECRET Product Launch Today!
The CEO told me the product launch is today. Tell no-one! The CEO told me the product launch is today. Tell no-one!
Existing encryption approaches require that header fields such as the Existing encryption approaches require that header fields such as the
subject line be encrypted with the body of the message or not subject line be encrypted with the body of the message or not
encrypted at all. Neither approach is satisfactory. In this encrypted at all. Neither approach is satisfactory. In this
example, the subject line gives away important information that the example, the subject line gives away important information that the
sender probably assumed would be encrypted. But if the subject line sender probably assumed would be encrypted. But if the subject line
is encrypted together with the message body, a mail client must is encrypted together with the message body, a mail client must
retrieve at least part of the message body to provide a 'folder' retrieve at least part of the message body to provide a 'folder'
view. view.
The plaintext form of the equivalent DARE Message encoding is: The plaintext form of the equivalent DARE Message encoding is:
skipping to change at page 17, line 15 skipping to change at page 17, line 22
88 01 88 01
01 01
88 17 88 17
46 72 6f 6d 3a 20 41 6c 69 63 65 40 65 78 61 6d 46 72 6f 6d 3a 20 41 6c 69 63 65 40 65 78 61 6d
70 6c 65 2e 63 6f 6d 70 6c 65 2e 63 6f 6d
88 00 88 00
3.4. Encryption and Integrity 3.4. Encryption and Integrity
Encryption and integrity protections MAY be applied to any DARE Encryption and integrity protections MAY be applied to any DARE
Message Payload and Annotations. Envelope Payload and Annotations.
The following is an encrypted version of the message shown earlier. The following is an encrypted version of the message shown earlier.
The payload and annotations have both increased in size as a result The payload and annotations have both increased in size as a result
of the block cipher padding. The header now includes Recipients and of the block cipher padding. The header now includes Recipients and
Salt fields to enable the content to be decoded. Salt fields to enable the content to be decoded.
[{ [{
"enc":"A256CBC", "enc":"A256CBC",
"Salt":"r1yXNHkhxZnQcAloDzscDg", "Salt":"EshYX1Y0cYSUq8LfTh4Fvw",
"cty":"application/example-mail", "cty":"application/example-mail",
"Annotations":["iAEBiCDY_GflmQT6FRGDzxUxAv0LrHRP_b7jvZvprQWwWPFk "Annotations":["iAEBiCAaX0DGhdZpeaC_HL5oQbZ7TotGPzRit2svzpfRfgYX
TA", UA",
"iAECiCAsiGoiMi0xFnoZVsMUKyGgTX0E448MKqg36hZZxnyBYg", "iAECiCBQ-Q4zWmIMnNKe9GCufR_6E9iXryHc4hfIMqwBXovfYg",
"iAEDiDDvGyqYBVJSa_d1c0v5Z4DN9wKWRmdnllyJJecdlsJ4szg95xtLrKoW "iAEDiDCSyMOzrZ6XFn0BUVoHpsG6QQ5ShgUEwL6ru-Ss_UUXc2NFixDt3mCr
xgym6Ngqnqo" w1sHb-r6WY0"
], ],
"recipients":[{ "recipients":[{
"kid":"MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid":"MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk":{ "epk":{
"PublicKeyECDH":{ "PublicKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Public":"7isN-IhDOvyIlTc8NvH7j3lTQ31z7POV12c2YwtyMPE"}}, "Public":"9RDXSE936LEXqiRd7TDIKp8dqWSlyhe3uxwzZKmdK_U"}},
"wmk":"DicCqnjnsm7tyTaoo7pyCFCU0zHQ_gOP5cW35nRtpjrm10GGlE64 "wmk":"sqmCWgeebzKrMa-MuUaj8ddgK3RWayVEt8_-e7PCtFST3g1shucO
rg"} 7g"}
]}, ]},
"Vq__pS87wSZnJOaKEDMVojU28yAhAzNv8ddLnjSlgoR1QhCW28NLV7_thL01UegX "_pCLaNXBOTT4rut3TZ9g4fjHeUnuJmQtUJEIqm0BNrwGGcBkchNqeNaF8mu8zMRN
2-ud1OwnCMdOXlxkrMrpxg" AzPowgk0xUWMd-YDZmStig"
] ]
3.4.1. Key Exchange 3.4.1. Key Exchange
The DARE key exchange is based on the JWE key exchange except that The DARE key exchange is based on the JWE key exchange except that
encryption modes are intentionally limited and the output of the key encryption modes are intentionally limited and the output of the key
exchange is the DARE Master Key rather than the Content Encryption exchange is the DARE Master Key rather than the Content Encryption
Key. Key.
A DARE Key Exchange MAY contain any number of Recipient entries, each A DARE Key Exchange MAY contain any number of Recipient entries, each
providing a means of decrypting the Master Key using a different providing a means of decrypting the Master Key using a different
private key. private key.
If the Key Exchange mechanism supports message recovery, Direct Key If the Key Exchange mechanism supports message recovery, Direct Key
Agreement is used, in all other cases, Key Wrapping is used. Agreement is used, in all other cases, Key Wrapping is used.
This approach allows messages with one intended recipient to be This approach allows envelopes with one intended recipient to be
handled in the exact same fashion as messages with multiple handled in the exact same fashion as envelopes with multiple
recipients. While this does require an additional key wrapping recipients. While this does require an additional key wrapping
operation, that could be avoided if a message has exactly one operation, that could be avoided if an envelope has exactly one
intended recipient, this is offset by the reduction in code intended recipient, this is offset by the reduction in code
complexity. complexity.
If the key exchange algorithm does not support message recovery (e.g. If the key exchange algorithm does not support message recovery (e.g.
Diffie Hellman and Elliptic Curve Diffie-Hellman), the HKDF Extract- Diffie Hellman and Elliptic Curve Diffie-Hellman), the HKDF Extract-
and-Expand Key Derivation Function is used to derive a master key and-Expand Key Derivation Function is used to derive a master key
using the following info tag: using the following info tag:
"dare-master" [64 61 72 65 2d 6d 61 73 74 65 72] Key derivation info "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 field used when deriving a master key from the output of a key
skipping to change at page 19, line 10 skipping to change at page 19, line 15
A Group Key Identifier has the form <fingerprint>@<domain>. Where A Group Key Identifier has the form <fingerprint>@<domain>. Where
<fingerprint> is a UDF key fingerprint and <domain> is the DNS <fingerprint> is a UDF key fingerprint and <domain> is the DNS
address of a service that provides the encryption service to support address of a service that provides the encryption service to support
decryption by group members. decryption by group members.
3.4.3. Salt Derivation 3.4.3. Salt Derivation
A Master Salt is a sequence of 16 or more octets that is specified in A Master Salt is a sequence of 16 or more octets that is specified in
the Salt field of the header. the Salt field of the header.
The Master Salt is used to derive salt values for the message payload The Master Salt is used to derive salt values for the envelope
and associated encoded data sequences as follows. payload and associated encoded data sequences as follows.
Payload Salt = Master Salt Payload Salt = Master Salt
EDS Salt = Concatenate (Payload Salt Prefix, Master Salt) EDS Salt = Concatenate (Payload Salt Prefix, Master Salt)
Encoders SHOULD NOT generate salt values that exceed 1024 octets. Encoders SHOULD NOT generate salt values that exceed 1024 octets.
The salt value is opaque to the DARE encoding but MAY be used to The salt value is opaque to the DARE encoding but MAY be used to
encode application specific semantics including: encode application specific semantics including:
o Frame number to allow reassembly of a data sequence split over a o Frame number to allow reassembly of a data sequence split over a
sequence of messages which may be delivered out of order. sequence of envelopes which may be delivered out of order.
o Transmit the Master Key in the manner of a Kerberos ticket. o Transmit the Master Key in the manner of a Kerberos ticket.
o Identify the Master Key under which the Enhanced Data Sequence was o Identify the Master Key under which the Enhanced Data Sequence was
generated. generated.
o Enable access to the plaintext to be eliminated by erasure of the o Enable access to the plaintext to be eliminated by erasure of the
encryption key. encryption key.
For data erasure to be effective, the salt MUST be constructed so For data erasure to be effective, the salt MUST be constructed so
skipping to change at page 20, line 13 skipping to change at page 20, line 18
encryption or encryption with authentication key. encryption or encryption with authentication key.
"dare-iv" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an "dare-iv" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an
initialization vector. initialization vector.
"dare-mac" [dare-mac] To generate a Message Authentication Code key. "dare-mac" [dare-mac] To generate a Message Authentication Code key.
3.5. Signature 3.5. Signature
While encryption and integrity enhancements can be applied to any While encryption and integrity enhancements can be applied to any
part of a DARE message, signatures are only applied to payload digest part of a DARE Envelope, signatures are only applied to payload
values calculated over one or more message payloads. digest values calculated over one or more envelope payloads.
The payload digest value for a message is calculated over the binary The payload digest value for an envelope is calculated over the
payload data. That is, after any encryption enhancement has been binary payload data. That is, after any encryption enhancement has
applied but before the message encoding is applied. This allows been applied but before the envelope encoding is applied. This
messages to be converted from one encoding to another without allows envelopes to be converted from one encoding to another without
affecting signature verification. affecting signature verification.
Single Payload The signed value is the payload digest of the message Single Payload The signed value is the payload digest of the
payload. envelope payload.
Multiple Payload. The signed value is the root of a Merkle Tree in Multiple Payload. The signed value is the root of a Merkle Tree in
which the payload digest of the message is one of the leaves. which the payload digest of the envelope is one of the leaves.
Verification of a multiple payload signature naturally requires the Verification of a multiple payload signature naturally requires the
additional digest values required to construct the Merkle Tree. additional digest values required to construct the Merkle Tree.
These are provided in the Trailer in a format that permits multiple These are provided in the Trailer in a format that permits multiple
signers to reference the same tree data. signers to reference the same tree data.
3.6. Algorithms 3.6. Algorithms
3.6.1. Field: kwd 3.6.1. Field: kwd
skipping to change at page 23, line 44 skipping to change at page 23, line 50
of necessary digest inputs is known. of necessary digest inputs is known.
To calculate the value of the tree digest for a node, we first To calculate the value of the tree digest for a node, we first
calculate the values of all the sub trees that have their apex at calculate the values of all the sub trees that have their apex at
that node and then calculate the digest of that value and the that node and then calculate the digest of that value and the
immediately preceding local apex. immediately preceding local apex.
4.2.3. Signature 4.2.3. Signature
Payload data MAY be signed using a JWS [RFC7515] as applied in the Payload data MAY be signed using a JWS [RFC7515] as applied in the
Message. Envelope.
Signatures are specified by the Signatures parameter in the content Signatures are specified by the Signatures parameter in the content
header. The data that the signature is calculated over is defined by header. The data that the signature is calculated over is defined by
the typ parameter of the Signature as follows. the typ parameter of the Signature as follows.
Payload The value of the PayloadDigest parameter Payload The value of the PayloadDigest parameter
Chain The value of the ChainDigest parameter Chain The value of the ChainDigest parameter
Tree The value of the TreeDigestFinal parameter Tree The value of the TreeDigestFinal parameter
If the typ parameter is absent, the value Payload is implied. If the typ parameter is absent, the value Payload is implied.
A frame MAY contain multiple signatures created with the same signing A frame MAY contain multiple signatures created with the same signing
key and different typ values. key and different typ values.
The use of signatures over chain and tree digest values permit The use of signatures over chain and tree digest values permit
skipping to change at page 31, line 29 skipping to change at page 31, line 29
where frames matching the specified criteria are found. where frames matching the specified criteria are found.
ContentType: String (Optional) Content type parameter ContentType: String (Optional) Content type parameter
Paths: String [0..Many] List of filename paths for the current Paths: String [0..Many] List of filename paths for the current
frame. frame.
Labels: String [0..Many] List of labels that are applied to the Labels: String [0..Many] List of labels that are applied to the
current frame. current frame.
7. Security Considerations 7. Dare Container Applications
DARE Containers are used to implement two forms of persistence store
to support Mesh operations:
Catalogs A set of related items which MAY be added, modified or
deleted at any time.
Spools A list of related items whose status MAY be changed at any
time but which are immutable once added.
Since DARE Containers are an append only log format, entries can only
be modified or deleted by adding items to the log to change the
status of previous entries. It is always possible to undo any
operation on a catalog or spool unless the underlying container is
purged or the individual entries modified.
7.1. Catalog
Catalogs contain a set of entries, each of which is distinguished by
a unique identifier.
Three operations are supported:
Add Addition of the entry to the catalog
Update Modification of the data associated with the entry excluding
the identifier
Delete Removal of the entry from the catalog
The set of valid state transitions is defined by the Finite State
machine:
(Add-Update*-Delete)*
Catalogs are used to represent sets of persistent objects associated
with a Mesh Service Account. The user's set of contacts for example.
Each contact entry may be modified many times over time but refers to
the same subject for its entire lifetime.
SchemaCatalog
7.2. Spool
Spools contain lists of entries, each of which is distinguished by a
unique identifier.
Four operations are supported:
Post Addition of the entry to the spool
Processed Marks the entry as having been processed.
Unprocessed Returns the entry to the unread state.
Delete Mark the entry as deleted allowing recovery of associated
storage in a subsequent purge operation.
The set of valid state transitions is defined by the Finite State
machine:
Post-(Processed| Unprocessed| Delete *)
Spools are used to represent time sequence ordered entries such as
lists of messages being sent or received, task queues and transaction
logs.
SchemaCatalog
7.3. Archive
A DARE Archive is a DARE Container whose entries contain files. This
affords the same functionality as a traditional ZIP or tar archive
but with the added cryptographic capabilities provided by the DARE
format.
8. Future Work
The current specification describes an approach in which containers
are written according to a strict append-only policy. Greater
flexibility may be achieved by loosening this requirement allowing
record(s) at the end of the container to be overwritten.
8.1. Terminal integrity check
A major concern when operating a critical service is the possibility
of a hardware or power failure occurring during a write operation
causing the file update to be incomplete. While most modern
operating systems have effective mechanisms in place to prevent
corruption of the file system itself in such circumstances, this does
not provide sufficient protection at the application level.
Appending a null record containing a container-specific magic number
provides an effective means of detecting this circumstance that can
be quickly verified.
If a container specifies a terminal integrity check value in the
header of frame zero, the container is considered to be in an
incomplete write state if the final frame is not a null record
specifying the magic number.
When appending new records to such containers, the old terminal
integrity check record is overwritten by the data being added and a
new integrity check record appended to the end.
8.2. Terminal index record
A writer can maintain a complete (or partial) index of the container
in its final record without additional space overhead by overwriting
the prior index on each update.
8.3. Deferred indexing
The task of updating terminal indexes may be deferred to a time when
the machine is not busy. This improves responsiveness and may avoid
the need to re-index containers receiving a sequence of updates.
This approach may be supported by appending new entries to the end of
the container in the usual fashion and maintaining a record of
containers to be updated as a separate task.
When updating the index on a container that has been updated in this
fashion, the writer must ensure that no data is lost even if the
process is interrupted. The use of guard records and other
precautions against loss of state is advised.
9. Security Considerations
This section describes security considerations arising from the use This section describes security considerations arising from the use
of DaRE in general applications. of DARE in general applications.
Additional security considerations for use of DaRE in Mesh services Additional security considerations for use of DARE in Mesh services
and applications are described in the Mesh Security Considerations and applications are described in the Mesh Security Considerations
guide [draft-hallambaker-mesh-security] . guide [draft-hallambaker-mesh-security] .
7.1. Encryption/Signature nesting 9.1. Encryption/Signature nesting
7.2. Side channel 9.2. Side channel
7.3. Salt reuse 9.3. Salt reuse
8. IANA Considerations 10. IANA Considerations
9. Acknowledgements 11. Acknowledgements
10. Appendix A: DARE Message Examples and Test Vectors A list of people who have contributed to the design of the Mesh is
11. Test Examples presented in [draft-hallambaker-mesh-architecture] .
The name Data At Rest Encryption was proposed by Melhi Abdulhayo?lu.
12. Appendix A: DARE Envelope Examples and Test Vectors
13. Test Examples
In the following examples, Alice's encryption private key parameters In the following examples, Alice's encryption private key parameters
are: are:
{ {
"PrivateKeyECDH":{ "PrivateKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Private":"eutl5W-yj45k4ME_mh2SbR3E5AN61tgDbfmF-dJmTVo"}} "Private":"pL1Td_SjZbgKQwMkr11GICpVujinWV0VSjHcSpIEdpI"}}
Alice's signature private key parameters are: Alice's signature private key parameters are:
{ {
"PrivateKeyECDH":{ "PrivateKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Private":"Bw6qDvg3D8IunEgMDBoDHFc1X-wnd577-PiXUR9RfFU"}} "Private":"utQgSqlZkGD_hd-Qm_Kznx-NVZGyLZu3yIjaGGRYg2g"}}
The body of the test message is the UTF8 representation of the The body of the test message is the UTF8 representation of the
following string: following string:
"This is a test long enough to require multiple blocks" "This is a test long enough to require multiple blocks"
The EDS sequences, are the UTF8 representation of the following The EDS sequences, are the UTF8 representation of the following
strings: strings:
"Subject: Message metadata should be encrypted" "Subject: Message metadata should be encrypted"
"2018-02-01" "2018-02-01"
11.1. Plaintext Message 13.1. Plaintext Message
A plaintext message without associated EDS sequences is an empty A plaintext message without associated EDS sequences is an empty
header followed by the message body: header followed by the message body:
{ {
"DareMessage":[{}, "DareEnvelope":[{},
"VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
BibG9ja3M" BibG9ja3M"
]} ]}
11.2. Plaintext Message with EDS 13.2. Plaintext Message with EDS
If a plaintext message contains EDS sequences, these are also in If a plaintext message contains EDS sequences, these are also in
plaintext: plaintext:
{ {
"DareMessage":[{ "DareEnvelope":[{
"Annotations":["iAEBiC1TdWJqZWN0OiBNZXNzYWdlIG1ldGFkYXRhIHNob3 "Annotations":["iAEBiC1TdWJqZWN0OiBNZXNzYWdlIG1ldGFkYXRhIHNob3
VsZCBiZSBlbmNyeXB0ZWSIAA", VsZCBiZSBlbmNyeXB0ZWSIAA",
"iAECiAoyMDE4LTAyLTAxiAA" "iAECiAoyMDE4LTAyLTAxiAA"
]}, ]},
"VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
BibG9ja3M" BibG9ja3M"
]} ]}
11.3. Encrypted Message 13.3. Encrypted Message
The creator generates a master session key: The creator generates a master session key:
78 52 E2 3D 76 A6 54 63 3A B3 8A C9 76 C5 64 29 7C 84 59 B5 09 DE 9A 84 AE 15 DC E9 9D 08 1A BB
54 56 8C A0 2B F3 40 6A 3B D3 F4 B3 B7 58 80 1F 2A 67 65 F6 FC D5 B4 0F 61 84 75 2C E1 85 C3 06
For each recipient of the message: For each recipient of the message:
The creator generates an ephemeral key: The creator generates an ephemeral key:
{ {
"PrivateKeyECDH":{ "PrivateKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Private":"rDiO3m5PEKiuBDdYwvvHJJXqXTU6md8_FpR0HevDolQ"}} "Private":"LWZrmAXsjR2VVJB4u009kFfI8nTx4awTXqL1HMkgkHk"}}
The key agreement value is calculated: The key agreement value is calculated:
38 95 F8 24 4B C0 71 F7 2C 80 2D 9C 27 E2 E0 81 39 16 01 2A 0F 20 0F 6C 53 93 A4 4D 02 89 4F E0
20 9B 40 03 3D 74 90 E3 60 6E E1 28 E3 B0 63 0E 7B 65 F6 C9 CA 25 5D B4 0A 09 3C CD 63 4D E0 73
The key agreement value is used as the input to a HKDF key derivation The key agreement value is used as the input to a HKDF key derivation
function with the info parameter master to create the key used to function with the info parameter master to create the key used to
wrap the master key: wrap the master key:
B1 AC 17 1F 82 51 52 E5 73 32 6E 2B C3 9F 82 3F 9F C1 77 32 4F C6 A2 0E B4 B1 FF F8 70 15 E7 1E
CE 20 BF A5 19 02 DF EB D3 19 3D 6D 39 91 F3 E2 46 4F 5E 5B 16 F0 7E 93 48 CA F5 13 06 8A 06 FE
The wrapped master key is: The wrapped master key is:
02 FC 2C 53 E0 85 F1 40 20 98 11 1D 7F FC FE 63 E4 5D A9 11 B2 B3 F2 F6 68 9A AC F7 C6 A5 22 CD
B1 26 D8 B4 91 51 7A 19 B8 4E 92 D7 FC A3 2A C1 F8 A8 5C 8D 6C C6 40 FB 77 90 8F 3E 18 31 F2 14
BA EE 2C 6C A2 22 B8 A6 CD 5F 99 75 76 87 88 4C
This information is used to calculate the Recipient information shown This information is used to calculate the Recipient information shown
in the example below. in the example below.
To encrypt a message, we first generate a unique salt value: To encrypt a message, we first generate a unique salt value:
34 2F 8F 81 84 94 86 A7 F3 8A 63 4D 95 FC 9F 65 21 69 5A 7A 3B 55 B3 64 74 FA 48 FD 9C E2 29 A6
The salt value and master key are used to generate the payload The salt value and master key are used to generate the payload
encryption key: encryption key:
8C 2F 2C B7 86 C4 1B 38 72 FF CF 2F 8C 4B 02 B3 80 AA F5 E4 F0 35 74 EB 1A 97 14 43 07 81 14 BE
9B 68 81 95 C1 D8 04 CC C5 CA 9F EC 28 42 20 35 2B 7F 5E CC A8 0F 09 ED 2F 00 0F 60 6A 50 13 E0
Since AES is a block cipher, we also require an initializarion Since AES is a block cipher, we also require an initializarion
vector: vector:
92 2B 73 F5 A9 C4 AD 7E 68 44 4F 51 AC 13 AD 79 C4 90 BB A0 89 63 A4 E2 C7 75 88 42 60 B6 0B 15
The output sequence is the encrypted bytes: The output sequence is the encrypted bytes:
7A F1 D3 73 BB 98 8E EA 54 F5 D6 6F 45 1F 45 F9 8B 45 26 DD D2 29 48 4B 3B FF 70 81 4F FB 15 27
DF AE C8 22 9F 24 01 24 52 C3 26 38 87 11 1A F1 A6 CE 37 26 8E 4A D5 93 90 25 91 43 DF CF EF 3B
20 28 54 9E F4 50 C4 EC D9 11 C7 8C 5A 15 42 A4 44 CA F2 EB 74 F6 DA 69 BB A9 41 2A 01 8D 3C 1B
71 72 F4 C8 47 04 32 5D 9E F7 4F 65 A1 C6 DE A8 3E F7 27 EC F9 9A 1E 1E 83 43 60 C6 79 7D 43 54
Since the message is not signed, there is no need for a trailer. The Since the message is not signed, there is no need for a trailer. The
completed message is: completed message is:
{ {
"DareMessage":[{ "DareEnvelope":[{
"enc":"A256CBC", "enc":"A256CBC",
"Salt":"NC-PgYSUhqfzimNNlfyfZQ", "Salt":"IWlaejtVs2R0-kj9nOIppg",
"recipients":[{ "recipients":[{
"kid":"MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid":"MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk":{ "epk":{
"PublicKeyECDH":{ "PublicKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Public":"qiPa2xdwOl61qs5yUQooA5vHE4C6yA9BqGzSgdF36vI"}}, "Public":"caH_trHCVnZAPg0d1fkMruORm-L8vCQVzSiZHrzQ6ao"}},
"wmk":"AvwsU-CF8UAgmBEdf_z-Y7Em2LSRUXoZuE6S1_yjKsG67ixsoi "wmk":"5F2pEbKz8vZomqz3xqUizfioXI1sxkD7d5CPPhgx8hTNX5l1do
K4pg"} eITA"}
]}, ]},
"evHTc7uYjupU9dZvRR9F-d-uyCKfJAEkUsMmOIcRGvEgKFSe9FDE7NkRx4xaFU "i0Um3dIpSEs7_3CBT_sVJ6bONyaOStWTkCWRQ9_P7ztEyvLrdPbaabupQSoBjT
KkcXL0yEcEMl2e909locbeqA" wbPvcn7PmaHh6DQ2DGeX1DVA"
]} ]}
11.4. Signed Message 13.4. Signed Message
Signed messages specify the digest algorithm to be used in the header Signed messages specify the digest algorithm to be used in the header
and the signature value in the trailer. Note that the digest and the signature value in the trailer. Note that the digest
algorithm is not optional since it serves as notice that a decoder algorithm is not optional since it serves as notice that a decoder
should digest the payload value to enable signature verification. should digest the payload value to enable signature verification.
{ {
"DareMessage":[{ "DareEnvelope":[{
"dig":"S512"}, "dig":"S512"},
"VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS
BibG9ja3M", BibG9ja3M",
{ {
"signatures":[{ "signatures":[{
"signature":"6WT83zSqqsXlCg5qV2lcQKWvjaqfGn40iuMfCMJj3W3u "signature":"-O-Wb7Pi2APad40loUjY9Nt752eEUap6h3QlbRc91Env
p-suh93GUmnJRU3G4N7rrfdSszwqNF3QXGcB6TFyCQ"} pLa0yIBVKdjhA6NZy4h3j7HyavbmpGsfrOYfntEOAg"}
], ],
"PayloadDigest":"raim8SV5adPbWWn8FMM4mrRAQCO9A2jZ0NZAnFXWlG0x "PayloadDigest":"raim8SV5adPbWWn8FMM4mrRAQCO9A2jZ0NZAnFXWlG0x
F6sWGJbnKSdtIJMmMU_hjarlIPEoY3vy9UdVlH5KAg"} F6sWGJbnKSdtIJMmMU_hjarlIPEoY3vy9UdVlH5KAg"}
]} ]}
11.5. Signed and Encrypted Message 13.5. Signed and Encrypted Message
A signed and encrypted message is encrypted and then signed. The A signed and encrypted message is encrypted and then signed. The
signer proves knowledge of the payload plaintext by providing the signer proves knowledge of the payload plaintext by providing the
plaintext witness value. plaintext witness value.
{ {
"DareMessage":[{ "DareEnvelope":[{
"enc":"A256CBC", "enc":"A256CBC",
"dig":"S512", "dig":"S512",
"Salt":"sBoqFymhJw40xB5g3ojv1g", "Salt":"XaMZ2mkbCFsiS4CAH_gbfA",
"recipients":[{ "recipients":[{
"kid":"MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid":"MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk":{ "epk":{
"PublicKeyECDH":{ "PublicKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Public":"S8VmzAf5zVrRwSYMicKHFKTycHdieNTMjmLNABO9vto"}}, "Public":"PSPSJGaCeiMsolP05AHVYhHU5Mb_ss-6V2fxWPM76Fw"}},
"wmk":"pIfhfZ1wZhJ9ZvRnJQlFFDUHilpYyllfHhPzwQpO5Ttzkd4r5x "wmk":"F4lY4Yi3d0Og3NoUh_VzFeumhFGaBn0mNana3GjbUlSkqCjacx
Q9yg"} u3_Q"}
]}, ]},
"eR6QEDzxlgive00ysoeXt9YhmfAYCCx7rYKNuuM3Tr7GR7NcqRvnzz_ZRlCPds "5VCyJCXq1a7wRcoLgfqQgagkjLV9k-ljRBZ217R2iLH4WaDTUZI8i2_iBBz-Sf
hdA9AgEIjveTLPjfPWqgMGXQ", BDiikJ_JTaQuOyHDVAw8nLgQ",
{ {
"signatures":[{ "signatures":[{
"signature":"WdlXU4CZx5Lqg7BWwBdec_zrRyNj1ozh1s65akpo5QbZ "signature":"DTLadbjNopoWfY0vf8lTwqkH_fNuw_4h7TqJaj74n0S4
cHQCMGCfMR3yqp-_GCfB4BIlNTp8Dy3AeftFVIrMBw", 3dYktssoBSix917VX2xDBdRyEn8Khmd3-ba627tBBw",
"witness":"H4ZdcRAn3N5HptphfHgyGKi80qb6GqoIv0LFX5IMy-s"} "witness":"lXO0qec5JKM4M5tAUT1nkEgKyZEZkL0ccn4pL8Cm4hc"}
], ],
"PayloadDigest":"fT5sn-m-AzCCOYpqWf4oPZQJ2Sg6Tb_mHAT5SIMu1dqX "PayloadDigest":"20QMWpBwQmKnIEPaGGw_M9w6WKnowSzPZLXWz5MSClRr
o0G4RWWavoc7gCWSunW9B4Gm9x1aVhclvQ82vMOhUg"} vYOqYDQJkozNfM3uUwZq2PFnLNEnbWNGbbbiH8YQ-w"}
]} ]}
12. Appendix B: DARE Container Examples and Test Vectors 14. Appendix B: DARE Container Examples and Test Vectors
The data payloads in all the following examples are identical, only The data payloads in all the following examples are identical, only
the authentication and/or encryption is different. the authentication and/or encryption is different.
o Frame 1..n consists of 300 bytes being the byte sequence 00, 01, o Frame 1..n consists of 300 bytes being the byte sequence 00, 01,
02, etc. repeating after 256 bytes. 02, etc. repeating after 256 bytes.
For conciseness, the raw data format is omitted for examples after For conciseness, the raw data format is omitted for examples after
the first, except where the data payload has been transformed, (i.e. the first, except where the data payload has been transformed, (i.e.
encrypted). encrypted).
12.1. Simple container 14.1. Simple container
the following example shows a simple container with first frame and a the following example shows a simple container with first frame and a
single data frame: single data frame:
f4 5d f4 5d
f0 59 f0 59
f0 00 f0 00
5d f4 5d f4
f5 01 40 f5 01 40
f0 0f f0 0f
skipping to change at page 37, line 34 skipping to change at page 40, line 5
[Empty trailer] [Empty trailer]
Frame 1 Frame 1
{ {
"Index": 1} "Index": 1}
[Empty trailer] [Empty trailer]
12.2. Payload and chain digests 14.2. Payload and chain digests
The following example shows a chain container with a first frame and The following example shows a chain container with a first frame and
three data frames. The headers of these frames is the same as before three data frames. The headers of these frames is the same as before
but the frames now have trailers specifying the PayloadDigest and but the frames now have trailers specifying the PayloadDigest and
ChainDigest values: ChainDigest values:
Frame 0 Frame 0
{ {
"Index": 0, "Index": 0,
skipping to change at page 38, line 25 skipping to change at page 41, line 4
{ {
"Index": 2} "Index": 2}
{ {
"PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD "PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD
lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw", lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw",
"ChainDigest": "T7S1FcrgY3AaWD4L-t5W1K-3XYkPTcOdGEGyjglTD6yMYVR "ChainDigest": "T7S1FcrgY3AaWD4L-t5W1K-3XYkPTcOdGEGyjglTD6yMYVR
Vz9tn_KQc6GdA-P4VSRigBygV65OEd2Vv3YDhww"} Vz9tn_KQc6GdA-P4VSRigBygV65OEd2Vv3YDhww"}
Frame 3 Frame 3
{ {
"Index": 3} "Index": 3}
{ {
"PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD "PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD
lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw", lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw",
"ChainDigest": "T7S1FcrgY3AaWD4L-t5W1K-3XYkPTcOdGEGyjglTD6yMYVR "ChainDigest": "T7S1FcrgY3AaWD4L-t5W1K-3XYkPTcOdGEGyjglTD6yMYVR
Vz9tn_KQc6GdA-P4VSRigBygV65OEd2Vv3YDhww"} Vz9tn_KQc6GdA-P4VSRigBygV65OEd2Vv3YDhww"}
12.3. Merkle Tree 14.3. Merkle Tree
The following example shows a chain container with a first frame and The following example shows a chain container with a first frame and
six data frames. The trailers now contain the TreePosition and six data frames. The trailers now contain the TreePosition and
TreeDigest values: TreeDigest values:
Frame 0 Frame 0
{ {
"Index": 0, "Index": 0,
"ContainerType": "Merkle", "ContainerType": "Merkle",
skipping to change at page 40, line 26 skipping to change at page 43, line 5
{ {
"Index": 6, "Index": 6,
"TreePosition": 2616} "TreePosition": 2616}
{ {
"PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD "PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD
lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw", lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw",
"TreeDigest": "WgHlz3EHczVPqgtpc39Arv7CFIsCbFVsk8wg0j2qLlEfur9S "TreeDigest": "WgHlz3EHczVPqgtpc39Arv7CFIsCbFVsk8wg0j2qLlEfur9S
Z0mdr65Ka-HF0Qx8gg_DAoiJwUrwADDXyxVJOg"} Z0mdr65Ka-HF0Qx8gg_DAoiJwUrwADDXyxVJOg"}
12.4. Signed container 14.4. Signed container
The following example shows a tree container with a signature in the The following example shows a tree container with a signature in the
final record. The signing key parameters are: final record. The signing key parameters are:
{ {
"PrivateKeyECDH":{ "PrivateKeyECDH":{
"crv":"Ed25519", "crv":"Ed25519",
"Private":"Bw6qDvg3D8IunEgMDBoDHFc1X-wnd577-PiXUR9RfFU"}} "Private":"utQgSqlZkGD_hd-Qm_Kznx-NVZGyLZu3yIjaGGRYg2g"}}
The container headers and trailers are: The container headers and trailers are:
Frame 0 Frame 0
{ {
"Index": 0, "Index": 0,
"ContainerType": "Merkle", "ContainerType": "Merkle",
"ContentMeta": {}, "ContentMeta": {},
"DataEncoding": "JSON"} "DataEncoding": "JSON"}
skipping to change at page 41, line 26 skipping to change at page 44, line 5
{ {
"Index": 2, "Index": 2,
"TreePosition": 325} "TreePosition": 325}
{ {
"PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD "PayloadDigest": "8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZD
lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw", lZeaWQlBsYhOu88-ekpNXpZ2iY96zTRI229zaJ5sw",
"TreeDigest": "7fHmkEIsPkN6sDYAOLvpIJn5Dg3PxDDAaq-ll2kh8722kokk "TreeDigest": "7fHmkEIsPkN6sDYAOLvpIJn5Dg3PxDDAaq-ll2kh8722kokk
FnZQcYtjuVC71aHNXI18q-lPnfRkmwryG-bhqQ"} FnZQcYtjuVC71aHNXI18q-lPnfRkmwryG-bhqQ"}
12.5. Encrypted container 14.5. Encrypted container
The following example shows a container in which all the frame The following example shows a container in which all the frame
payloads are encrypted under the same master secret established in a payloads are encrypted under the same master secret established in a
key agreement specified in the first frame. key agreement specified in the first frame.
Frame 0 Frame 0
{ {
"enc": "A256CBC", "enc": "A256CBC",
"Salt": "Q_LKYdTGwOHRZNjw4PrUbg", "Salt": "VDnGR20aCOw81vKkoZ1B3g",
"recipients": [{ "recipients": [{
"kid": "MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid": "MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk": { "epk": {
"PublicKeyECDH": { "PublicKeyECDH": {
"crv": "Ed25519", "crv": "Ed25519",
"Public": "fuPEPja6OemH5ZZf_m5l83wMIEJQFWi_S71CF1yoE24"}}, "Public": "1LsW7q7UM_dlcglNPDTl7FQCQJ_ygPB-eRRLJ9U_KJE"}},
"wmk": "3H77ypek_SUIs16CfApMCoBD4j8MD0LO3xOx5Njs6QVtV3qAlcygRg"}], "wmk": "yOMdZnE4OoZrkBmjvhow6O7NxH3L_RGg3RMwS1pAiIg4nIYelqEl3Q"}],
"Index": 0, "Index": 0,
"ContainerType": "List", "ContainerType": "List",
"ContentMeta": {}, "ContentMeta": {},
"DataEncoding": "JSON"} "DataEncoding": "JSON"}
[Empty trailer] [Empty trailer]
Frame 1 Frame 1
{ {
"enc": "A256CBC", "enc": "A256CBC",
"Salt": "TjNsKUyuXpKTujdd7E30KQ", "Salt": "qlf6ppXoDFgb_sYaXehrRQ",
"Index": 1} "Index": 1}
[Empty trailer] [Empty trailer]
Frame 2 Frame 2
{ {
"enc": "A256CBC", "enc": "A256CBC",
"Salt": "HpQHRfWJv8JEOXGPFY5ncw", "Salt": "d7UNbWSW49p6jd-xt9aQHw",
"Index": 2} "Index": 2}
[Empty trailer] [Empty trailer]
Here are the container bytes. Note that the content is now encrypted Here are the container bytes. Note that the content is now encrypted
and has expanded by 25 bytes. These are the salt (16 bytes), the AES and has expanded by 25 bytes. These are the salt (16 bytes), the AES
padding (4 bytes) and the JSON-B framing (5 bytes). padding (4 bytes) and the JSON-B framing (5 bytes).
f5 01 c0 f5 01 c0
f1 01 ab f1 01 ab
skipping to change at page 43, line 4 skipping to change at page 45, line 31
Frame 0 Frame 0
{ {
"Index": 0, "Index": 0,
"ContainerType": "List", "ContainerType": "List",
"ContentMeta": {}, "ContentMeta": {},
"DataEncoding": "JSON"} "DataEncoding": "JSON"}
[Empty trailer] [Empty trailer]
Frame 1 Frame 1
{ {
"enc": "A256CBC", "enc": "A256CBC",
"Salt": "grVcSJ0gnISD1d3cueTkIQ", "Salt": "APYGT9HjAI6C5ju7Q1ls4A",
"recipients": [{ "recipients": [{
"kid": "MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid": "MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk": { "epk": {
"PublicKeyECDH": { "PublicKeyECDH": {
"crv": "Ed25519", "crv": "Ed25519",
"Public": "dKyTOgrG3IK5AxtLOsBVIq_ZqDKAIMI6ZpezK2JXlg4"}}, "Public": "Ral0xlpE8Oj_2pZQjGSDXanH1oML4ERA84Xep8hR98k"}},
"wmk": "VRTC-LEJm5gDbsQZXxj4NVSnpEoVPjzBWUhcmyFdmDSzJEDMIIQWMQ"}], "wmk": "IzFcpxJRo2q2N_SaEdVj17pJAF4cDThgLy4X9xv99IKcorXvKYbuwQ"}],
"Index": 1} "Index": 1}
[Empty trailer] [Empty trailer]
Frame 2 Frame 2
{ {
"enc": "A256CBC", "enc": "A256CBC",
"Salt": "YEgzV_m5hgA1EmK15PsTpQ", "Salt": "Evqro4DJy6USJcuI0lLp3w",
"recipients": [{ "recipients": [{
"kid": "MCNZ-6W5N-NWWW-FTHM-YSIM-P2JG-EBM7", "kid": "MBNZ-GJFZ-OLGQ-Q6J6-OAGS-JYLE-OQNH",
"epk": { "epk": {
"PublicKeyECDH": { "PublicKeyECDH": {
"crv": "Ed25519", "crv": "Ed25519",
"Public": "QMkq7pio3N_PoM_DV60f_RPo3hx1wZ4jqrmS64en_nE"}}, "Public": "QrWpxH4l_RCs7LMVbd8G6iv4yeq-Wr5NlKinvhEvUKE"}},
"wmk": "FIF2-JJMrPBgMP6Jeomdu_ldYv8FL5DEWq8TOJ_dPk9NIt7NxVLGRA"}], "wmk": "D9fWgLeROP5erSODAjXhm1RAtmFIGH3-neXcMEIjPOxHsjyFF-iR9w"}],
"Index": 2} "Index": 2}
[Empty trailer] [Empty trailer]
13. Appendix C: Previous Frame Function 15. Appendix C: Previous Frame Function
public long PreviousFrame (long Frame) { public long PreviousFrame (long Frame) {
long x2 = Frame + 1; long x2 = Frame + 1;
long d = 1; long d = 1;
while (x2 > 0) { while (x2 > 0) {
if ((x2 & 1) == 1) { if ((x2 & 1) == 1) {
return x2 == 1 ? (d / 2) - 1 : Frame - d; return x2 == 1 ? (d / 2) - 1 : Frame - d;
} }
d = d * 2; d = d * 2;
x2 = x2 / 2; x2 = x2 / 2;
} }
return 0; return 0;
} }
14. Appendix D: Outstanding Issues 16. Appendix D: Outstanding Issues
The following issues need to be addressed. The following issues need to be addressed.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Issue | Description | | Issue | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| X25519 | The examples currently use Edwards Curve25519 | | X25519 | The examples currently use Edwards Curve25519 |
| | for encryption. This should be Curve25519 | | | for encryption. This should be Curve X25519 |
| Indexing | No examples are given of indexing a container | | Indexing | No examples are given of indexing a container |
| Archive | Should include a file archive example | | Archive | Should include a file archive example |
| File Path | Mention the file path security issue in the | | File Path | Mention the file path security issue in the |
| | security considerations | | | security considerations |
| Security | Write Security considerations | | Security | Write Security considerations |
| Considerations | | | Considerations | |
| AES-GCM | Switch to using AES GCM in the examples | | AES-GCM | Switch to using AES GCM in the examples |
| Witness | Complete handling of witness values. | | Witness | Complete handling of witness values. |
| Schema | Complete the schema documentation | | Schema | Complete the schema documentation |
| Container Redo | Rework the container/header objects so that | | Container Redo | Rework the container/header objects so that |
| | these are separate classes and Header is an | | | these are separate classes and Header is an |
| | entry in the Container header. | | | entry in the Container header. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Table 1 Table 1
15. References 17. References
15.1. Normative References 17.1. Normative References
[draft-hallambaker-jsonbcd] [draft-hallambaker-jsonbcd]
Hallam-Baker, P., "Binary Encodings for JavaScript Object Hallam-Baker, P., "Binary Encodings for JavaScript Object
Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker-
jsonbcd-13 (work in progress), July 2018. jsonbcd-14 (work in progress), April 2019.
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh Part I: Architecture
Guide", draft-hallambaker-mesh-architecture-07 (work in
progress), April 2019.
[draft-hallambaker-mesh-security] [draft-hallambaker-mesh-security]
"[Reference Not Found!]". Hallam-Baker, P., "Mathematical Mesh Part VII: Security
Considerations", draft-hallambaker-mesh-security-00 (work
in progress), April 2019.
[draft-hallambaker-mesh-udf] [draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh Part II: Uniform Data Hallam-Baker, P., "Mathematical Mesh Part II: Uniform Data
Fingerprint.", draft-hallambaker-mesh-udf-01 (work in Fingerprint.", draft-hallambaker-mesh-udf-02 (work in
progress), February 2019. progress), April 2019.
[IANAJOSE] [IANAJOSE]
"[Reference Not Found!]". "[Reference Not Found!]".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998. Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998.
skipping to change at page 45, line 44 skipping to change at page 48, line 48
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015. RFC 7516, DOI 10.17487/RFC7516, May 2015.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015. DOI 10.17487/RFC7517, May 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015. DOI 10.17487/RFC7518, May 2015.
15.2. Informative References 17.2. Informative References
[BLOCKCHAIN] [BLOCKCHAIN]
Chain.com, "Blockchain Specification". Chain.com, "Blockchain Specification".
[Davis2001] [Davis2001]
Davis, D., "Defective Sign & Encrypt in S/MIME, PKCS#7, Davis, D., "Defective Sign & Encrypt in S/MIME, PKCS#7,
MOSS, PEM, PGP, and XML", May 2001. MOSS, PEM, PGP, and XML", May 2001.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009.
[ZIPFILE] PKWARE Inc, "APPNOTE.TXT - .ZIP File Format [ZIPFILE] PKWARE Inc, "APPNOTE.TXT - .ZIP File Format
Specification", October 2014. Specification", October 2014.
15.3. URIs 17.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
[2] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
[3] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [3] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
[4] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [4] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
[5] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [5] http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
 End of changes. 154 change blocks. 
251 lines changed or deleted 397 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/