idnits 2.17.1 draft-hallambaker-dare-message-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2018) is 2066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1229 -- Looks like a reference, but probably isn't: '2' on line 1231 -- Looks like a reference, but probably isn't: '3' on line 1233 -- Looks like a reference, but probably isn't: '4' on line 1235 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 27, 2018 5 Expires: February 28, 2019 7 Data At Rest Encryption Part 1: DARE Message Syntax 8 draft-hallambaker-dare-message-02 10 Abstract 12 This document describes the Data At Rest Encryption (DARE) message 13 syntax. This syntax is used to digitally sign, digest, authenticate, 14 or encrypt arbitrary message content. 16 This document is also available online at 17 http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [1] 18 . 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 28, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Encryption and Integrity . . . . . . . . . . . . . . . . 3 56 1.1.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 4 57 1.1.2. Data Erasure . . . . . . . . . . . . . . . . . . . . 5 58 1.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.2.1. Signing Individual Plaintext Messages . . . . . . . . 6 60 1.2.2. Signing Individual Encrypted Messages . . . . . . . . 6 61 1.2.3. Signing Sequences of Messages . . . . . . . . . . . . 6 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1. Related Specifications . . . . . . . . . . . . . . . . . 7 64 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 7 65 2.3. Defined terms . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Processing Considerations . . . . . . . . . . . . . . . . 9 68 3.2. Content Metadata and Annotations . . . . . . . . . . . . 10 69 3.3. Encoded Data Sequence . . . . . . . . . . . . . . . . . . 11 70 3.4. Encryption and Integrity . . . . . . . . . . . . . . . . 12 71 3.4.1. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 72 3.4.2. Key Identifiers . . . . . . . . . . . . . . . . . . . 14 73 3.4.3. Salt Derivation . . . . . . . . . . . . . . . . . . . 14 74 3.4.4. Key Derivation . . . . . . . . . . . . . . . . . . . 15 75 3.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1. Field: kwd . . . . . . . . . . . . . . . . . . . . . . . 16 78 5. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1. Message Classes . . . . . . . . . . . . . . . . . . . . . 17 80 5.1.1. Structure: DAREMessageSequence . . . . . . . . . . . 17 81 5.2. Header and Trailer Classes . . . . . . . . . . . . . . . 17 82 5.2.1. Structure: DARETrailer . . . . . . . . . . . . . . . 17 83 5.2.2. Structure: DAREHeader . . . . . . . . . . . . . . . . 18 84 5.3. Cryptographic Data . . . . . . . . . . . . . . . . . . . 18 85 5.3.1. Structure: DARESigner . . . . . . . . . . . . . . . . 19 86 5.3.2. Structure: X509Certificate . . . . . . . . . . . . . 19 87 5.3.3. Structure: DARESignature . . . . . . . . . . . . . . 19 88 5.3.4. Structure: DARERecipient . . . . . . . . . . . . . . 19 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 6.1. Encryption/Signature nesting . . . . . . . . . . . . . . 20 91 6.2. Side channel . . . . . . . . . . . . . . . . . . . . . . 20 92 6.3. Salt reuse . . . . . . . . . . . . . . . . . . . . . . . 20 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 95 9. Test Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 96 9.1. Plaintext Message . . . . . . . . . . . . . . . . . . . . 22 97 9.2. Plaintext Message with EDS . . . . . . . . . . . . . . . 22 98 9.3. Encrypted Message . . . . . . . . . . . . . . . . . . . . 22 99 9.4. Signed Message . . . . . . . . . . . . . . . . . . . . . 25 100 9.5. Signed and Encrypted Message . . . . . . . . . . . . . . 26 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 10.2. Informative References . . . . . . . . . . . . . . . . . 28 104 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 107 1. Introduction 109 This document describes the Data At Rest Encryption (DARE) Message 110 Syntax. This syntax is used to digitally sign, digest, authenticate, 111 or encrypt arbitrary message content. 113 The DARE Message Syntax is based on a subset of the JSON Web 114 Signature [RFC7515] and JSON Web Encryption [RFC7516] standards and 115 shares many fields and semantics. The processing model and data 116 structures have been streamlined to remove alternative means of 117 specifying the same content. 119 A DARE Message consists of a Header, Payload and an optional Trailer. 120 To enable single pass encoding and decoding, the Header contains all 121 the information required to perform cryptographic processing of the 122 Payload and authentication data (digest, MAC, signature values) may 123 be deferred to the Trailer section. 125 The DARE Message Syntax is designed to compliment the DARE Container 126 syntax. A DARE Container is an append-only log format consisting of 127 a sequence of frames. Cryptographic enhancements (signature, 128 encryption) may be applied to individual frames or to sets of frames. 129 Thus, a single key exchange may be used to provide a master key to 130 encrypt multiple frames and a single signature may be used to 131 authenticate all the frames in the container up to and including the 132 frame in which the signature is presented. 134 The DARE Message syntax may be used either as a standalone 135 cryptographic message syntax or as a means of presenting a single 136 DARE Container frame together with the complete cryptographic context 137 required to verify the contents and decrypt them. 139 1.1. Encryption and Integrity 141 An important innovation in the DARE Message Syntax is the separation 142 of key exchange and data encryption operations so that a Master Key 143 (MK) established in a single exchange to be applied to multiple octet 144 sequences. This means that a public key operation may be used to 145 encrypt multiple parts of the same message or to multiple frames in a 146 DARE Container. 148 To avoid reuse of the key and to avoid the need to communicate 149 separate IVs, each octet sequence is encrypted under a different 150 encryption key (and IV if required) derived from the Master Key by 151 means of a salt that is unique for each octet sequence that is 152 encrypted. The same approach is used to generate keys for 153 calculating a MAC over the octet sequence if required. This approach 154 allows encryption and integrity protections to be applied to the 155 message payload, to header or trailer fields or to application 156 defined Enhanced Data Sequences in the header or trailer. 158 1.1.1. Key Exchange 160 Traditional cryptographic containers describe the application of a 161 single key exchange to encryption of a single octet sequence. 162 Examples include PCKS#7/CMS [RFC2315] , OpenPGP [RFC4880] and JSON 163 Web Encryption [RFC7516] . 165 To encrypt a message using RSA, the encoder first generates a random 166 encryption key and initialization vector (IV). The encryption key is 167 encrypted under the public key of each recipient to create a per- 168 recipient decryption entry. The encryption key, plaintext and IV are 169 used to generate the ciphertext (figure 1). 171 [[This figure is not viewable in this format. The figure is 172 available at http://mathmesh.com/Documents/draft-hallambaker-dare- 173 message.html [2].]] 175 Monolithic Key Exchange and Encrypt 177 This approach is adequate for the task of encrypting a single octet 178 stream. It is less than satisfactory when encrypting multiple octet 179 streams or very long streams for which a rekeying operation is 180 desirable. 182 In the DARE approach, key exchange and key derivation are separate 183 operations and keys MAY be derived for encryption or integrity 184 purposes or both. A single key exchange MAY be used to derive keys 185 to apply encryption and integrity enhancements to multiple data 186 sequences. 188 The DARE key exchange begins with the same key exchange used to 189 produce the CEK in JWE but instead of using the CEK to encipher data 190 directly, it is used as one of the inputs to a Key Derivation 191 Function (KDF) that is used to derive parameters for each block of 192 data to be encrypted. To avoid the need to introduce additional 193 terminology, the term 'CEK' is still used to describe the output of 194 the key agreement algorithm (including key unwrapping if required) 195 but it is more appropriately described as a Master Key (figure 2). 197 [[This figure is not viewable in this format. The figure is 198 available at http://mathmesh.com/Documents/draft-hallambaker-dare- 199 message.html [3].]] 201 Exchange of Master Key 203 A Master Key may be used to encrypt any number of data items. Each 204 data item is encrypted under a different encryption key and IV (if 205 required). This data is derived from the Master Key using the HKDF 206 function [RFC5869] using a different salt for each data item and 207 separate info tags for each cryptographic function (figure 3). 209 [[This figure is not viewable in this format. The figure is 210 available at http://mathmesh.com/Documents/draft-hallambaker-dare- 211 message.html [4].]] 213 Data item encryption under Master Key and per-item salt. 215 This approach to encryption offers considerably greater flexibility 216 allowing the same format for data item encryption to be applied at 217 the transport, message or field level. 219 1.1.2. Data Erasure 221 Each encrypted DARE Message specifies a unique Master Salt value of 222 at least 128 bits which is used to derive the salt values used to 223 derive cryptographic keys for the message payload and annotations. 225 Erasure of the Master Salt value MAY be used to effectively render 226 the message payload and annotations undecipherable without altering 227 the message payload data. The work factor for decryption will be 228 O(2^128) even if the decryption key is compromised. 230 1.2. Signature 232 As with encryption, DARE Message signatures MAY be applied to an 233 individual message or a sequence of messages. 235 1.2.1. Signing Individual Plaintext Messages 237 When an individual plaintext message is signed, the digest value used 238 to create the signature is calculated over the binary value of the 239 payload data. That is, the value of the payload before the encoding 240 (Base-64, JSON-B) is applied. 242 1.2.2. Signing Individual Encrypted Messages 244 When an individual plaintext message is signed, the digest value used 245 to create the signature is calculated over the binary value of the 246 payload data. That is, the value of the payload after encryption but 247 before the encoding (Base-64, JSON-B) is applied. 249 Use of signing and encryption in combination presents the risk of 250 subtle attacks depending on the order in which signing and encryption 251 take place [Davis2001] . 253 Na?ve approaches in which a message is encrypted and then signed 254 present the possibility of a surreptitious forwarding attack. For 255 example, Alice signs a message and sends it to Mallet who then strips 256 off Alice's signature and sends the message to Bob. 258 Na?ve approaches in which a message is signed and then encrypted 259 present the possibility of an attacker claiming authorship of a 260 ciphertext. For example, Alice encrypts a ciphertext for Bob and 261 then signs it. Mallet then intercepts the message and sends it to 262 Bob. 264 While neither attack is a concern in all applications, both attacks 265 pose potential hazards for the unwary and require close inspection of 266 application protocol design to avoid exploitation. 268 To prevent these attacks, each signature on a message that is signed 269 and encrypted MUST include a witness value that is calculated by 270 applying a MAC function to the signature value as described in 271 section XXX. 273 1.2.3. Signing Sequences of Messages 275 To sign multiple messages with a single signature, we first construct 276 a Merkle tree of the message payload digest values and then sign the 277 root of the Merkle tree. 279 [This is not yet implemented but will be soon.] 281 2. Definitions 283 2.1. Related Specifications 285 The DARE message format is based on the following existing standards 286 and specifications. 288 Object serialization The JSON-B [draft-hallambaker-jsonbcd] encoding 289 is used for object serialization. This encoding is an extension 290 of the JavaScript Object Notation (JSON) [RFC7159] . 292 Message syntax The cryptographic processing model is based on JSON 293 Web Signature (JWS) [RFC7515] , JSON Web Encryption (JWE) 294 [RFC7516] and JSON Web Key (JWK) [RFC7517] . 296 Cryptographic primitives. The HMAC-based Extract-and-Expand Key 297 Derivation Function [RFC5869] and Advanced Encryption Standard 298 (AES) Key Wrap with Padding Algorithm [RFC3394] are used. 300 The Uniform Data Fingerprint method of presenting data digests is 301 used for key identifiers and other purposes 302 [draft-hallambaker-udf] . 304 Cryptographic algorithms The cryptographic algorithms and 305 identifiers described in JSON Web Algorithms (JWA) [RFC7518] are 306 used together with additional algorithms as defined in the JSON 307 Object Signing and Encryption IANA registry [IANAJOSE] . 309 2.2. Requirements Language 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 313 document are to be interpreted as described in [RFC2119] . 315 2.3. Defined terms 317 The terms "Authentication Tag", "Content Encryption Key", "Key 318 Management Mode", "Key Encryption", "Direct Key Agreement", "Key 319 Agreement with Key Wrapping" and "Direct Encryption" are defined in 320 the JWE specification [RFC7516] . 322 The terms "Authentication", "Ciphertext", "Digital Signature", 323 "Encryption", "Initialization Vector (IV)", "Message Authentication 324 Code (MAC)", "Plaintext" and "Salt" are defined by the Internet 325 Security Glossary, Version 2 [RFC4949] . 327 Annotated Message A DARE Message that contains an Annotations field 328 with at least one entry. 330 Authentication Data A Message Authentication Code or authentication 331 tag. 333 Complete Message A DARE message that contains the key exchange 334 information necessary for the intended recipient(s) to decrypt it. 336 Detached Message A DARE message that does not contain the key 337 exchange information necessary for the intended recipient(s) to 338 decrypt it. 340 Encryption Context The master key, encryption algorithms and 341 associated parameters used to generate a set of one or more 342 enhanced data sequences. 344 Encoded data sequence (EDS) A sequence consisting of a salt, content 345 data and authentication data (if required by the encryption 346 context). 348 Enhancement Applying a cryptographic operation to a data sequence. 349 This includes encryption, authentication and both at the same 350 time. 352 Generator The party that generates a DARE message. 354 Group Encryption Key A key used to encrypt data to be read by a 355 group of users. This is typically achieved by means of some form 356 of proxy re-encryption or distributed key generation. 358 Group Encryption Key Identifier A key identifier for a group 359 encryption key. 361 Master Key (MK) The master secret from which keys are derived for 362 authenticating enhanced data sequences. 364 Recipient Any party that receives and processes at least some part 365 of a DARE message. 367 Related Message A set of DARE messages that share the same key 368 exchange information and hence the same Master Key. 370 Uniform Data Fingerprint (UDF) The means of presenting the result of 371 a cryptographic digest function over a data sequence and content 372 type identifier specified in the Uniform Data Fingerprint 373 specification [draft-hallambaker-udf] 375 3. Architecture 377 A DARE message is a sequence of three parts as follows. 379 Header A JSON object containing information a reader requires to 380 begin processing the message. 382 Payload An array of octets. 384 Trailer A JSON object containing information calculated from the 385 message payload. 387 For example, the following sequence is a JSON encoded DARE Message 388 with an empty header, a payload of zero length and an empty trailer: 390 [ {}, "", {} ] 392 Figure 1 394 DARE Messages MAY be encoded using JSON serialization or a binary 395 serialization for greater efficiency. 397 JSON Offers compatibility with applications and libraries that 398 support JSON. Payload data is encoded using Base64 incurring a 399 33% overhead. 401 JSON-B A superset of JSON encoding that permits binary data to be 402 encoded as a sequence of length-data segments. This avoids the 403 Base64 overhead incurred by JSON encoding. 405 JSON-C A superset of JSON-C which provides additional efficiency by 406 allowing field tags and other repeated string data to be encoded 407 by reference to a dictionary. 409 DARE Message processors MUST support JSON serialization and SHOULD 410 support JSON-B serialization. 412 3.1. Processing Considerations 414 The DARE Message Syntax supports single pass encoding and decoding 415 without buffering of data. All the information required to begin 416 processing a DARE message (key agreement information, digest 417 algorithms), is provided in the message header. All the information 418 that is derived from message processing (authentication codes, digest 419 values, signatures) is presented in the message trailer. 421 The choice of message encoding does not affect the semantics of 422 message processing. A DARE Message MAY be reserialized under the 423 same serialization or converted from any of the specified 424 serialization to any other serialization without changing the 425 semantics or integrity properties of the message. 427 3.2. Content Metadata and Annotations 429 A header MAY contain header fields describing the payload content. 430 These include: 432 ContentType Specifies the IANA Content Type. 434 Annotations A list of Encoded Data Sequences that provide 435 application specific annotations to the message. 437 The format of the Encoded Data Sequences is described in the 438 following section. 440 Consider the following mail message: 442 From: Alice@example.com 443 To: bob@example.com 444 Subject: TOP-SECRET Product Launch Today! 446 The CEO told me the product launch is today. Tell no-one! 448 Figure 2 450 Existing encryption approaches require that header fields such as the 451 subject line be encrypted with the body of the message or not 452 encrypted at all. Neither approach is satisfactory. In this 453 example, the subject line gives away important information that the 454 sender probably assumed would be encrypted. But if the subject line 455 is encrypted together with the message body, a mail client must 456 retrieve at least part of the message body to provide a 'folder' 457 view. 459 The following is a plaintext DARE Message in which the header fields 460 of the mail message are presented as annotations: 462 [{ 463 "cty":"application/example-mail", 464 "Annotations":["iAEBiBdGcm9tOiBBbGljZUBleGFtcGxlLmNvbYgA", 465 "iAECiBNUbzogYm9iQGV4YW1wbGUuY29tiAA", 466 "iAEDiClTdWJqZWN0OiBUT1AtU0VDUkVUIFByb2R1Y3QgTGF1bmNoIFRvZGF5 467 IYgA" 468 ]}, 469 "VGhlIENFTyB0b2xkIG1lIHRoZSBwcm9kdWN0IGxhdW5jaCBpcyB0b2RheS4gVGVs 470 bCBuby1vbmUh" 471 ] 473 Figure 3 475 3.3. Encoded Data Sequence 477 An encoded data sequence (EDS) is a sequence of octets that encodes a 478 data sequence according to cryptographic enhancements specified in 479 the context in which it is presented. An EDS MAY be encrypted and 480 MAY be authenticated by means of a MAC. The keys and other 481 cryptographic parameters used to apply these enhancements are derived 482 from the cryptographic context and a Salt prefix specified in the EDS 483 itself. 485 An EDS sequence contains exactly three binary fields encoded in 486 JSON-B serialization as follows: 488 Salt Prefix A sequence of octets used to derive the encryption key, 489 Initialization Vector and MAC key as required. 491 Body The plaintext or encrypted content. 493 Authentication Tag The authentication code value in the case that 494 the cryptographic context specifies use of authenticated 495 encryption or a MAC, otherwise is a zero-length field. 497 Requiring all three fields to be present, even in cases where they 498 are unnecessary simplifies processing at the cost of up to six 499 additional data bytes. 501 The encoding of the 'From' header of the previous example as a 502 plaintext EDS is as follows: 504 88 01 505 01 506 88 17 507 46 72 6f 6d 3a 20 41 6c 69 63 65 40 65 78 61 6d 508 70 6c 65 2e 63 6f 6d 509 88 00 511 ~~~~ 513 Figure 4 515 3.4. Encryption and Integrity 517 Encryption and integrity protections MAY be applied to any DARE 518 Message Payload and Annotations. 520 The following is an encrypted version of the message shown earlier. 521 The payload and annotations have both increased in size as a result 522 of the block cipher padding. The header now includes Recipients and 523 Salt fields to enable the content to be decoded. 525 [{ 526 "enc":"A256CBC", 527 "Salt":"cvbklMnkhoWE1-3_t3Z-UQ", 528 "cty":"application/example-mail", 529 "Annotations":["iAEBiCDUKHYfjqs5SHQAzwezya-guHTj0SkhmeHtjbHSWjLa 530 Fg", 531 "iAECiCCI5gIDQIVQLnQmnc3ZUHb4rtnq3U-ctF52eEXRdNapxw", 532 "iAEDiDAsnYWB_5SpxqyX_GLKSW4ztdPbEfsxMAUQnRzr7moJoORh1SxzLLYt 533 NPovkFVqXBg" 534 ], 535 "recipients":[{ 536 "kid":"MDAD3-E4BYE-MK6CH-QA2HD-TKRS2-KIX5Y-A", 537 "epk":{ 538 "PublicKeyDH":{ 539 "kid":"MDIGT-2AA2Q-HFVRN-WYCNY-F32NC-FB4NP-A", 540 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA", 541 "Public":"a3VlD_zF5tPfV3GxjfsdkdjDjqT0isXW9iwbZeXWGiCBV 542 dwTIgXAzDF0SqBMLbqe31p1ZEMFh0mas6evqNUCM-yb9HuVtjzaaDcn3_jH2kkgQw 543 S9_4cD8_qFCazvxwAgKCnLn_VzKOBduT0uvQz1FEuCSv4t0kLlbCwDIe_7TMaoQPN 544 RcsVvMPPW6lfWkC5CiHaGN78bNCzkmplAbHV2g10oC4_NdRZ6m8kBkXWz3bnnLFGI 545 KWzXKTgfQXrksSktKa9pkwA_6KWEMiLPPHQhtj7wud09o7TzWfdcz3lFaGeMmTBSH 546 dFyRl0LSbia9qsrgN6tLUCwOtbuKV3XoEYlvwA"}}, 547 "wmk":"mzXRWy5OjlsZFHT_teqx3E6wtL6eLVFekiUXO_txMUSt3ILj9xgJ 548 Lw"} 549 ]}, 550 "vTg5MAhAmIKF7LCFeE8xFhqOFQ5znVtkIctqyyctDkTNL69Tf0KhsC5VoVty3JCq 551 RNth3hIfdHJZlU_BnMRzyA" 552 ] 554 Figure 5 556 3.4.1. Key Exchange 558 The DARE key exchange is based on the JWE key exchange except that 559 encryption modes are intentionally limited and the output of the key 560 exchange is the DARE Master Key rather than the Content Encryption 561 Key. 563 A DARE Key Exchange MAY contain any number of Recipient entries, each 564 providing a means of decrypting the Master Key using a different 565 private key. 567 If the Key Exchange mechanism supports message recovery, Direct Key 568 Agreement is used, in all other cases, Key Wrapping is used. 570 This approach allows messages with one intended recipient to be 571 handled in the exact same fashion as messages with multiple 572 recipients. While this does require an additional key wrapping 573 operation, that could be avoided if a message has exactly one 574 intended recipient, this is offset by the reduction in code 575 complexity. 577 If the key exchange algorithm does not support message recovery (e.g. 578 Diffie Hellman and Elliptic Curve Diffie-Hellman), the HKDF Extract- 579 and-Expand Key Derivation Function is used to derive a master key 580 using the following info tag: 582 "dare-master" [64 61 72 65 2d 6d 61 73 74 65 72] Key derivation info 583 field used when deriving a master key from the output of a key 584 exchange. 586 The master key length is the maximum of the key size of the 587 encryption algorithm specified by the key exchange header, the key 588 size of the MAC algorithm specified by the key exchange header (if 589 used) and 256. 591 3.4.2. Key Identifiers 593 The JWE/JWS specifications define a kid field for use as a key 594 identifier but not how the identifier itself is constructed. All 595 DARE key identifiers are either UDF key fingerprints 596 [draft-hallambaker-udf] or Mesh/Recrypt Group Key Identifiers. 598 A UDF fingerprint is formed as the digest of an IANA content type and 599 the digested data. A UDF key fingerprint is formed with the content 600 type application/pkix-keyinfo and the digested data is the ASN.1 DER 601 encoded PKIX certificate keyInfo sequence for the corresponding 602 public key. 604 A Group Key Identifier has the form @. Where 605 is a UDF key fingerprint and is the DNS 606 address of a service that provides the encryption service to support 607 decryption by group members. 609 3.4.3. Salt Derivation 611 A Master Salt is a sequence of 16 or more octets that is specified in 612 the Salt field of the header. 614 The Master Salt is used to derive salt values for the message payload 615 and associated encoded data sequences as follows. 617 Payload 619 EDS 620 Encoders SHOULD NOT generate salt values that exceed 1024 octets. 622 The salt value is opaque to the DARE encoding but MAY be used to 623 encode application specific semantics including: 625 o Frame number to allow reassembly of a data sequence split over a 626 sequence of messages which may be delivered out of order. 628 o Transmit the Master Key in the manner of a Kerberos ticket to 629 allow some (but not necessarily all) to avoid the need to perform 630 a key exchange. 632 o Identify the Master Key under which the Enhanced Data Sequence was 633 generated. 635 o Enable erasure of the encrypted data plaintext by erasure of the 636 encryption key. 638 For data erasure to be effective, the salt MUST be constructed so 639 that the difficulty of recovering the key is sufficiently high that 640 it is infeasible. For most purposes, a salt with 128 bits of 641 appropriately random data is sufficient. 643 3.4.4. Key Derivation 645 Encryption and/or authentication keys are derived from the Master Key 646 using a Extract-and-Expand Key Derivation Function as follows: 648 1. The Master Key and salt value are used to extract the PRK 649 (pseudorandom key) 651 2. The PRK is used to derive the algorithm keys using the 652 application specific information input for that key type. 654 The application specific information inputs are: 656 "dare-encrypt" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an 657 encryption or encryption with authentication key. 659 "dare-iv" [64 61 72 65 2d 65 6e 63 72 79 70 74] To generate an 660 initialization vector. 662 "dare-mac" [dare-mac] To generate a Message Authentication Code key. 664 3.5. Signature 666 While encryption and integrity enhancements can be applied to any 667 part of a DARE message, signatures are only applied to payload digest 668 values calculated over one or more message payloads. 670 The payload digest value for a message is calculated over the binary 671 payload data. That is, after any encryption enhancement has been 672 applied but before the message encoding is applied. This allows 673 messages to be converted from one encoding to another without 674 affecting signature verification. 676 Single Payload The signed value is the payload digest of the message 677 payload. 679 Multiple Payload. The signed value is the root of a Merkle Tree in 680 which the payload digest of the message is one of the leaves. 682 Verification of a multiple payload signature naturally requires the 683 additional digest values required to construct the Merkle Tree. 684 These are provided in the Trailer in a format that permits multiple 685 signers to reference the same tree data. 687 4. Algorithms 689 4.1. Field: kwd 691 The key wrapping and derivation algorithms. 693 Since the means of public key exchange is determined by the key 694 identifier of the recipient key, it is only necessary to specify the 695 algorithms used for key wrapping and derivation. 697 The default (and so far only) algorithm is kwd-aes-sha2-256-256. 699 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm 700 [RFC3394] is used to wrap the Master Exchange Key. AES 256 is used. 702 HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] is 703 used for key derivation. SHA-2-256 is used for the hash function. 705 5. Reference 707 A DARE Message consists of a Header, an Enhanced Data Sequence (EDS) 708 and an optional trailer. This section describes the JSON data fields 709 used to construct headers, trailers and complete messages. 711 Wherever possible, fields from JWE, JWS and JWK have been used. In 712 these cases, the fields have the exact same semantics. Note however 713 that the classes in which these fields are presented have different 714 structure and nesting. 716 5.1. Message Classes 718 A DARE Message contains a single DAREMessageSequence in either the 719 JSON or Compact serialization as directed by the protocol in which it 720 is applied. 722 5.1.1. Structure: DAREMessageSequence 724 A DARE Message containing Header, EDS and Trailer in JSON object 725 encoding. Since a DAREMessage is almost invariably presented in JSON 726 sequence or compact encoding, use of the DAREMessage subclass is 727 preferred. 729 Although a DARE Message is functionally an object, it is serialized 730 as an ordered sequence. This ensures that the message header field 731 will always precede the body in a serialization, this allowing 732 processing of the header information to be performed before the 733 entire body has been received. 735 Header: DAREHeader (Optional) The message header. May specify the 736 key exchange data, pre-signature or signature data, cloaked 737 headers and/or encrypted data sequences. 739 Body: Binary (Optional) The message body 741 Trailer: DARETrailer (Optional) The message trailer. If present, 742 this contains the signature. 744 5.2. Header and Trailer Classes 746 A DARE Message sequence MUST contain a (possibly empty) DAREHeader 747 and MAY contain a DARETrailer. 749 5.2.1. Structure: DARETrailer 751 A DARE Message Trailer 753 Signatures: DARESignature [0..Many] A list of signatures. A message 754 trailer MUST NOT contain a signatures field if the header contains 755 a signatures field. 757 5.2.2. Structure: DAREHeader 759 Inherits: DARETrailer 761 A DARE Message Header. Since any field that is present in a trailer 762 MAY be placed in a header instead, the message header inherits from 763 the trailer. 765 EncryptionAlgorithm: String (Optional) The encryption algorithm as 766 specified in JWE 768 AuthenticationAlgorithm: String (Optional) Message Authentication 769 Code algorithm 771 Cloaked: Binary (Optional) If present in a header or trailer, 772 specifies an encrypted data block containing additional header 773 fields whose values override those specified in the message and 774 context headers. 776 When specified in a header, a cloaked field MAY be used to conceal 777 metadata (content type, compression) and/or to specify an 778 additional layer of key exchange. That applies to both the 779 Message body and to headers specified within the cloaked header. 781 Processing of cloaked data is described in? 783 ContentType: String (Optional) The content type field as specified 784 in JWE 786 EDSS: Binary [0..Many] If present, the Encrypted Data Segments field 787 contains a sequence of Encrypted Data Segments encrypted under the 788 message Master Key. The interpretation of these fields is 789 application specific. 791 Signers: DARESigner [0..Many] A list of 'presignature' 793 Recipients: DARERecipient [0..Many] A list of recipient key exchange 794 information blocks. 796 5.3. Cryptographic Data 798 DARE Message uses the same fields as JWE and JWS but with different 799 structure. In particular, DARE messages MAY have multiple recipients 800 and multiple signers. 802 5.3.1. Structure: DARESigner 804 The signature value 806 Dig: String (Optional) Digest algorithm hint. Specifying the digest 807 algorithm to be applied to the message body allows the body to be 808 processed in streaming mode. 810 Alg: String (Optional) Key exchange algorithm 812 KeyIdentifier: String (Optional) Key identifier of the signature 813 key. 815 Certificate: X509Certificate (Optional) PKIX certificate of signer. 817 Path: X509Certificate (Optional) PKIX certificates that establish a 818 trust path for the signer. 820 5.3.2. Structure: X509Certificate 822 X5u: String (Optional) URL identifying an X.509 public key 823 certificate 825 X5: Binary (Optional) An X.509 public key certificate 827 5.3.3. Structure: DARESignature 829 Inherits: DARESigner 831 The signature value 833 SignatureValue: Binary (Optional) The signature value as an Enhanced 834 Data Sequence under the message Master Key. 836 5.3.4. Structure: DARERecipient 838 Recipient information 840 KeyIdentifier: String (Optional) Key identifier for the encryption 841 key. 843 The Key identifier MUST be either a UDF fingerprint of a key or a 844 Group Key Identifier 846 KeyWrapDerivation: String (Optional) The key wrapping and derivation 847 algorithms. 849 WrappedMasterKey: Binary (Optional) The wrapped master key. The 850 master key is encrypted under the result of the key exchange. 852 RecipientKeyData: String (Optional) The per-recipient key exchange 853 data. 855 6. Security Considerations 857 6.1. Encryption/Signature nesting 859 6.2. Side channel 861 6.3. Salt reuse 863 7. IANA Considerations 865 8. Acknowledgements 867 9. Test Examples 869 In the following examples, Alice's encryption private key parameters 870 are: 872 { 873 "PrivateKeyDH":{ 874 "kid":"MDAD3-E4BYE-MK6CH-QA2HD-TKRS2-KIX5Y-A", 875 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA", 876 "Public":"GaMqeF8I2s00AUMm1D1dcXflA61rrbUflBbpYHLtz3GrwkVR_JsGd 877 qlCVWQEX9McxsYTJUoFJzeHivLsyoUlAY9H3Qtm_aClOeARO8yXboUTjKtwgH1qu0 878 s6kKl-p-tcaqu2PXReTVfOG9HtSR60iSuRZ9G9JHpKQNZCTdpoq4B2oBw6LvS1y-p 879 18bDCB_JeOOcqT8Aba08TjkhIG2OHaZDEgdDOU1nIAT1hIxh48sLuPSdou-F76l47 880 8Jte_oJKTqGCUUeOm_397_d4sbaCiPO0RMllIFC7VEhi2TIDL6bRF7ujmCdxreYn9 881 DlDjr1nF7hkcXEALL_5NyLVxwKdBw", 882 "Private":"cokgZSxP_IdDAswgUZWDFu6qlKrEVX83uwDU2jI5LWiIoknyE6dY 883 wW2_mADDQ_2DRxm73J3fTH6C73KAOx-cJnJYDqr8kU3FhBEXBn8wxFL6M-SgVxyKa 884 jZ5MRL0-3EAyNCAE_HLNoeUqAqGAchw-lnDgQO7e4F0hkEwa29JdwrBKTJxY93WAB 885 Xd3xZahbNWs3sh2MU_FGU6AzfnTWPdvWTTxImySVF47pex-gRbYFVV-Cm1ZUuof-5 886 flM-RwUlnf28qJ8SJ_-zKmjLc6TSrMky8ox1u6v7WHoFRiweMCyBQ3x2Zc2ypXPfF 887 DvvAu5RYiVoUbrlES1UswPObiE2lOg"}} 889 Figure 6 891 Alice's signature private key parameters are: 893 { 894 "PrivateKeyRSA":{ 895 "kid":"MBWNO-2J43U-ESWKW-XQWL6-6YGEW-UOPWU-A", 896 "n":"1NzbmakMalVH1mRv7TEDEhwXDNojn5wZbq1tv1gp5PgZwzX-klYXuFhj0- 897 MpO0zcwptsUaYJhwdvvgW_1udUpISQYluXOB3UMj2e_0yl64MvnqTL47SZQuAN3QQ 898 9cuCw_-_Eyj_jerspauqa6RpNzGcabZrtRl7J7DPVZ3SNlw-H_Wxd4HkrFVW_Yqup 899 htNL1JciQJYm2DSu9dbetqPZ80x6IBargY850mBYOzvNNE5S-dRJQHoJY4SG-ESYF 900 BuAHtBlOMgbI0XNiq96EegA-vPW9XRF-SHdX5mkafefDGK4rT_RoE4gRwhDM3jbZ8 901 1-F2ZA_GpNVEvB-25_vF96lQ", 902 "e":"AQAB", 903 "d":"k_v_h7Jo-TvUt44X6jSax-pTdBHrljk1zSYxGEe4yIBbmMVe-Gl2ECkTLe 904 nNbnafO4RGJ_Vgxkk7PEZO-p7Uz5OBtX-rf83tCgihEyg8aaFIZ-h1_xY9Pqr5uGA 905 MQGNJaoVMsLb99QNNZhE4JTquP56mVvDQaI3Zn6bhhA0ZqpxS_x6iRUV5KnHCRd47 906 DKGHcAsQR_caxGec7M_XNPqpl0tcoGQz46-I0SVVcqtjb_YysEVez4eJhb_ZTU4C7 907 pz4wXDj6B0ppFJVZEMaIhKo8FCnoQdXEJl4vSiBzUFrSlPc6gjQk2CBhxc_kb782w 908 VwW5wtgOVxhV1k2piQ2NrlOQ", 909 "p":"6osXfrJLiPfK0ky17vqzRs-M5mOxZU2LEFGyHTXxx6EYTWixEsx2Sdf6kx 910 UD5K_QdYnqqd3yobbGdDpMwwEuwgogWVCz90nc9QdCUy4MCpz8lpOQd1i_tXMmtOg 911 GBu9mapMTEOwc7HlLlSDRezv_TzTAH4izv-CUEZ_M5EcwyFM", 912 "q":"6FYD6NV4rKU1ACtGQyIvwGrkrS_F6phB-whx0nSVFkbkwppJiPnC6XqjZ3 913 OYPCZylxaTHFnxCs0nntrraeNEcWfNPrpTN5XIZjbOiIaKA2iCQkWlDoi8oduEtTK 914 oIcuy32oBz6MpUeCWzl0ZQ4EeTF3RyCc_jpf8oRvZ0e3ItHc", 915 "dp":"hfjbe9BmWx-HqCaPSanEW-9UQYmym_X2OGUiA5N7vxci5ZymgOFvs_B9v 916 iQj7C4NOgaEl3EjFgJsS5m9nSoAxm-4WKxDkD6NyxzRYugLkshnc69otvNn1kKnWn 917 CqeK2o57mJC4KDZwRGCzIK1oTH6jtsfta8Lh8fFQ4doEuV7uc", 918 "dq":"r6R_ViE0Foja1aLhflU09mmZMViBbkXm86nBqtHZ97pmrLvJRdVTxgCh0 919 c6w0yBZ1uEJHBDeykSoZE6qVCWtE3Le1kI0MTx6ANQENXBInCUA_Kr8Ck3TFSYIYJ 920 fIRaxiMMZKUjfOQAji2WXGeKL_TcpLkt4hDWLXaNDOTgdOiSc", 921 "qi":"DfHtLB1Ox1Kgp3E4jqy5Qxeb7-v7_uv8n_5-E1OQ3NLSRV2m_auojkR19 922 nY3gokHKNSXM41qKlJLU00lROjOO2KUq57s8GZkheVfbJLNCJ6KAw_aRT2IgyJm2b 923 e2v5OCHSkm88tgJWbtKj-OPKTFV5gOMVdeCzGX286ErjDHGCM"}} 925 Figure 7 927 The body of the test message is the UTF8 representation of the 928 following string: 930 "This is a test long enough to require multiple blocks" 932 Figure 8 934 The EDS sequences, are the UTF8 representation of the following 935 strings: 937 "Subject: Message metadata should be encrypted" 938 "2018-02-01" 940 Figure 9 942 9.1. Plaintext Message 944 A plaintext message without associated EDS sequences is an empty 945 header followed by the message body: 947 { 948 "DAREMessage":[{}, 949 "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS 950 BibG9ja3M" 951 ]} 953 Figure 10 955 9.2. Plaintext Message with EDS 957 If a plaintext message contains EDS sequences, these are also in 958 plaintext: 960 { 961 "DAREMessage":[{ 962 "Annotations":["iAEBiC1TdWJqZWN0OiBNZXNzYWdlIG1ldGFkYXRhIHNob3 963 VsZCBiZSBlbmNyeXB0ZWSIAA", 964 "iAECiAoyMDE4LTAyLTAxiAA" 965 ]}, 966 "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS 967 BibG9ja3M" 968 ]} 970 Figure 11 972 9.3. Encrypted Message 974 The creator generates a master session key: 976 94 D7 0B C4 8C 43 B2 0E 7C 2A F8 C2 37 9C 8F E5 977 CA A7 8F BC 4C B3 9F CB 14 AA 5F 4C 41 AF 52 4B 979 Figure 12 981 The creator generates an ephemeral key: 983 { 984 "PrivateKeyDH":{ 985 "kid":"MAK3V-IOKWY-NFGD7-YBPY3-OWINU-3WRPC-A", 986 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA", 987 "Public":"aeZpao1EpPIXrAFheMEHjjxJMucxpFJ5LvDXJunryv0xfpDseipYF 988 8jng0pBAE-P7CDPdw_WQgYDdW4NgF7BUbYq1EaXbcV1uLYBB2Yw2MAj-Up-7pO1Fc 989 5kjiDnRz0Sd0lJARCtkR5A2cuyMvuEg8cntCQWcoyzh4ep1PktlWDKoSKltovO0cM 990 -9hj-uGFiBV6-cb15fkQ7pyKp-XiH_2YkMCiUYhkPx9ZObr1WNMVHn9TyLgufPnLH 991 skaE2JDFckEBMljwXdI9z_DeUx4FNESRQQ68UGfDhfepPwR3_xbL9OFbFiJSjdd51 992 pxfzvi2SbJm8uKY5K3omsUMszyqjQA", 993 "Private":"iXfaIGr7vRVqJyTZEj_5F-3n7DL5KZzQ0sL4wydy1-F27A6kHjBW 994 yOrV0qr9BLuLRGH4vvfYSael_ILWzgKfC22KqN1CjJdzChwZvFyQCCXynrkH06KAk 995 uDWpczlC0n8T8WvTboalzVNvOfVM__QcywomDoY6tUCbIn6fQ5xJyWaR8EGQHPFdF 996 7W-O0ezKIieSKC25fIkIOt3c2-dqQdzUl2Vlk6R_6wkFxhX2NNqpV7VktrglQ6AUJ 997 b8gFt6H7gmsSvdks8lXv-1VHwwH_8HBRAOcqsRu9THuz8T4H30d30FZ-NXtCpUEwi 998 citGRXZ1UzmChc_IuIkfdQfuAGvttAA"}} 1000 Figure 13 1002 The key agreement value is calculated: 1004 A2 CD 5A 08 24 70 27 5F 6F 28 A5 6D B0 AA 47 31 1005 50 D0 F3 DA 07 13 4A 72 F7 BB 19 8E 72 60 82 51 1006 32 0B CF 7B A1 8A FD 40 7E D5 E1 79 87 20 8B 2A 1007 73 F5 20 2D 1C 94 FB 2D 8D 4F C0 DA 6D D7 C0 7A 1008 D1 C6 35 A8 AD D2 DD BF F9 19 C3 BB 60 20 04 F7 1009 D7 F0 81 F6 F3 94 68 DE 6F B6 B4 67 CD 9B F3 E4 1010 A0 28 6E 59 5A A2 FE 00 10 17 B3 34 2C 07 20 06 1011 2C B9 34 F0 4C C8 E9 C1 CA 80 1D 02 15 B6 CE D4 1012 EC BB 91 2B FA 7D 9B 14 24 13 16 46 1C D2 5B 12 1013 4A 0E 60 28 D6 38 E1 35 79 D6 DF 66 C0 C6 7F A7 1014 E3 C1 9F 25 CD 01 A5 52 7A C1 B5 ED 3C 24 0F 8F 1015 DD E6 27 60 F7 2D CF D5 7E 13 F8 29 53 7B 43 FC 1016 13 F6 7B 55 8A 44 AD 16 A9 27 75 E0 9A DF 95 F6 1017 F6 2C D5 26 88 1B EB 20 EE 26 C6 4E 17 20 54 BA 1018 DB A5 37 A4 99 A2 FC 49 93 DE F5 8F F5 3B D1 F3 1019 FF 9D 71 38 B1 AE 94 E0 10 61 16 CA 8F B9 16 1C 1021 Figure 14 1023 The key agreement value is used as the input to a HKDF key derivation 1024 function with the info parameter System.Byte[] to create the key used 1025 to wrap the master key: 1027 40 39 4F 58 34 F4 0F B3 AA 0F 88 7D EE AC 98 1A 1028 91 84 25 3C 74 F6 E4 25 35 DB D6 78 6A ED 6B F5 1030 Figure 15 1032 The wrapped master key is: 1034 14 98 FB 8C 0A D0 C8 C6 65 D3 9F F5 6B 80 42 96 1035 0A 71 E9 93 F7 14 D2 29 C9 DB 96 FE FA 9A DB 74 1036 29 F4 35 36 BC CF BF 41 1038 Figure 16 1040 This information is used to calculate the Recipient information shown 1041 in the example below. 1043 To encrypt a message, we first generate a unique salt value: 1045 82 D1 8C BA A0 F0 26 5C 7A 35 5F 82 1F 88 35 CD 1047 Figure 17 1049 The salt value and master key are used to generate the payload 1050 encryption key: 1052 D3 74 4A 8E 69 65 A4 71 8B 14 44 AA CC E6 7F 66 1053 07 87 91 3E F3 41 DE 2D DE 5F 4A 7C 19 D5 75 79 1055 Figure 18 1057 Since AES is a block cipher, we also require an initializarion 1058 vector: 1060 0A 5A 94 71 54 7B C2 16 E8 BF D2 66 5D 8D E5 BF 1062 Figure 19 1064 The output sequence is the encrypted bytes: 1066 30 33 D9 A1 12 19 EF 96 1C 43 45 98 50 7B D2 B1 1067 A7 94 C2 C8 1B 52 00 3E DD A2 B4 9F 51 A5 BD 8C 1068 F4 3D 81 15 95 D0 6D D7 19 5F 28 E3 A0 FF EA 26 1069 29 27 78 B7 49 E7 B2 E3 AD A7 8C D1 C0 61 D5 68 1071 Figure 20 1073 Since the message is not signed, there is no need for a trailer. The 1074 completed message is: 1076 { 1077 "DAREMessage":[{ 1078 "enc":"A256CBC", 1079 "Salt":"gtGMuqDwJlx6NV-CH4g1zQ", 1080 "recipients":[{ 1081 "kid":"MDAD3-E4BYE-MK6CH-QA2HD-TKRS2-KIX5Y-A", 1082 "epk":{ 1083 "PublicKeyDH":{ 1084 "kid":"MAK3V-IOKWY-NFGD7-YBPY3-OWINU-3WRPC-A", 1085 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA", 1086 "Public":"aeZpao1EpPIXrAFheMEHjjxJMucxpFJ5LvDXJunryv0 1087 xfpDseipYF8jng0pBAE-P7CDPdw_WQgYDdW4NgF7BUbYq1EaXbcV1uLYBB2Yw2MAj 1088 -Up-7pO1Fc5kjiDnRz0Sd0lJARCtkR5A2cuyMvuEg8cntCQWcoyzh4ep1PktlWDKo 1089 SKltovO0cM-9hj-uGFiBV6-cb15fkQ7pyKp-XiH_2YkMCiUYhkPx9ZObr1WNMVHn9 1090 TyLgufPnLHskaE2JDFckEBMljwXdI9z_DeUx4FNESRQQ68UGfDhfepPwR3_xbL9OF 1091 bFiJSjdd51pxfzvi2SbJm8uKY5K3omsUMszyqjQA"}}, 1092 "wmk":"FJj7jArQyMZl05_1a4BClgpx6ZP3FNIpyduW_vqa23Qp9DU2vM 1093 -_QQ"} 1094 ]}, 1095 "MDPZoRIZ75YcQ0WYUHvSsaeUwsgbUgA-3aK0n1GlvYz0PYEVldBt1xlfKOOg_- 1096 omKSd4t0nnsuOtp4zRwGHVaA" 1097 ]} 1099 Figure 21 1101 9.4. Signed Message 1103 Signed messages specify the digest algorithm to be used in the header 1104 and the signature value in the trailer. Note that the digest 1105 algorithm is not optional since it serves as notice that a decoder 1106 should digest the payload value to enable signature verification. 1108 { 1109 "DAREMessage":[{ 1110 "dig":"S512"}, 1111 "VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdWx0aXBsZS 1112 BibG9ja3M", 1113 { 1114 "signatures":[{ 1115 "signature":"s4LxUqNOV1-0uryJCiYFqnKak3EHZuLBaaUrehaRCaZH 1116 2KqASBftk87fTl73XUeV-0TfvlfV8STP7l0brcWnPTKQgXSMXvuoxqF0n9qcpXubB 1117 xzdGHdFX-5GeQMFsr8NutBBng-LSZVe2eCb7n29dpCgZ84v5Y4JGzvKHOy8vaU"} 1118 ], 1119 "PayloadDigest":"raim8SV5adPbWWn8FMM4mrRAQCO9A2jZ0NZAnFXWlG0x 1120 F6sWGJbnKSdtIJMmMU_hjarlIPEoY3vy9UdVlH5KAg"} 1121 ]} 1123 Figure 22 1125 9.5. Signed and Encrypted Message 1127 A signed and encrypted message is encrypted and then signed. The 1128 signer proves knowledge of the payload plaintext by providing the 1129 plaintext witness value. 1131 { 1132 "DAREMessage":[{ 1133 "enc":"A256CBC", 1134 "dig":"S512", 1135 "Salt":"AB4x8M6bLZjdSr6W9ntB2A", 1136 "recipients":[{ 1137 "kid":"MDAD3-E4BYE-MK6CH-QA2HD-TKRS2-KIX5Y-A", 1138 "epk":{ 1139 "PublicKeyDH":{ 1140 "kid":"MDJLN-DFSIO-ZOL6P-2NOZD-YHBQH-3JQSK-A", 1141 "Domain":"YE6bnq1MlX5ojaJto6PLP_PEwA", 1142 "Public":"XBYmS2ui9AgETUvwK9d3eLWQiQ8240yddATCETYAAUH 1143 H0m29aDiBpIT9TcDVs6dtnWH-mnZMTfwT_RQJvyMcfM1AYFvmMfu3GoFS6Z4nngor 1144 hZGFNGgWEG7yX9eOvaiBWpTs2gw7AM4PvUh9r5G0IolfIvQcTRZHpKuU3GqV0E0xp 1145 PhrEajKzLSrDNu6tZ2yDe7BQBSI7YNgZGeXqOTr3KmfdfYU7Hk_ak3M_LhtCCe2-m 1146 bwPuDUD0PUWScZLrKbMWzLIzO0OrDYMwjSrJmirH2RxQKM2a_kJAQoBFtmXjlaFLC 1147 yvOKK1ibPnWn7_JZtUy_k4IvDex6b7VKVap6ySQ"}}, 1148 "wmk":"qS1rvoKhPjlVy3B6uYkgRYYTJtOzDEeiqqezpTAoGh8Op2VV6x 1149 cbUw"} 1150 ]}, 1151 "MudZFUAZRBINTZO9szFJCr9NUrE1s1meuZfRftorYK5_gI8-NAjLud8Jx8LM_R 1152 DVNXfi5GKGNFuvfr0MlqyFRQ", 1153 { 1154 "signatures":[{ 1155 "signature":"SAzZxGhqUVUSQCta3vZ1OL9AkdLD40sVSE9k2opol_FW 1156 4aEyMEm4c5UZTnkf6Ndkz1O47TrjHowzagSwkTdq-dV7r7OxH-oQ9fTeG1GyT8xwo 1157 Yw4KsSjD71X_lwgi2BI-WMvdVliOFk78MC52eF7SsA0mkbWnSSB0WHBjoJvEaI", 1158 "witness":"zvxEBQmdHJCin9brH4lpD-8CNJXWezsSMhWAT-CSlk0"} 1159 ], 1160 "PayloadDigest":"ScoVguz7ufoe547gh9LIC00ptI24ZzpwLplJFzeJQx9d 1161 G7LfeBTi2oNPr2GBuLp29pRRuDqgdRCftuLeRBl8kg"} 1162 ]} 1164 Figure 23 1166 10. References 1168 10.1. Normative References 1170 [draft-hallambaker-jsonbcd] 1171 Hallam-Baker, P., "Binary Encodings for JavaScript Object 1172 Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- 1173 jsonbcd-13 (work in progress), July 2018. 1175 [draft-hallambaker-udf] 1176 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 1177 hallambaker-udf-10 (work in progress), April 2018. 1179 [IANAJOSE] 1180 "[Reference Not Found!]". 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, 1184 DOI 10.17487/RFC2119, March 1997. 1186 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1187 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998. 1189 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1190 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1191 September 2002. 1193 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1194 Thayer, "OpenPGP Message Format", RFC 4880, 1195 DOI 10.17487/RFC4880, November 2007. 1197 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1198 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. 1200 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1201 Key Derivation Function (HKDF)", RFC 5869, 1202 DOI 10.17487/RFC5869, May 2010. 1204 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1205 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1206 2014. 1208 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1209 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1210 2015. 1212 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1213 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1215 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1216 DOI 10.17487/RFC7517, May 2015. 1218 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1219 DOI 10.17487/RFC7518, May 2015. 1221 10.2. Informative References 1223 [Davis2001] 1224 Davis, D., "Defective Sign & Encrypt in S/MIME, PKCS#7, 1225 MOSS, PEM, PGP, and XML", May 2001. 1227 10.3. URIs 1229 [1] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html 1231 [2] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html 1233 [3] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html 1235 [4] http://mathmesh.com/Documents/draft-hallambaker-dare-message.html 1237 Author's Address 1239 Phillip Hallam-Baker 1240 Comodo Group Inc. 1242 Email: philliph@comodo.com