idnits 2.17.1 draft-bsipos-dtn-bpsec-cose-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2020) is 1401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 661 -- Looks like a reference, but probably isn't: '40' on line 661 -- Looks like a reference, but probably isn't: '2' on line 692 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-22 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE' ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-25 == Outdated reference: A later version (-02) exists of draft-ietf-dtn-bpsec-interop-sc-01 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Standards Track June 26, 2020 5 Expires: December 28, 2020 7 DTN Bundle Protocol Security COSE Security Contexts 8 draft-bsipos-dtn-bpsec-cose-01 10 Abstract 12 This document defines an integrity security context and a 13 confidentiality security context suitable for using CBOR Object 14 Signing and Encryption (COSE) algorithms within Bundle Protocol 15 Security (BPSec) blocks. A profile of COSE is also defined for BPSec 16 interoperation. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 28, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. BPSec Security Contexts . . . . . . . . . . . . . . . . . . . 3 55 3.1. COSE Integrity Context . . . . . . . . . . . . . . . . . 3 56 3.2. COSE Confidentiality Context . . . . . . . . . . . . . . 4 57 4. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 5 58 4.1. Interoperability Algorithms . . . . . . . . . . . . . . . 5 59 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 8 62 6.2. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 8 63 6.3. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 9.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 71 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 10 72 A.2. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 12 73 A.3. Symmetric Key COSE_Encrypt0 . . . . . . . . . . . . . . . 14 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The Bundle Protocol Security (BPSec) Specification 79 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block 80 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but 81 does not specify any security contexts to be used by either of the 82 security block types. The CBOR Object Signing and Encryption (COSE) 83 specification [RFC8152] defines a structure, encoding, and algorithms 84 to use for cryptographic signing and encryption. 86 This document describes how to use the algorithms and encodings of 87 COSE within BPSec blocks to apply those algorithms to Bundle security 88 in Section 3. A bare minimum of interoperability algorithms and 89 algorithm parameters is specified by this document in Section 4. 91 This document does not address how those COSE algorithms are intended 92 to be used within a larger security context. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. BPSec Security Contexts 104 Rather than defining a single security context for both integrity and 105 confidentiality blocks, this document specifies two separate security 106 contexts which are analogous to the two BPSec block types. Each 107 security context allows a specific set of BPSec Result IDs. 109 The existing COSE message-marking tags in Section 2 of [RFC8152] 110 SHALL be used as BPSec Result ID values for all COSE security 111 contexts (see Table 1 and Table 2). This avoids the need for value- 112 mapping between code points of the two registries. 114 When embedding COSE messages, the CBOR-tagged form SHALL NOT be used. 115 The Result ID values already provide the same information as the COSE 116 tags. 118 3.1. COSE Integrity Context 120 The COSE Integrity Context has a Security Context ID of TBD-CI. 122 The integrity context SHALL allow only the Result IDs from Table 1. 123 Each integrity context result value SHALL consist of the COSE message 124 indicated by Table 1 in its decoded form. 126 +-----------+----------------+ 127 | Result ID | Result Message | 128 +-----------+----------------+ 129 | 97 | COSE_Mac | 130 | | | 131 | 17 | COSE_Mac0 | 132 | | | 133 | 98 | COSE_Sign | 134 | | | 135 | 18 | COSE_Sign1 | 136 +-----------+----------------+ 138 Table 1: COSE Integrity Results 140 Each integrity result SHALL use the "detached" payload form with nil 141 payload value. The integrity result for COSE_Mac and COSE_Mac0 142 messages are computed by the procedure in Section 6.3 of [RFC8152]. 143 The integrity result for COSE_Sign and COSE_Sign1 messages are 144 computed by the procedure in Section 4.4 of [RFC8152]. 146 [NOTE: This differs from base BPSec in that the entire block and the 147 bundle primary is signed] The COSE "payload" used to generate a 148 signature or MAC result SHALL be the canonically serialized target 149 block, including the canonical block array structure. The COSE 150 "protected attributes from the application" used to generate a 151 signature or MAC result SHALL be either: 153 For a primary block target: An empty byte string. 155 For a canonical block target: The canonically serialized primary 156 block of the bundle. 158 3.2. COSE Confidentiality Context 160 The COSE Confidentiality Context has a Security Context ID of TBD-CC. 162 The confidentiality context SHALL allow only the Result IDs from 163 Table 2. Each confidentiality context result value SHALL consist of 164 the COSE message indicated by Table 2 in its decoded form. 166 +-----------+----------------+ 167 | Result ID | Result Message | 168 +-----------+----------------+ 169 | 96 | COSE_Encrypt | 170 | | | 171 | 16 | COSE_Encrypt0 | 172 +-----------+----------------+ 174 Table 2: COSE Confidentiality Results 176 Only algorithms which support Authenticated Encryption with 177 Authenticated Data (AEAD) SHALL be usable in the first (content) 178 layer of a confidentiality result. Because COSE encryption with AEAD 179 appends the authentication tag with the ciphertext, the size of the 180 block-type-specific-data will grow after an encryption operation. 182 Each confidentiality result SHALL use the "detached" payload form 183 with nil payload value. The COSE plaintext and ciphertext correspond 184 exactly with the target block-type-specific-data. The 185 confidentiality result for COSE_Encrypt and COSE_Encrypt0 messages 186 are computed by the procedure in Section 5.3 of [RFC8152]. 188 [NOTE: This differs from base BPSec in that AAD from the block and 189 the bundle primary is used] The COSE "plaintext" used to generate an 190 encrypt result SHALL be the block-type-specific-data of the target 191 block, the decoded byte string itself (not including the encoded CBOR 192 item header). The COSE "protected attributes from the application" 193 used to generate an encrypt result SHALL be the concatenation of the 194 following: 196 1. The canonically serialized primary block of the bundle. 198 2. The canonically serialized augmented target block, which has its 199 block-type-specific-data substituted with an empty byte string. 201 4. COSE Profile for BPSec 203 This section contains requirements which apply to the use of COSE 204 within BPSec across any security context use. 206 When used in a BPSec result, each COSE message SHALL contain an 207 explicit algorithm identifier in the lower (content) layers. A BPSec 208 security operation always occurs within the context of the immutable 209 primary block and its parameters. When available and not implied by 210 the bundle source, a COSE message SHOULD contain a key identifier in 211 the highest layer. When a key identifier is not available, BPSec 212 acceptors SHOULD use the Security Source (if available) and the 213 Bundle Source to imply which keys can be used for security 214 operations. 216 The algorithms required by this profile focuses on networks using 217 shared symmetric-keys, with recommended algorithms for Elliptic Curve 218 (EC) keypairs and RSA keypairs. The focus of this profile is to 219 enable interoperation between security sources and acceptors on an 220 open network, where more explicit COSE parameters make it easier for 221 BPSec acceptors to avoid assumptions and avoid out-of-band 222 parameters. The requirements of this profile still allow the use of 223 potentially not-easily-interoperable algorithms and message/recipient 224 configurations for use by private networks, where message size is 225 more important than explicit COSE parameters. 227 4.1. Interoperability Algorithms 229 [NOTE: The required list is identical to the 230 [I-D.ietf-dtn-bpsec-interop-sc] list.] The set of integrity 231 algorithms needed for interoperability is listed here. The full set 232 of COSE algorithms available is managed at [IANA-COSE]. 234 Implementations conforming to this specification SHALL support the 235 symmetric keyed algorithms of Table 3. Implementations capable of 236 doing so SHOULD support the asymmetric keyed and key-encryption 237 algorithms of Table 3. 239 +------------------+--------+-------------+------+------------------+ 240 | BPSec Block | COSE | Name | Code | Implementation | 241 | | Layer | | | Requirements | 242 +------------------+--------+-------------+------+------------------+ 243 | Integrity | 1 | HMAC | 5 | Required | 244 | | | 256/256 | | | 245 | | | | | | 246 | Integrity | 1 | ES256 | -7 | Recommended | 247 | | | | | | 248 | Integrity | 1 | PS256 | -37 | Recommended | 249 | | | | | | 250 | Confidentiality | 1 | A256GCM | 3 | Required | 251 | | | | | | 252 | Confidentiality | 2 | A256KW | -5 | Recommended | 253 | | | | | | 254 | Integrity or | 2 | ECDH-ES + | -31 | Recommended | 255 | Confidentiality | | A256KW | | | 256 | | | | | | 257 | Integrity or | 2 | RSAES-OAEP | -41 | Recommended | 258 | Confidentiality | | w/ SHA-256 | | | 259 +------------------+--------+-------------+------+------------------+ 261 Table 3: Interoperability Algorithms 263 The following are recommended key and recipient uses within COSE/ 264 BPSec: 266 Symmetric Key Integrity: When generating a BIB result from a 267 symmetric key, implementations SHOULD use either a COSE_Mac0 or a 268 COSE_Mac using the private key directly. When a COSE_Mac is used 269 with a direct key, the recipient layer SHOULD include a key 270 identifier. 272 EC Keypair Integrity: When generating a BIB result from an EC 273 keypair, implementations SHOULD use either a COSE_Sign1 or a 274 COSE_Sign using the private key directly or a COSE_Mac from a 275 symmetric key with a layer-2 encryption of the symmetric key. 276 When a COSE_Sign or COSE_Mac is used with EC keypair, the 277 recipient layer SHOULD include a public key identifier. 279 RSA Keypair Integrity: When generating a BIB result from an RSA 280 keypair, implementations SHOULD use either a COSE_Sign1 or a 281 COSE_Sign using the private key directly or a COSE_Mac from a 282 symmetric key with a layer-2 key-wrap of the symmetric key. When 283 a COSE_Sign or COSE_Mac is used with RSA keypair, the recipient 284 layer SHOULD include a public key identifier. When a COSE_Sign or 285 COSE_Sign1 is used with RSA keypair, the signature uses a maximum- 286 length PSS salt in accordance with [RFC8230]. 288 Symmetric Key Confidentiality: When generating a BCB result from an 289 symmetric key, implementations SHOULD use a COSE_Encrypt message 290 with a recipient containing a key-wrapped CEK. When generating a 291 BCB result from a symmetric key, implementations SHOULD NOT use 292 COSE_Encrypt0 or COSE_Encrypt with direct content encryption key 293 (CEK). Doing so risks key overuse and the vulnerabilities 294 associated with large amount of ciphertext from the same key. 296 EC Keypair Confidentiality: When generating a BCB result from an EC 297 keypair, implementations SHOULD use a COSE_Encrypt message with a 298 recipient containing a key-wrapped CEK. 300 RSA Keypair Confidentiality: When generating a BCB result from an 301 RSA keypair, implementations SHOULD use a COSE_Encrypt message 302 with a recipient containing a key-wrapped CEK. 304 5. Implementation Status 306 [NOTE to the RFC Editor: please remove this section before 307 publication, as well as the reference to [RFC7942] and 308 [github-dtn-bpsec-cose].] 310 This section records the status of known implementations of the 311 protocol defined by this specification at the time of posting of this 312 Internet-Draft, and is based on a proposal described in [RFC7942]. 313 The description of implementations in this section is intended to 314 assist the IETF in its decision processes in progressing drafts to 315 RFCs. Please note that the listing of any individual implementation 316 here does not imply endorsement by the IETF. Furthermore, no effort 317 has been spent to verify the information presented here that was 318 supplied by IETF contributors. This is not intended as, and must not 319 be construed to be, a catalog of available implementations or their 320 features. Readers are advised to note that other implementations can 321 exist. 323 An example implementation of COSE over Blocks has been created as a 324 GitHub project [github-dtn-bpsec-cose] and is intended to use as a 325 proof-of-concept and as a possible source of interoperability 326 testing. This example implementation only handles CBOR encoding/ 327 decoding and cryptographic functions, it does not construct actual 328 BIB or BCB and does not integrate with a BP Agent. 330 6. Security Considerations 332 This section separates security considerations into threat categories 333 based on guidance of BCP 72 [RFC3552]. 335 All of the security considerations of the underlying BPSec 336 [I-D.ietf-dtn-bpsec] apply to these new security contexts. 338 6.1. Threat: BPSec Block Replay 340 The bundle's primary block contains fields which uniquely identify a 341 bundle: the Source Node ID, Creation Timestamp, and fragment 342 parameters (see Section 4.2.2 of [I-D.ietf-dtn-bpbis]). These same 343 fields are used to correlate Administrative Records with the bundles 344 for which the records were generated. Including the primary block in 345 the AAD for BPSec integrity and confidentiality binds the 346 verification of the secured block to its parent bundle and disallows 347 replay of any block with its BIB or BCB. 349 This profile of COSE limits the encryption algorithms to only AEAD in 350 order to include the context of the encrypted data as AAD. If an 351 agent mistakenly allows the use of non-AEAD encryption when 352 decrypting and verifying a BCB, the possibility of block replay 353 attack is present. 355 6.2. Threat: Unidentifiable Key 357 The profile in Section 4.1 recommends key identifiers when possible. 358 If the application using a COSE Integrity or COSE Confidentiality 359 context leaves out key identification data (in a COSE recipient 360 structure), the security acceptor for those BPSec blocks only has the 361 primary block available to use when verifying or decrypting the 362 target block. This leads to a situation, identified in BPSec 363 Security Considerations, where a signature is verified to be valid 364 but not from the expected Security Source. 366 6.3. Threat: Algorithm Vulnerabilities 368 Because this use of COSE leaves the specific algorithms chosen for 369 BIB and BCB use up to the applications securing bundle data, it is 370 important to use only COSE algorithms which are marked as recommended 371 in the IANA registry [IANA-COSE]. 373 7. IANA Considerations 375 Registration procedures referred to in this section are defined in 376 [RFC8126]. 378 7.1. BPSec Security Contexts 380 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following 381 entry has been added to the "BPSec Security Context Identifiers" sub- 382 registry. 384 +--------+----------------------+---------------------+ 385 | Value | Description | Reference | 386 +--------+----------------------+---------------------+ 387 | TBD-CI | COSE Integrity | This specification. | 388 | | | | 389 | TBD-CC | COSE Confidentiality | This specification. | 390 +--------+----------------------+---------------------+ 392 8. Acknowledgments 394 The interoperability minimum algorithms and parameters are based on 395 the draft [I-D.ietf-dtn-bpsec-interop-sc]. 397 9. References 399 9.1. Normative References 401 [I-D.ietf-dtn-bpsec] 402 Birrane, E. and K. McKeever, "Bundle Protocol Security 403 Specification", draft-ietf-dtn-bpsec-22 (work in 404 progress), March 2020. 406 [IANA-BUNDLE] 407 IANA, "Bundle Protocol", 408 . 410 [IANA-COSE] 411 IANA, "CBOR Object Signing and Encryption (COSE)", 412 . 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, 417 . 419 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 420 Writing an IANA Considerations Section in RFCs", BCP 26, 421 RFC 8126, DOI 10.17487/RFC8126, June 2017, 422 . 424 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 425 RFC 8152, DOI 10.17487/RFC8152, July 2017, 426 . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 433 and Encryption (COSE) Messages", RFC 8230, 434 DOI 10.17487/RFC8230, September 2017, 435 . 437 9.2. Informative References 439 [github-dtn-bpsec-cose] 440 Sipos, B., "DTN Bundle Protocol Security COSE Security 441 Contexts", 442 . 444 [I-D.ietf-dtn-bpbis] 445 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 446 Version 7", draft-ietf-dtn-bpbis-25 (work in progress), 447 May 2020. 449 [I-D.ietf-dtn-bpsec-interop-sc] 450 Birrane, E., "BPSec Interoperability Security Contexts", 451 draft-ietf-dtn-bpsec-interop-sc-01 (work in progress), 452 February 2020. 454 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 455 Text on Security Considerations", BCP 72, RFC 3552, 456 DOI 10.17487/RFC3552, July 2003, 457 . 459 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 460 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 461 October 2013, . 463 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 464 Code: The Implementation Status Section", BCP 205, 465 RFC 7942, DOI 10.17487/RFC7942, July 2016, 466 . 468 Appendix A. Examples 470 A.1. Symmetric Key COSE_Mac0 472 This is an example of a MAC with implied recipient (and its key 473 material). The two provided figures are CBOR diagnostic notation 474 [RFC7049] of the target block being signed and the Abstract Security 475 Block (which will itself be enveloped within a BIB). 477 The 256-bit key used is shown below. 479 / signing key / 480 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c' 482 Symmetric Key 484 [ 485 7, / BP version / 486 0, / flags / 487 0, / CRC type / 488 [1, '//dst/'], / destination / 489 [1, '//src/'], / source / 490 [1, '//src/'], / report-to / 491 [0, 40], / timestamp / 492 1000000 / lifetime / 493 ] 495 Figure 1: Primary block CBOR diagnostic 497 [ 498 7, / type code - bundle age / 499 2, / block num / 500 0, / flags / 501 0, / CRC type / 502 h'19012c' / type-specific-data: 503 300 \ age \ 504 / 505 ] 507 Figure 2: Target block CBOR diagnostic 509 The external_aad is the encoded primary block. The payload is the 510 encoded target block. 512 [ 513 'MAC0', / context / 514 h'a10105', / protected / 515 h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018 516 281a000f4240', / external_aad / 517 h'85070200004319012c' / payload / 518 ] 520 Figure 3: MAC_structure CBOR diagnostic 522 [ 523 [2], / targets / 524 0, / security context TBD / 525 0, / flags / 526 [ 527 [ / target block #2 / 528 [ / result / 529 17, / COSE_Mac0 tag / 530 [ 531 h'a10105' / protected { 532 \ alg \ 1:5 \ HMAC 256//256 \ 533 } / , 534 { / unprotected / 535 / kid / 4:'mykey' 536 }, 537 null, / payload / 538 h'd98308918d36dc4190a93f84c8d857015b75b78edea3360282555257c3be 539 f847' / tag / 540 ] 541 ] 542 ] 543 ] 544 ] 546 Figure 4: Abstract Security Block CBOR diagnostic 548 A.2. RSA Keypair COSE_Sign1 550 This is an example of a signature with implied recipient (and its key 551 material). The two provided figures are CBOR diagnostic notation 552 [RFC7049] of the target block being signed and the Abstract Security 553 Block (which will itself be enveloped within a BIB). 555 The 512-bit private key used is below. It is not supposed to be a 556 secure configuration, only intended to explain the procedure. This 557 signature uses zero-length salt for deterministic output, which 558 differs from the parameter specified by [RFC8230] and is not 559 recommended for normal use. 561 -----BEGIN RSA PRIVATE KEY----- 562 MIIBOwIBAAJBAN21GdS0faAYgacepRmbr7TAT0wEuahjrBfAO0Dg1M5d37O9Tx9H 563 vZw2OEcLq2WTvf0Kja1JWpqdoJm17LghhPkCAwEAAQJBAMgkJo9n6EhQFyrgdTZq 564 3vES8gKz+U3TvJUsSdFFpZYsZhUaLKP9oxyIxl3IvK5iS0oAsW0nqI7aMcBoPmxZ 565 pQECIQDuyd5uzvS0wnrsDWoDhiTm6O+PJoMQix9yH99HBUhWKQIhAO2wDP7e/Nnr 566 A7rDSgM6+REGmt8I00NglFwShBUi4HJRAiAiJrLuTCEJXSsxaXW5DU1nzPa+FXb3 567 Pb6Alvha8vF2iQIgbC7WK2dJBNKv9uCOHlxIItSzxtIYfjFGNYYD8i7Wo5ECIQDp 568 5++fp04AMVAnE0uqNEnITkTWb91hAS8IjaYCqLGyEA== 569 -----END RSA PRIVATE KEY----- 571 [ 572 7, / BP version / 573 0, / flags / 574 0, / CRC type / 575 [1, '//dst/'], / destination / 576 [1, '//src/'], / source / 577 [1, '//src/'], / report-to / 578 [0, 40], / timestamp / 579 1000000 / lifetime / 580 ] 582 Figure 5: Primary block CBOR diagnostic 584 [ 585 7, / type code - bundle age / 586 2, / block num / 587 0, / flags / 588 0, / CRC type / 589 h'19012c' / type-specific-data: 590 300 \ age \ 591 / 592 ] 594 Figure 6: Target block CBOR diagnostic 596 The external_aad is the encoded primary block. The payload is the 597 encoded target block. 599 [ 600 'Signature1', / context / 601 h'a1013824', / protected / 602 h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018 603 281a000f4240', / external_aad / 604 h'85070200004319012c' / payload / 605 ] 607 Figure 7: Sig_structure CBOR diagnostic 609 [ 610 [2], / targets / 611 0, / security context TBD / 612 0, / flags / 613 [ 614 [ / target block #2 / 615 [ / result / 616 18, / COSE_Sign1 tag / 617 [ 618 h'a1013824' / protected { 619 \ alg \ 1:-37 \ PS256 \ 620 } / , 621 { / unprotected / 622 / kid / 4:'mykey' 623 }, 624 null, / payload / 625 h'1a35746072396c74275fd7b443a0d7391a0f92012a53e0accc543daa51ae 626 6faae551a4843a0bc7c3bf808e3638ddc381355b54cc60f4ca9dea15923b 627 5986e758' / signature / 628 ] 629 ] 630 ] 631 ] 632 ] 634 Figure 8: Abstract Security Block CBOR diagnostic 636 A.3. Symmetric Key COSE_Encrypt0 638 This is an example of an encryption with implied recipient (and its 639 direct content encryption key). The provided figures are CBOR 640 diagnostic notation [RFC7049] of the target block being encrypted, 641 the Abstract Security Block (which will itself be enveloped within a 642 BCB), and the resulting target block. 644 This example uses a single shared content encryption key, which is 645 not recommended for normal use. The 256-bit key used is shown below. 646 A random IV is generated for this operation and is indicated in a 647 standard way in the unprotected header. 649 / content encryption key / 650 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c' 652 Symmetric Keys 654 [ 655 7, / BP version / 656 0, / flags / 657 0, / CRC type / 658 [1, '//dst/'], / destination / 659 [1, '//src/'], / source / 660 [1, '//src/'], / report-to / 661 [0, 40], / timestamp / 662 1000000 / lifetime / 663 ] 665 Figure 9: Primary block CBOR diagnostic 667 [ 668 7, / type code - bundle age / 669 2, / block num / 670 0, / flags / 671 0, / CRC type / 672 h'19012c' / type-specific-data: 673 300 \ age \ 674 / 675 ] 677 Figure 10: Initial Target block CBOR diagnostic 679 The external_aad is a concatenation of the encoded primary block and 680 the encoded augmented target block (its block data removed). 682 [ 683 'Encrypt0', / context / 684 h'a10103', / protected / 685 h'880700008201662f2f6473742f8201662f2f7372632f8201662f2f7372632f820018 686 281a000f4240850702000040' / external_aad / 687 ] 689 Figure 11: Enc_structure CBOR diagnostic 691 [ 692 [2], / targets / 693 0, / security context TBD / 694 0, / flags / 695 [ 696 [ / target block #2 / 697 [ / result / 698 16, / COSE_Encrypt0 tag / 699 [ 700 h'a10103', / protected { 701 \ alg \ 1:3 \ A256GCM \ 702 } / 703 { / unprotected / 704 / kid / 4:'mykey', 705 / iv / 5: h'6f3093eba5d85143c3dc484a' 706 }, 707 null / payload / 708 ] 709 ] 710 ] 711 ] 712 ] 714 Figure 12: Abstract Security Block CBOR diagnostic 716 [ 717 7, / type code - bundle age / 718 2, / block num / 719 0, / flags / 720 0, / CRC type / 721 h'63bb16685ef432a0e6f1d404da71959081a715' / ciphertext / 722 ] 724 Figure 13: Encrypted Target block CBOR diagnostic 726 Author's Address 728 Brian Sipos 729 RKF Engineering Solutions, LLC 730 7500 Old Georgetown Road 731 Suite 1275 732 Bethesda, MD 20814-6198 733 United States of America 735 Email: BSipos@rkf-eng.com