idnits 2.17.1 draft-bsipos-dtn-bpsec-cose-06.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Following the same pattern as COSE, when both additional header maps are present in a single security block they SHALL not contain any duplicated labels. Security acceptors SHALL treat a pair of additional header maps containing duplicated labels as invalid. -- The document date (3 June 2021) is 1057 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: '5' on line 381 == Missing Reference: 'AAD-scope' is mentioned on line 381, but not defined -- Looks like a reference, but probably isn't: '0' on line 1242 -- Looks like a reference, but probably isn't: '40' on line 1242 -- Looks like a reference, but probably isn't: '1' on line 1831 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SMI' ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-26 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-08 == Outdated reference: A later version (-11) exists of draft-ietf-dtn-bpsec-default-sc-05 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 3 June 2021 5 Expires: 5 December 2021 7 DTN Bundle Protocol Security COSE Security Context 8 draft-bsipos-dtn-bpsec-cose-06 10 Abstract 12 This document defines a security context suitable for using CBOR 13 Object Signing and Encryption (COSE) algorithms within Bundle 14 Protocol Security (BPSec) integrity and confidentiality blocks. A 15 profile of COSE and for PKIX certificates are 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 5 December 2021. 35 Copyright Notice 37 Copyright (c) 2021 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 4 54 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 4 57 2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2.1. Raw Public Key Containers . . . . . . . . . . . . . . 6 60 2.2.2. Additional Header Maps . . . . . . . . . . . . . . . 7 61 2.2.3. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 8 62 2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 10 64 2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 11 65 2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 11 66 2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 12 67 2.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 12 68 2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 13 69 2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 13 70 2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 13 71 2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 15 72 3. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 15 73 3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 15 74 3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 16 75 3.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 18 76 3.3.1. Policy Recommendations . . . . . . . . . . . . . . . 19 77 4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 20 78 4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 21 79 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 22 82 6.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 23 83 6.3. Threat: Certificate Validation Vulnerabilities . . . . . 23 84 6.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 23 85 6.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 23 86 6.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 24 87 6.7. Threat: Passive Leak of Key Material . . . . . . . . . . 24 88 6.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 24 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 25 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 9.2. Informative References . . . . . . . . . . . . . . . . . 27 95 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 96 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 30 97 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 31 98 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 33 99 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 36 100 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 38 101 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 41 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 104 1. Introduction 106 The Bundle Protocol Security (BPSec) Specification 107 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block 108 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but 109 does not specify any security contexts to be used by either of the 110 security block types. The CBOR Object Signing and Encryption (COSE) 111 specification [RFC8152] defines a structure, encoding, and algorithms 112 to use for cryptographic signing and encryption. 114 This document describes how to use the algorithms and encodings of 115 COSE within BPSec blocks to apply those algorithms to Bundle security 116 in Section 2. A bare minimum of interoperability algorithms and 117 algorithm parameters is specified by this document in Section 3. The 118 focus of the recommended algorithms is to allow BPSec to be used in a 119 Public Key Infrastructure (PKI) as described in Section 1.2. 121 Examples of specific uses are provided in Appendix A to aid in 122 implementation support of the interoperability algorithms. 124 1.1. Scope 126 This document describes a profile of COSE which is tailored for use 127 in BPSec and a method of including full COSE messages within BPSec 128 security blocks. This document does not address: 130 * Policies or mechanisms for issuing Public Key Infrastructure Using 131 X.509 (PKIX) certificates; provisioning, deploying, or accessing 132 certificates and private keys; deploying or accessing certificate 133 revocation lists (CRLs); or configuring security parameters on an 134 individual entity or across a network. 136 * Uses of COSE beyond the profile defined in this document. 138 * How those COSE algorithms are intended to be used within a larger 139 security context. Many header parameters used by COSE (e.g., key 140 identifiers) depend on the network environment and security policy 141 related to that environment. 143 1.2. PKIX Environments and CA Policy 145 This specification gives requirements about how to use PKIX 146 certificates issued by a Certificate Authority (CA), but does not 147 define any mechanisms for how those certificates come to be. 149 To support the PKIX uses defined in this document, the CA(s) issuing 150 certificates for BP nodes are aware of the end use of the 151 certificate, have a mechanism for verifying ownership of a Node ID, 152 and are issuing certificates directly for that Node ID. BPSec 153 security acceptors authenticate the Node ID of security sources when 154 verifying integrity (see Section 2.6.1) using a public key provided 155 by a PKIX certificate (see Section 2.6.1) following the certificate 156 profile of Section 4. 158 1.3. Use of CDDL 160 This document defines CBOR structure using the Concise Data 161 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 162 can be extracted from the XML version of this document using the 163 XPath expression: 165 '//sourcecode[@type="cddl"]' 167 The following initial fragment defines the top-level symbols of this 168 document's CDDL, including the ASB data structure with its parameter/ 169 result sockets. 171 start = bpsec-cose-asb / AAD-structure / 172 primary-block / extension-block / 173 MAC_structure / Sig_structure / Enc_structure / COSE_KeySet 175 1.4. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 2. BPSec Security Context 185 This document specifies a single security context for use in both 186 BPSec integrity and confidentiality blocks. This is done to save 187 code points allocated to this specification and to simplify the 188 encoding of COSE-in-BPSec; the BPSec block type uniquely defines the 189 acceptable parameters and COSE messages which can be present. 191 The COSE security context SHALL have the Security Context ID 192 specified in Section 7.1. 194 Both types of security block can use the same parameters, defined in 195 Section 2.2, to carry public key-related information and each type of 196 security block allows specific COSE message results, defined in 197 Section 2.3. 199 ; Specialize the ASB for this context 200 bpsec-cose-asb = bpsec-context-use< 201 0, ; Context ID TBD-COSE 202 $bpsec-cose-param, 203 $bpsec-cose-result 204 > 205 $ext-data-asb /= bpsec-cose-asb 207 Figure 1: COSE context declaration CDDL 209 2.1. Security Scope 211 The scope here refers to the set of information used by the security 212 context to cryptographically bind with the plaintext data being 213 integrity-protected or confidentiality-protected. This information 214 is generically referred to as additional authenticated data (AAD), 215 which is also the term used by COSE to describe the same data. 217 The sources for AAD within the COSE context are described below, 218 controlled by the AAD Scope Flags parameter of Section 2.2.3, and 219 implemented as defined in Section 2.5.1. 221 Bundle Primary Block The primary block identifies a bundle and, once 222 created, the contents of this block are immutable. Changes to the 223 primary block associated with the security target indicate that 224 the target is no longer in its original bundle. Including this 225 data as part of AAD ensures that security target appears in the 226 same bundle that the security source intended. 228 Target Block Metadata When the target block is a canonical block 229 (i.e., not the primary block) it contains its block-type-specific 230 data, which is the subject of the security operation, but also 231 metadata identifying the block. This metadata explicitly excludes 232 the CRC type and value fields because the CRC is derived from the 233 block-type-specific data. Including this data as part of AAD 234 ensures that the target data appears in the same block that the 235 security source intended. 237 Security Block Metadata The BPSec block containing the security 238 result for which the AAD is assembled also has metadata 239 identifying the block. Including this data as part of AAD ensures 240 that the security result appears in the same block that the 241 security source intended. 243 2.2. Parameters 245 Each COSE context parameter value SHALL consist of the COSE structure 246 indicated by Table 1 in its decoded (CBOR item) form. Each security 247 block MAY contain any number of each parameter type. When a 248 parameter is not present, the security acceptor SHALL use the Default 249 Value of Table 1. 251 +===========+========================+==================+===========+ 252 | Parameter | Parameter Structure | Reference | Default | 253 | ID | | | Value | 254 +===========+========================+==================+===========+ 255 | 1 | COSE_Key | [RFC8152] | none | 256 +-----------+------------------------+------------------+-----------+ 257 | 2 | COSE_KeySet | [RFC8152] | none | 258 +-----------+------------------------+------------------+-----------+ 259 | 3 | additional-protected | Section 2.2.2 | "''" | 260 | | | of this | (empty | 261 | | | document | bstr) | 262 +-----------+------------------------+------------------+-----------+ 263 | 4 | additional-unprotected | Section 2.2.2 | "{}" | 264 | | | of this | (empty | 265 | | | document | map) | 266 +-----------+------------------------+------------------+-----------+ 267 | 5 | AAD_Scope | Section 2.2.3 | "0x7" | 268 | | | of this | (all AAD | 269 | | | document | contexts) | 270 +-----------+------------------------+------------------+-----------+ 272 Table 1: COSE Security Parameters 274 2.2.1. Raw Public Key Containers 276 Implementations capable of handling asymmetric-keyed algorithms 277 SHOULD support raw public key handling in COSE_Key and COSE_KeySet 278 parameters. 280 No more than one total COSE_Key or COSE_KeySet parameter SHALL be 281 present in a single security block. Security acceptors are sill 282 required to aggregate multiple parameters, if present, in 283 Section 3.3. 285 Key container parameters SHALL NOT contain any private key material. 286 The security parameters are all stored in the bundle as plaintext and 287 are visible to any bundle handlers. 289 $bpsec-cose-param /= [1, COSE_Key] 290 $bpsec-cose-param /= [2, COSE_KeySet] 292 Figure 2: Key Containers CDDL 294 2.2.2. Additional Header Maps 296 The two parameters Additional Protected and Additional Unprotected 297 allow de-duplicating header items which are common to all COSE 298 results. Both additional header values contain a CBOR map which is 299 to be merged with each of the result's unprotected headers. Although 300 the additional header items are all treated as unprotected from the 301 perspective of the COSE message, the additional protected map is 302 included within the "external_aad" (see Section 2.5.1). The expected 303 use of additional header map is to contain a certificate (chain) or 304 identifier (see Section 3.3) which applies to all results in the same 305 security block. 307 Following the same pattern as COSE, when both additional header maps 308 are present in a single security block they SHALL not contain any 309 duplicated labels. Security acceptors SHALL treat a pair of 310 additional header maps containing duplicated labels as invalid. 312 No more than one of each Additional Protected and Additional 313 Unprotected parameter SHALL be present in a single security block. 314 Security acceptors SHALL treat a security block with multiple 315 instances of either additional header type as invalid. There is no 316 well-defined behavior for a security acceptor to handle multiple 317 Additional Protected parameters. 319 Security sources SHOULD NOT include an additional header parameter 320 which represents an empty map. Security acceptors SHALL handle empty 321 header map parameters, specifically the Additional Protected 322 parameter because it is part of the external_aad. 324 Security acceptors SHALL treat the aggregate of both additional 325 header maps as being present in the "unprotected" header map of the 326 highest-layers of the COSE message of each result. For single-layer 327 messages (i.e., COSE_Encrypt0, COSE_MAC0, and COSE_Sign1) the 328 additional headers apply to the message itself (layer 1) and for 329 other messages the additional headers apply to the final recipients. 330 If the same header label is present in a additional header map and a 331 COSE layer's headers the item in the result header SHALL take 332 precedence (i.e., the additional header items are added only if they 333 are not already present in a layer's header). 335 Additional header maps SHALL NOT contain any private key material. 336 The security parameters are all stored in the bundle as plaintext and 337 are visible to any bundle handlers. 339 $bpsec-cose-param /= [3, additional-protected] 340 additional-protected = empty_or_serialized_map 342 $bpsec-cose-param /= [4, additional-unprotected] 343 additional-unprotected = header_map 345 Figure 3: Additional Headers CDDL 347 2.2.3. AAD Scope 349 The AAD Scope parameter controls what data is included in the AAD for 350 both integrity and confidentiality operations. The AAD Scope 351 parameter SHALL be encoded as a uint value with bit flags defined in 352 Table 2. All reserved bits SHALL be set to zero (which will be 353 elided by CBOR encoding) by security sources. All reserved bits 354 SHALL be ignored by security acceptors. The default value for this 355 parameter has all flags set, meaning the AAD includes all available 356 context. 358 A CDDL representation of this definition is included in Figure 4 for 359 reference. 361 +==================+========+===============================+ 362 | Name | Code | Description | 363 +==================+========+===============================+ 364 | has-primary-ctx | 0x01 | If bit is set, indicates that | 365 | | | the primary block is included | 366 | | | in AAD scope. | 367 +------------------+--------+-------------------------------+ 368 | has-target-ctx | 0x02 | If bit is set, indicates that | 369 | | | the target block metadata is | 370 | | | included in AAD scope. | 371 +------------------+--------+-------------------------------+ 372 | has-security-ctx | 0x04 | If bit is set, indicates that | 373 | | | the security block metadata | 374 | | | is included in AAD scope. | 375 +------------------+--------+-------------------------------+ 376 | Reserved | others | | 377 +------------------+--------+-------------------------------+ 379 Table 2: AAD Scope Flags 381 $bpsec-cose-param /= [5, AAD-scope] 382 AAD-scope = uint .bits AAD-scope-flags 383 AAD-scope-flags = &( 384 has-primary-ctx: 0, 385 has-target-ctx: 1, 386 has-security-ctx: 2, 387 ) 389 Figure 4: AAD Scope CDDL 391 2.3. Results 393 Although each COSE context result is a COSE message, the types of 394 message allowed depend upon the security block type in which the 395 result is present: only MAC or signature messages are allowed in a 396 BIB and only encryption messages are allowed in a BCB. 398 The code points for Result ID values are identical to the existing 399 COSE message-marking tags in Section 2 of [RFC8152]. This avoids the 400 need for value-mapping between code points of the two registries. 402 When embedding COSE messages, the message CBOR structure SHALL be 403 encoded as a byte string used as the result value. This allows a 404 security acceptor to skip over unwanted results without needing to 405 decode the result structure. When embedding COSE messages, the CBOR- 406 tagged form SHALL NOT be used. The Result ID values already provide 407 the same information as the COSE tags (using the same code points). 409 These generic requirements are formalized in the CDDL fragment of 410 Figure 5. 412 $bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0] 413 $bpsec-cose-result /= [17, bstr .cbor COSE_Mac0] 414 $bpsec-cose-result /= [18, bstr .cbor COSE_Sign1] 415 $bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt] 416 $bpsec-cose-result /= [97, bstr .cbor COSE_Mac] 417 $bpsec-cose-result /= [98, bstr .cbor COSE_Sign] 419 Figure 5: COSE context results CDDL 421 2.3.1. Integrity Messages 423 When used within a Block Integrity Block, the COSE context SHALL 424 allow only the Result IDs from Table 3. Each integrity result value 425 SHALL consist of the COSE message indicated by Table 3 in its non- 426 tagged encoded form. 428 +===========+====================+===========+ 429 | Result ID | Result Structure | Reference | 430 +===========+====================+===========+ 431 | 97 | encoded COSE_Mac | [RFC8152] | 432 +-----------+--------------------+-----------+ 433 | 17 | encoded COSE_Mac0 | [RFC8152] | 434 +-----------+--------------------+-----------+ 435 | 98 | encoded COSE_Sign | [RFC8152] | 436 +-----------+--------------------+-----------+ 437 | 18 | encoded COSE_Sign1 | [RFC8152] | 438 +-----------+--------------------+-----------+ 440 Table 3: COSE Integrity Results 442 Each integrity result SHALL use the "detached" payload form with 443 "null" payload value. The integrity result for COSE_Mac and 444 COSE_Mac0 messages are computed by the procedure in Section 6.3 of 445 [RFC8152]. The integrity result for COSE_Sign and COSE_Sign1 446 messages are computed by the procedure in Section 4.4 of [RFC8152]. 448 The COSE "protected attributes from the application" used for a 449 signature or MAC result SHALL be the encoded data defined in 450 Section 2.5.1. The COSE payload used for a signature or MAC result 451 SHALL be either the block-type-specific data of the target, if the 452 target is not the primary block, or an empty byte string if the 453 target is the primary block. 455 2.3.2. Confidentiality Messages 457 When used within a Block Confidentiality Block, COSE context SHALL 458 allow only the Result IDs from Table 4. Each confidentiality result 459 value SHALL consist of the COSE message indicated by Table 4 in its 460 non-tagged encoded form. 462 +===========+=======================+===========+ 463 | Result ID | Result Structure | Reference | 464 +===========+=======================+===========+ 465 | 96 | encoded COSE_Encrypt | [RFC8152] | 466 +-----------+-----------------------+-----------+ 467 | 16 | encoded COSE_Encrypt0 | [RFC8152] | 468 +-----------+-----------------------+-----------+ 470 Table 4: COSE Confidentiality Results 472 Only algorithms which support Authenticated Encryption with 473 Authenticated Data (AEAD) SHALL be usable in the first (content) 474 layer of a confidentiality result. Because COSE encryption with AEAD 475 appends the authentication tag with the ciphertext, the size of the 476 block-type-specific-data will grow after an encryption operation. 477 Security acceptors MUST NOT assume that the size of the plaintext is 478 the same as the size of the ciphertext. 480 Each confidentiality result SHALL use the "detached" payload form 481 with "null" payload value. The confidentiality result for 482 COSE_Encrypt and COSE_Encrypt0 messages are computed by the procedure 483 in Section 5.3 of [RFC8152]. 485 The COSE "protected attributes from the application" used for an 486 encryption result SHALL be the encoded data defined in Section 2.5.1. 487 The COSE payload used for an encryption result SHALL be the block- 488 type-specific data of the target. Because confidentiality of the 489 primary block is disallowed by BPSec, there is no logic here for 490 handling a BCB with a target on the primary block. 492 2.4. Key Considerations 494 This specification does not impose any additional key requirements 495 beyond those already specified for each COSE algorithm required in 496 Section 3. 498 2.5. Canonicalization Algorithms 500 Generating or processing COSE messages for the COSE context follows 501 the profile defined in Section 3 with the "protected attributes from 502 the application" (i.e., the "external_aad" item) generated as defined 503 in Section 2.5.1. 505 2.5.1. Generating AAD 507 The AAD used for both integrity and confidentiality messages SHALL be 508 the deterministically encoded form of a CBOR array containing the 509 following: 511 1. The first item SHALL be either: the CBOR array (unencoded) form 512 of the primary block of the bundle if the AAD Scope has the has- 513 primary-ctx flag set, otherwise the null value. 515 2. The second item SHALL be either: a CBOR array containing the 516 first three fields of the target block (i.e., the block type 517 code, block number, and control flags) if the AAD Scope has the 518 has-target-ctx flag set, otherwise the null value. 520 3. The third item SHALL be either: a CBOR array containing the first 521 three fields of the security block containing the result (i.e., 522 the block type code, block number, and control flags) if the AAD 523 Scope has the has-security-ctx flag set, otherwise the null 524 value. 526 4. The fourth item SHALL be the Additional Protected header map, 527 which is a bstr value and has a default value of the empty bstr. 529 A CDDL representation of this data is shown below in Figure 6. 531 AAD-structure = [ 532 ; non-null if has-primary-ctx is set 533 primary-ctx: null / primary-block, 534 ; non-null if has-target-ctx is set 535 target-ctx: null / block-metadata, 536 ; non-null if has-security-ctx is set 537 security-ctx: null / block-metadata, 538 ; copy of additional-protected (or default) 539 additional-protected 540 ] 541 ; The first three fields of BP "canonical-block-structure" 542 block-metadata = [ 543 block-type-code: uint, 544 block-number: uint, 545 block-control-flags, 546 ] 548 Figure 6: COSE context AAD CDDL 550 2.5.2. Payload Data 552 When correlating between BPSec target block-type-specific-data and 553 COSE plaintext or payload, any byte string SHALL be handled in its 554 decoded (CBOR item) form. This means any CBOR header or tag in a 555 source encoding are ignored for the purposes of security processing. 556 This also means that if the source byte string was encoded in a non- 557 conforming way, for example in indefinite-length form or with a non- 558 minimum-size length, the security processing always treats it in a 559 deterministically encoded CBOR form. 561 2.6. Processing 563 This section describes block-level requirements for handling COSE 564 security data. 566 All security results generated for BIB or BCB blocks SHALL conform to 567 the COSE profile of Section 3 with header augmentation as defined in 568 Section 2.2.2. 570 2.6.1. Node Authentication 572 This section explains how the certificate profile of Section 4 is 573 used by a security acceptor to both validate an end-entity 574 certificate and to use that certificate to authenticate the security 575 source for an integrity result. For a confidentiality result, some 576 of the requirements in this section are implicit in an implementation 577 using a private key associated with a certificate used by a result 578 recipient. It is an implementation matter to ensure that a BP agent 579 is configured to generate or receive results associated with valid 580 certificates. 582 A security source MAY prohibit generating a result (either integrity 583 or confidentiality) for an end-entity certificate which is not 584 considered valid according to Section 2.6.1.2. Generating a result 585 which is likely to be discarded is wasteful of bundle size and 586 transport resources. 588 2.6.1.1. Certificate Identification 590 Because of the standard policy of using separate certificates for 591 transport, signing, and encryption (see Section 4.1) a single Node ID 592 is likely to be associated with multiple certificates, and any or all 593 of those certificates MAY be present within an "x5bag" in an 594 Additional Protected parameter (see Section 2.2.2). When present, a 595 security acceptor SHALL use an "x5chain" or "x5t" to identify an end- 596 entity certificate to use for result processing. Security acceptors 597 SHALL NOT assume that a validated certificate containing a NODE-ID 598 matching a security source is enough to associate a certificate with 599 a COSE message or recipient (see Section 3.3). 601 2.6.1.2. Certificate Validation 603 For each end-entity certificate contained in or identified by by a 604 COSE result, the security acceptor SHALL perform the certification 605 path validation of Section 6 of [RFC5280] up to one of the acceptor's 606 trusted CA certificates. When evaluating a certificate Validity 607 period, the security acceptor SHALL use the bundle Creation Timestamp 608 time (if not unknown) as the reference instead of the current time. 609 If enabled by local policy, the entity SHALL perform an OCSP check of 610 each certificate providing OCSP authority information in accordance 611 with [RFC6960]. If certificate validation fails or if security 612 policy disallows a certificate for any reason, the acceptor SHALL 613 treat the associated security result as failed. Leaving out part of 614 the certification chain can cause the entity to fail to validate a 615 certificate if the left-out certificates are unknown to the entity 616 (see Section 6.2). 618 For each end-entity certificate contained in or identified by a COSE 619 context result, the security acceptor SHALL apply security policy to 620 the Key Usage extension (if present) and Extended Key Usage extension 621 (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the 622 profile in Section 4. 624 2.6.1.3. Node ID Authentication 626 If required by security policy, for each end-entity certificate 627 referenced by a COSE context integrity result the security acceptor 628 SHALL validate the certificate NODE-ID in accordance with Section 6 629 of [RFC6125] using the NODE-ID reference identifier from the Security 630 Source of the containing security block. If the NODE-ID validation 631 result is Failure or if the result is Absent and security policy 632 requires an authenticated Node ID, the security acceptor SHALL treat 633 the result as failed. 635 2.6.2. Policy Recommendations 637 A RECOMMENDED security policy is to enable the use of OCSP checking 638 when internet connectivity is present. A RECOMMENDED security policy 639 is that if an Extended Key Usage is present that it needs to contain 640 "id-kp-bundleSecurity" of [IANA-SMI] to be usable as an end-entity 641 certificate for COSE security results. A RECOMMENDED security policy 642 is to require a validated Node ID (of Section 2.6.1.3) and to ignore 643 any other identifiers in the end-entity certificate. 645 This policy relies on and informs the certificate requirements in 646 Section 3.3.1 and Section 4. This policy assumes that a DTN-aware CA 647 (see Section 1.2) will only issue a certificate for a Node ID when it 648 has verified that the private key holder actually controls the DTN 649 node; this is needed to avoid the threat identified in Section 6.4. 650 This policy requires that a certificate contain a NODE-ID and allows 651 the certificate to also contain network-level identifiers. A 652 tailored policy on a more controlled network could relax the 653 requirement on Node ID validation and/or Extended Key Usage presence. 655 3. COSE Profile for BPSec 657 This section contains requirements which apply to the use of COSE 658 within the BPSec security context defined in this document. 660 3.1. COSE Messages 662 When generating a BPSec result, security sources SHALL use only COSE 663 labels with a uint value. When processing a BPSec result, security 664 acceptors MAY handle COSE labels with with a tstr value. 666 When used in a BPSec result, each COSE message SHALL contain an 667 explicit algorithm identifier in the lower (content) layers. When 668 available and not implied by the bundle source, a COSE message SHALL 669 contain a key identifier in the highest (recipient) layer. See 670 Section 3.3 for specifics about asymmetric key identifiers. When a 671 key identifier is not available, BPSec acceptors SHALL use the 672 Security Source (if available) and the Bundle Source to imply which 673 keys can be used for security operations. Using implied keys has an 674 interoperability risk, see Section 6.5 for details. A BPSec security 675 operation always occurs within the context of the immutable primary 676 block with its parameters (specifically the Source Node ID) and the 677 security block with its optional Security Source. 679 The algorithms required by this profile focuses on networks using 680 shared symmetric-keys, with recommended algorithms for Elliptic Curve 681 (EC) keypairs and RSA keypairs. The focus of this profile is to 682 enable interoperation between security sources and acceptors on an 683 open network, where more explicit COSE parameters make it easier for 684 BPSec acceptors to avoid assumptions and avoid out-of-band 685 parameters. The requirements of this profile still allow the use of 686 potentially not-easily-interoperable algorithms and message/recipient 687 configurations for use by private networks, where message size is 688 more important than explicit COSE parameters. 690 3.2. Interoperability Algorithms 692 The set of integrity algorithms needed for interoperability is listed 693 here. The full set of COSE algorithms available is managed at 694 [IANA-COSE]. 696 Implementations conforming to this specification SHALL support the 697 symmetric keyed and key-encryption algorithms of Table 5. 698 Implementations capable of doing so SHOULD support the asymmetric 699 keyed and key-encryption algorithms of Table 5. 701 | The layer-1 required list is identical to the 702 | [I-D.ietf-dtn-bpsec-default-sc] context list. 704 +=================+============+============+======+================+ 705 | BPSec Block | COSE | Name | Code | Implementation | 706 | | Layer | | | Requirements | 707 +=================+============+============+======+================+ 708 | Integrity | 1 | HMAC | 5 | Required | 709 | | | 256/256 | | | 710 +-----------------+------------+------------+------+----------------+ 711 | Integrity | 1 | ES256 | -7 | Recommended | 712 +-----------------+------------+------------+------+----------------+ 713 | Integrity | 1 | EdDSA | -8 | Recommended | 714 +-----------------+------------+------------+------+----------------+ 715 | Integrity | 1 | PS256 | -37 | Recommended | 716 +-----------------+------------+------------+------+----------------+ 717 | Confidentiality | 1 | A256GCM | 3 | Required | 718 +-----------------+------------+------------+------+----------------+ 719 | Confidentiality | 2 | A256KW | -5 | Required | 720 +-----------------+------------+------------+------+----------------+ 721 | Confidentiality | 2 | ECDH-ES + | -31 | Recommended | 722 | | | A256KW | | | 723 +-----------------+------------+------------+------+----------------+ 724 | Confidentiality | 2 | ECDH-SS + | -34 | Recommended | 725 | | | A256KW | | | 726 +-----------------+------------+------------+------+----------------+ 727 | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended | 728 | | | w/ SHA-256 | | | 729 +-----------------+------------+------------+------+----------------+ 731 Table 5: Interoperability Algorithms 733 The following are recommended key and recipient uses within COSE/ 734 BPSec: 736 Symmetric Key Integrity: When generating a BIB result from a 737 symmetric key, implementations SHALL use a COSE_Mac0 using the 738 private key directly. When a COSE_Mac0 is used with a direct key, 739 the headers SHALL include a key identifier ("kid" header). 741 EC Keypair Integrity: When generating a BIB result from an EC 742 keypair, implementations SHALL use a COSE_Sign1 using the private 743 key directly. When a COSE_Sign1 is used with an EC keypair, the 744 headers SHALL include a public key identifier (see Section 3.3). 746 RSA Keypair Integrity: When generating a BIB result from an RSA 747 keypair, implementations SHALL use a COSE_Sign1 using the private 748 key directly. When a COSE_Sign1 is used with an RSA keypair, the 749 headers SHALL include a public key identifier (see Section 3.3). 750 When a COSE signature is generated with an RSA keypair, the 751 signature uses a PSS salt in accordance with Section 2 of 752 [RFC8230]. 754 Symmetric Key Confidentiality: When generating a BCB result from an 755 symmetric key, implementations SHALL use a COSE_Encrypt message 756 with a recipient containing an indirect (wrapped or derived) 757 content encryption key (CEK). When generating a BCB result from a 758 symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or 759 COSE_Encrypt with direct CEK. Doing so risks key overuse and the 760 vulnerabilities associated with large amount of ciphertext from 761 the same key. When a COSE_Encrypt is used with an overall key- 762 encryption key (KEK), the recipient layer SHALL include a key 763 identifier for the KEK. 765 EC Keypair Confidentiality: When generating a BCB result from an EC 766 keypair, implementations SHALL use a COSE_Encrypt message with a 767 recipient containing an indirect (wrapped or derived) CEK. When a 768 COSE_Encrypt is used with an EC keypair, the recipient layer SHALL 769 include a public key identifier (see Section 3.3). When a 770 COSE_Encrypt is used with an EC keypair, the security source SHALL 771 either generate an ephemeral EC keypair or choose a unique PartyU 772 Nonce for each security operation. When processing a COSE_Encrypt 773 with an EC keypair, the security acceptor SHALL process all KDF 774 and HMAC context data from the recipient headers in accordance 775 with Section 11.2 of [RFC8152] even though the source is not 776 required to provide any of those parameters. 778 RSA Keypair Confidentiality: When generating a BCB result from an 779 RSA keypair, implementations SHALL use a COSE_Encrypt message with 780 a recipient containing a key-wrapped CEK. When a COSE_Encrypt is 781 used with an RSA keypair, the recipient layer SHALL include a 782 public key identifier (see Section 3.3). 784 3.3. Asymmetric Key Types and Identifiers 786 This section applies when a BIB uses a public key for verification or 787 key-wrap, or when a BCB uses a public key for encryption or key-wrap. 788 When using asymmetric keyed algorithms, the security source SHALL 789 include a public key container or public key identifier as a 790 recipient header. The public key identifier SHALL be either a "kid" 791 of [RFC8152], an "x5t" or "x5chain" of [I-D.ietf-cose-x509], or an 792 equivalent identifier. 794 When a BIB result contains a "kid" identifier, the security source 795 MAY include an appropriate COSE public key "COSE_Key" in a key 796 container security parameter (see Section 2.2.1). When BIB result 797 contains a "x5t" identifier, the security source MAY include an 798 appropriate PKIX certificate container ("x5chain" or "x5bag" of 799 [I-D.ietf-cose-x509]) in a direct COSE header or an additional header 800 security parameter (see Section 2.2.2). When a BIB result contains 801 an "x5chain", the security source SHOULD NOT also include an "x5t" as 802 the first certificate in the chain is implicitly the applicable end- 803 entity certificate. For a BIB, if all potential security acceptors 804 are known to possess related public key and/or certificate data then 805 the public key or additional header parameters can be omitted. Risks 806 of not including related data are described in Section 6.5 and 807 Section 6.6. 809 When present, public keys and certificates SHOULD be included as 810 additional header parameters rather than within result COSE messages. 811 This provides size efficiency when multiple security results are 812 present because they will all be from the same security source and 813 likely share the same public key material. Security acceptors SHALL 814 still process public keys or certificates present in a result message 815 or recipient as applying to that individual COSE level. 817 Security acceptors SHALL aggregate all COSE_Key objects from all 818 parameters within a single BIB or BCB, independent of encoded type or 819 order of parameters. Because each context contains a single set of 820 security parameters which apply to all results in the same context, 821 security acceptors SHALL treat all public keys as being related to 822 the security source itself and potentially applying to every result. 824 3.3.1. Policy Recommendations 826 The RECOMMENDED priority policy for including PKIX material for BIB 827 results is as follows: 829 1. When receivers are not known to possess certificate chains, a 830 full chain is included (as an "x5chain"). 832 2. When receivers are known to possess root and intermediate CAs, 833 just the end-entity certificate is included (again as an 834 "x5chain"). 836 3. When receivers are known to possess associated chains including 837 end-entity certificates, a certificate thumbnail (as an "x5t"). 839 4. Some arbitrary identifier is used to correlate to an end-entity 840 certificate (as a "kid"). 842 5. The BIB Security Source is used to imply an associated end-entity 843 certificate which identifies that Node ID. 845 When PKIX certificates are used by security acceptors and the end- 846 entity certificate is not explicitly trusted (i.e. pinned), the 847 security acceptor SHALL perform the certification path validation of 848 Section 2.6.1.2 up to one or more trusted CA certificates. Leaving 849 out part of the certification chain can cause the security acceptor 850 to fail to validate a BIB if the left-out certificates are unknown to 851 the acceptor (see Section 6.6). 853 Any end-entity certificate associated with a BPSec security source 854 SHALL adhere to the profile of Section 4. 856 4. PKIX Certificate Profile 858 This section contains requirements on certificates used for the COSE 859 context, while Section 3.3 contains requirements for how such 860 certificates are transported or identified. 862 All end-entity certificates used for BPSec SHALL conform to 863 [RFC5280], or any updates or successors to that profile. 865 This profile requires Version 3 certificates due to the extensions 866 used by this profile. Security acceptors SHALL reject as invalid 867 Version 1 and Version 2 end-entity certificates. 869 Security acceptors SHALL accept certificates that contain an empty 870 Subject field or contain a Subject without a Common Name. Identity 871 information in end-entity certificates is contained entirely in the 872 subjectAltName extension as a NODE-ID, as defined in 873 [I-D.ietf-dtn-tcpclv4]. 875 All end-entity and CA certificates used for BPSec SHOULD contain both 876 a Subject Key Identifier extension in accordance with Section 4.2.1.2 877 of [RFC5280] and an Authority Key Identifier extension in accordance 878 with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT 879 rely on either a Subject Key Identifier and an Authority Key 880 Identifier being present in any received certificate. Including key 881 identifiers simplifies the work of an entity needing to assemble a 882 certification chain. 884 A BPSec end-entity certificate SHALL contain a NODE-ID which 885 authenticates the Node ID of the security source (for integrity) or 886 the security acceptor (for confidentiality). The identifier type 887 NODE-ID is defined in [I-D.ietf-dtn-tcpclv4]. 889 When allowed by CA policy, a BPSec end-entity certificate SHOULD 890 contain a PKIX Extended Key Usage extension in accordance with 891 Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage 892 extension is present, it SHALL contain a key purpose "id-kp- 893 bundleSecurity" of [IANA-SMI]. The "id-kp-bundleSecurity" purpose 894 MAY be combined with other purposes in the same certificate. 896 When allowed by CA policy, a BPSec end-entity certificate SHALL 897 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 898 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE 899 security are: digitalSignature, nonRepudiation, keyEncipherment, and 900 keyAgreement. The specific algorithms used by COSE messages in 901 security results determine which of those key uses are exercised. 902 See Section 4.1 for discussion of key use policies across multiple 903 certificates. 905 A BPSec end-entity certificate MAY contain an Online Certificate 906 Status Protocol (OCSP) URI within an Authority Information Access 907 extension in accordance with Section 4.2.2.1 of [RFC5280]. Security 908 acceptors are not expected to have continuous internet connectivity 909 sufficient to perform OCSP verification. 911 4.1. Multiple-Certificate Uses 913 A RECOMMENDED security policy is to limit asymmetric keys (and thus 914 public key certificates) to single uses among the following: 916 Bundle transport: With key uses as defined in the convergence layer 917 specification(s). 919 Block signing: With key use digitalSignature and/or nonRepudiation. 921 Block encryption: With key use keyEncipherment and/or keyAgreement. 923 This policy is the same one recommended by Section 6 of [RFC8551] for 924 email security and by Section 5.2 of [NIST-SP800-57] more generally. 925 Effectively this means that a BP node uses separate certificates for 926 transport (e.g., as a TCPCL entity), BIB signing (as a security 927 source), and BCB encryption (as a security acceptor). 929 5. Implementation Status 931 This section is to be removed before publishing as an RFC. 933 [NOTE to the RFC Editor: please remove this section before 934 publication, as well as the reference to [RFC7942] and 935 [github-dtn-bpsec-cose].] 936 This section records the status of known implementations of the 937 protocol defined by this specification at the time of posting of this 938 Internet-Draft, and is based on a proposal described in [RFC7942]. 939 The description of implementations in this section is intended to 940 assist the IETF in its decision processes in progressing drafts to 941 RFCs. Please note that the listing of any individual implementation 942 here does not imply endorsement by the IETF. Furthermore, no effort 943 has been spent to verify the information presented here that was 944 supplied by IETF contributors. This is not intended as, and must not 945 be construed to be, a catalog of available implementations or their 946 features. Readers are advised to note that other implementations can 947 exist. 949 An example implementation of COSE over Blocks has been created as a 950 GitHub project [github-dtn-bpsec-cose] and is intended to use as a 951 proof-of-concept and as a possible source of interoperability 952 testing. This example implementation only handles CBOR encoding/ 953 decoding and cryptographic functions, it does not construct actual 954 BIB or BCB and does not integrate with a BP Agent. 956 6. Security Considerations 958 This section separates security considerations into threat categories 959 based on guidance of BCP 72 [RFC3552]. 961 All of the security considerations of the underlying BPSec 962 [I-D.ietf-dtn-bpsec] apply to these new security contexts. 964 6.1. Threat: BPSec Block Replay 966 The bundle's primary block contains fields which uniquely identify a 967 bundle: the Source Node ID, Creation Timestamp, and fragment 968 parameters (see Section 4.3.1 of [I-D.ietf-dtn-bpbis]). These same 969 fields are used to correlate Administrative Records with the bundles 970 for which the records were generated. Including the primary block in 971 the AAD Scope for integrity and confidentiality (see Section 2.2.3) 972 binds the verification of the secured block to its parent bundle and 973 disallows replay of any block with its BIB or BCB. 975 This profile of COSE limits the encryption algorithms to only AEAD in 976 order to include the context of the encrypted data as AAD. If an 977 agent mistakenly allows the use of non-AEAD encryption when 978 decrypting and verifying a BCB, the possibility of block replay 979 attack is present. 981 6.2. Threat: Untrusted End-Entity Certificate 983 The profile in Section 2.6.1 uses end-entity certificates chained up 984 to a trusted root CA. A security source can include a certificate 985 set which does not contain the full chain, possibly excluding 986 intermediate or root CAs. In an environment where security acceptors 987 are known to already contain needed root and intermediate CAs there 988 is no need to include those CAs, but this has a risk of an acceptor 989 not actually having one of the needed CAs. 991 6.3. Threat: Certificate Validation Vulnerabilities 993 Even when a security acceptor is operating properly an attacker can 994 attempt to exploit vulnerabilities within certificate check 995 algorithms or configuration to authenticate using an invalid 996 certificate. An invalid certificate exploit could lead to higher- 997 level security issues and/or denial of service to the Node ID being 998 impersonated. 1000 There are many reasons, described in [RFC5280] and [RFC6125], why a 1001 certificate can fail to validate, including using the certificate 1002 outside of its valid time interval, using purposes for which it was 1003 not authorized, or using it after it has been revoked by its CA. 1004 Validating a certificate is a complex task and can require network 1005 connectivity outside of the primary BP convergence layer network 1006 path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The 1007 configuration and use of particular certificate validation methods 1008 are outside of the scope of this document. 1010 6.4. Threat: BP Node Impersonation 1012 When certificates are referenced by BIB results it is possible that 1013 the certificate does not contain a NODE-ID or does contain one but 1014 has a mismatch with the actual security source (see Section 1.2). 1015 Having a CA-validated certificate does not alone guarantee the 1016 identity of the security source from which the certificate is 1017 provided; additional validation procedures in Section 2.6.1 bind the 1018 Node ID based on the contents of the certificate. 1020 6.5. Threat: Unidentifiable Key 1022 The profile in Section 3.2 recommends key identifiers when possible 1023 and the parameters in section Section 2.2 allow encoding public keys 1024 where available. If the application using a COSE Integrity or COSE 1025 Confidentiality context leaves out key identification data (in a COSE 1026 recipient structure), the security acceptor for those BPSec blocks 1027 only has the primary block available to use when verifying or 1028 decrypting the target block. This leads to a situation, identified 1029 in BPSec Security Considerations, where a signature is verified to be 1030 valid but not from the expected Security Source. 1032 Because the key identifier headers are unprotected (see Section 3.3), 1033 there is still the possibility that an active attacker removes or 1034 alters key identifier(s) in the result. This can cause the security 1035 acceptor to not be able to properly verify a valid signature or not 1036 use the correct private key to decrypt valid ciphertext. 1038 6.6. Threat: Non-Trusted Public Key 1040 The profile in Section 3.2 allows the use of PKIX which typically 1041 involves end-entity certificates chained up to a trusted root CA. 1042 This allows a BIB to contain end-entity certificates not previously 1043 known to a security acceptor but still trust the certificate by 1044 verifying it up to a trusted CA. In an environment where security 1045 acceptors are known to already contain needed root and intermediate 1046 CAs there is no need to include those CAs in a proper chain within 1047 the security parameters, but this has a risk of an acceptor not 1048 actually having one of the needed CAs. 1050 Because the security parameters are not included as AAD, there is 1051 still the possibility that an active attacker removes or alters 1052 certification chain data in the parameters. This can cause the 1053 security acceptor to be able to verify a valid signature but not 1054 trust the public key used to perform the verification. 1056 6.7. Threat: Passive Leak of Key Material 1058 It is important that the key requirements of Section 2.2 apply only 1059 to public keys and PKIX certificates. Including non-public key 1060 material in ASB parameters will expose that material in the bundle 1061 data and over the bundle convergence layer during transport. 1063 6.8. Threat: Algorithm Vulnerabilities 1065 Because this use of COSE leaves the specific algorithms chosen for 1066 BIB and BCB use up to the applications securing bundle data, it is 1067 important to use only COSE algorithms which are marked as recommended 1068 in the IANA registry [IANA-COSE]. 1070 7. IANA Considerations 1072 Registration procedures referred to in this section are defined in 1073 [RFC8126]. 1075 7.1. BPSec Security Contexts 1077 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following 1078 entry has been added to the "BPSec Security Context Identifiers" sub- 1079 registry. 1081 +==========+=============+=====================+ 1082 | Value | Description | Reference | 1083 +==========+=============+=====================+ 1084 | TBD-COSE | COSE | This specification. | 1085 +----------+-------------+---------------------+ 1087 Table 6 1089 8. Acknowledgments 1091 The interoperability minimum algorithms and parameters are based on 1092 the draft [I-D.ietf-dtn-bpsec-default-sc]. 1094 9. References 1096 9.1. Normative References 1098 [IANA-BUNDLE] 1099 IANA, "Bundle Protocol", 1100 . 1102 [IANA-COSE] 1103 IANA, "CBOR Object Signing and Encryption (COSE)", 1104 . 1106 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 1107 . 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, 1111 DOI 10.17487/RFC2119, March 1997, 1112 . 1114 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1115 Housley, R., and W. Polk, "Internet X.509 Public Key 1116 Infrastructure Certificate and Certificate Revocation List 1117 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1118 . 1120 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1121 Verification of Domain-Based Application Service Identity 1122 within Internet Public Key Infrastructure Using X.509 1123 (PKIX) Certificates in the Context of Transport Layer 1124 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1125 2011, . 1127 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1128 Galperin, S., and C. Adams, "X.509 Internet Public Key 1129 Infrastructure Online Certificate Status Protocol - OCSP", 1130 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1131 . 1133 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1134 Writing an IANA Considerations Section in RFCs", BCP 26, 1135 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1136 . 1138 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1139 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1140 . 1142 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1143 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1144 May 2017, . 1146 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 1147 and Encryption (COSE) Messages", RFC 8230, 1148 DOI 10.17487/RFC8230, September 2017, 1149 . 1151 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1152 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1153 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1154 April 2019, . 1156 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1157 Definition Language (CDDL): A Notational Convention to 1158 Express Concise Binary Object Representation (CBOR) and 1159 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1160 June 2019, . 1162 [I-D.ietf-dtn-bpsec] 1163 III, E. J. B. and K. McKeever, "Bundle Protocol Security 1164 Specification", Work in Progress, Internet-Draft, draft- 1165 ietf-dtn-bpsec-27, 16 February 2021, 1166 . 1168 [I-D.ietf-dtn-tcpclv4] 1169 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1170 Tolerant Networking TCP Convergence Layer Protocol Version 1171 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1172 tcpclv4-26, 15 February 2021, 1173 . 1175 [I-D.ietf-cose-x509] 1176 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1177 Header parameters for carrying and referencing X.509 1178 certificates", Work in Progress, Internet-Draft, draft- 1179 ietf-cose-x509-08, 14 December 2020, 1180 . 1182 9.2. Informative References 1184 [NIST-SP800-57] 1185 National Institute of Standards and Technology, 1186 "Recommendation for Key Management - Part 1: General", 1187 NIST Special Publication 800-57 Revision 4, DOI 10.6028/ 1188 NIST.SP.800-57pt1r5, May 2020, 1189 . 1192 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1193 Text on Security Considerations", BCP 72, RFC 3552, 1194 DOI 10.17487/RFC3552, July 2003, 1195 . 1197 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1198 Code: The Implementation Status Section", BCP 205, 1199 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1200 . 1202 [I-D.ietf-dtn-bpbis] 1203 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 1204 Protocol Version 7", Work in Progress, Internet-Draft, 1205 draft-ietf-dtn-bpbis-31, 25 January 2021, 1206 . 1208 [I-D.ietf-dtn-bpsec-default-sc] 1209 III, E. J. B., White, A., and S. Heiner, "BPSec Default 1210 Security Contexts", Work in Progress, Internet-Draft, 1211 draft-ietf-dtn-bpsec-default-sc-05, 26 April 2021, 1212 . 1215 [github-dtn-bpsec-cose] 1216 Sipos, B., "DTN Bundle Protocol Security COSE Security 1217 Context", . 1219 [github-dtn-demo-agent] 1220 Sipos, B., "Demo Convergence Layer Agent", 1221 . 1223 Appendix A. Examples 1225 These examples are intended to have the correct structure of COSE 1226 security blocks but in some cases use simplified algorithm parameters 1227 or smaller key sizes than are required by the actual COSE profile 1228 defined in this documents. Each example indicates how it differs 1229 from the actual profile if there is a meaningful difference. 1231 All of these examples operate within the context of the bundle 1232 primary block of Figure 7 with a security target block of Figure 8. 1233 All example figures use the extended diagnostic notation [RFC8610]. 1235 [ 1236 7, / BP version / 1237 0, / flags / 1238 0, / CRC type / 1239 [1, "//dst/svc"], / destination / 1240 [1, "//src/"], / source / 1241 [1, "//src/"], / report-to / 1242 [0, 40], / timestamp / 1243 1000000 / lifetime / 1244 ] 1246 Figure 7: Primary block CBOR diagnostic 1248 [ 1249 1, / type code: payload / 1250 1, / block num / 1251 0, / flags / 1252 0, / CRC type / 1253 <<"hello">> / block-type-specific-data / 1254 ] 1256 Figure 8: Target block CBOR diagnostic 1258 All of the block integrity block examples operate within the context 1259 of the "frame" block of Figure 9, and block confidentiality block 1260 examples within the frame block of Figure 10. 1262 [ 1263 11, / type code: BIB / 1264 3, / block num / 1265 0, / flags / 1266 0, / CRC type / 1267 b'' / block-type-specific-data to be replaced / 1268 ] 1270 Figure 9: Block integrity block frame CBOR diagnostic 1272 [ 1273 12, / type code: BCB / 1274 3, / block num / 1275 0, / flags / 1276 0, / CRC type / 1277 b'' / block-type-specific-data to be replaced / 1278 ] 1280 Figure 10: Block confidentiality block frame CBOR diagnostic 1282 All of the examples also operate within a security block containing 1283 the AAD Scope parameter with only "has-primary-ctx" and "has-target- 1284 ctx" flags set. This results in a consistent AAD-structure as shown 1285 in Figure 11, which is encoded as the byte string for COSE 1286 external_aad in all of the examples. 1288 [ 1289 [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ], 1290 [ 0, 40 ], 1000000 ], / primary-ctx / 1291 [ 1, 1, 0 ], / target-ctx / 1292 null, / security-ctx / 1293 '' / additional-protected / 1294 ] 1296 Figure 11: Example scope AAD-structure CBOR diagnostic 1298 The only differences between these examples which use EC or RSA 1299 keypairs and a use of a PKIX public key certificate are: the 1300 parameters would have an x5chain parameter instead of a COSE_Key 1301 type, and the recipient would contain an "x5t" value instead of a 1302 "kid" value. Neither of these is a change to a protected header so, 1303 given the same private key, there would be no change to the signature 1304 or wrapped-key data. 1306 Because each of the encryption examples use the same CEK within the 1307 same AAD, the target ciphertext is also identical. The target block 1308 after application of the encryption is shown in Figure 12. 1310 [ 1311 1, / type code: payload / 1312 1, / block num / 1313 0, / flags / 1314 0, / CRC type / 1315 h'1fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f96b1' / ciphertext / 1316 ] 1318 Figure 12: Encrypted Target block CBOR diagnostic 1320 A.1. Symmetric Key COSE_Mac0 1322 This is an example of a MAC with recipient having a 256-bit symmetric 1323 key identified by a "kid". 1325 [ 1326 { 1327 / kty / 1: 4, / symmetric / 1328 / kid / 2: 'ExampleMAC', 1329 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1330 99dbae4ce45c' 1331 } 1332 ] 1334 Figure 13: Symmetric Key 1336 The external_aad is the encoded data from Figure 11. The payload is 1337 the encoded target block-type-specific data from Figure 8. 1339 [ 1340 "MAC0", / context / 1341 h'a10105', / protected / 1342 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1343 72632f820018281a000f424083010100f640', / external_aad / 1344 h'6568656c6c6f' / payload / 1345 ] 1347 Figure 14: MAC_structure CBOR diagnostic 1349 [1], / targets / 1350 0, / security context TBD-COSE / 1351 1, / flags: params-present / 1352 [1, "//src/"], / security source / 1353 [ / parameters / 1354 [ 1355 5, / AAD-scope / 1356 0x03 / has-primary-ctx | has-target-ctx / 1357 ] 1358 ], 1359 [ 1360 [ / target block #1 / 1361 [ / result / 1362 17, / COSE_Mac0 tag / 1363 <<[ 1364 <<{ / protected / 1365 / alg / 1:5 / HMAC 256//256 / 1366 }>>, 1367 { / unprotected / 1368 / kid / 4:'ExampleMAC' 1369 }, 1370 null, / payload detached / 1371 h'cea75ab637d2c4499ceca970ec1acc9f789f382b06571a0bdba9cd5a0a 1372 b48f0e' / tag / 1373 ]>> 1374 ] 1375 ] 1376 ] 1378 Figure 15: Abstract Security Block CBOR diagnostic 1380 The final bundle is encoded as the byte string: 1382 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1383 632f820018281a000f4240850b030000584c810100018201662f2f7372632f818205 1384 038181821158358443a10105a1044a4578616d706c654b6579f65820cea75ab637d2 1385 c4499ceca970ec1acc9f789f382b06571a0bdba9cd5a0ab48f0e8501010000466568 1386 656c6c6fff' 1388 A.2. EC Keypair COSE_Sign1 1390 This is an example of a signature with a recipient having a P-256 1391 curve EC keypair identified by a "kid". The associated public key is 1392 included as a security parameter. 1394 [ 1395 { / signing private key / 1396 / kty / 1: 2, / EC2 / 1397 / kid / 2: 'ExampleEC2', 1398 / crv / -1: 1, / P-256 / 1399 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 1400 e4fe0a1787a8', 1401 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1402 1639960a0c7a', 1403 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 1404 89786ea63842' 1405 } 1406 ] 1408 Figure 16: Example Keys 1410 The external_aad is the encoded data from Figure 11. The payload is 1411 the encoded target block-type-specific data from Figure 8. 1413 [ 1414 "Signature1", / context / 1415 h'a10126', / protected / 1416 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1417 72632f820018281a000f424083010100f640', / external_aad / 1418 h'6568656c6c6f' / payload / 1419 ] 1421 Figure 17: Sig_structure CBOR diagnostic 1423 [1], / targets / 1424 0, / security context TBD-COSE / 1425 1, / flags: params-present / 1426 [1, "//src/"], / security source / 1427 [ / parameters / 1428 [ 1429 5, / AAD-scope / 1430 0x03 / has-primary-ctx | has-target-ctx / 1431 ] 1432 ], 1433 [ 1434 [ / target block #1 / 1435 [ / result / 1436 18, / COSE_Sign1 tag / 1437 <<[ 1438 <<{ / protected / 1439 / alg / 1:-7 / ES256 / 1440 }>>, 1441 { / unprotected / 1442 / kid / 4:'ExampleEC2' 1443 }, 1444 null, / payload detached / 1445 h'b9e130d0b26d35d02299ca27601aab5c36efabefe1608da0c065368ce9 1446 a78e76e90a26c20caf294d2735861a16ff53b0173a801ceb6993da62c76863a8261a 1447 ee' / signature / 1448 ]>> 1449 ] 1450 ] 1451 ] 1453 Figure 18: Abstract Security Block CBOR diagnostic 1455 The final bundle is encoded as the byte string: 1457 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1458 632f820018281a000f4240850b030000586c810100018201662f2f7372632f818205 1459 038181821258558443a10126a1044a4578616d706c65454332f65840b9e130d0b26d 1460 35d02299ca27601aab5c36efabefe1608da0c065368ce9a78e76e90a26c20caf294d 1461 2735861a16ff53b0173a801ceb6993da62c76863a8261aee8501010000466568656c 1462 6c6fff' 1464 A.3. RSA Keypair COSE_Sign1 1466 This is an example of a signature with a recipient having a 1024-bit 1467 RSA keypair identified by a "kid". The associated public key is 1468 included as a security parameter. 1470 This key strength is not supposed to be a secure configuration, only 1471 intended to explain the procedure. This signature uses a random 1472 salt, so the full signature output is not deterministic. 1474 [ 1475 { / signing private key / 1476 / kty / 1: 3, / RSA / 1477 / kid / 2: 'ExampleRSA', 1478 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 1479 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 1480 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 1481 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 1482 25', 1483 / e / -2: h'010001', 1484 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1485 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde 1486 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 1487 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 1488 01', 1489 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 1490 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e 1491 c3d00e75', 1492 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 1493 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 1494 7effb9f1', 1495 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 1496 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 1497 7eea427e1', 1498 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 1499 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 1500 05ba3af91', 1501 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e 1502 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 1503 f4f92865ca3' 1504 } 1505 ] 1507 Figure 19: Example Keys 1509 The external_aad is the encoded data from Figure 11. The payload is 1510 the encoded target block-type-specific data from Figure 8. 1512 [ 1513 "Signature1", / context / 1514 h'a1013824', / protected / 1515 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1516 72632f820018281a000f424083010100f640', / external_aad / 1517 h'6568656c6c6f' / payload / 1518 ] 1520 Figure 20: Sig_structure CBOR diagnostic 1522 [1], / targets / 1523 0, / security context TBD-COSE / 1524 1, / flags: params-present / 1525 [1, "//src/"], / security source / 1526 [ / parameters / 1527 [ 1528 5, / AAD-scope / 1529 0x03 / has-primary-ctx | has-target-ctx / 1530 ] 1531 ], 1532 [ 1533 [ / target block #1 / 1534 [ / result / 1535 18, / COSE_Sign1 tag / 1536 <<[ 1537 <<{ / protected / 1538 / alg / 1:-37 / PS256 / 1539 }>>, 1540 { / unprotected / 1541 / kid / 4:'ExampleRSA' 1542 }, 1543 null, / payload detached / 1544 h'55dac638eb2b6e31386189e2e5afe0f2f6888c017013bf7ecbdb585c38 1545 2845dcb305ca1b43d727113c4616d4185bbbafcef83ca3cea8c583bddbddabc3c412 1546 590de368ccc695d887037f3afc97766edfddfaadd43c4d5a48725159d2fad2b9dee1 1547 30b0a4e990410d7d91a294747a9f53780f72987ed2a488d8b84e7590b418 1548 5a' / signature / 1549 ]>> 1550 ] 1551 ] 1552 ] 1554 Figure 21: Abstract Security Block CBOR diagnostic 1556 The final bundle is encoded as the byte string: 1558 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1559 632f820018281a000f4240850b03000058ad810100018201662f2f7372632f818205 1560 038181821258968444a1013824a1044a4578616d706c65525341f6588055dac638eb 1561 2b6e31386189e2e5afe0f2f6888c017013bf7ecbdb585c382845dcb305ca1b43d727 1562 113c4616d4185bbbafcef83ca3cea8c583bddbddabc3c412590de368ccc695d88703 1563 7f3afc97766edfddfaadd43c4d5a48725159d2fad2b9dee130b0a4e990410d7d91a2 1564 94747a9f53780f72987ed2a488d8b84e7590b4185a8501010000466568656c6c6fff' 1566 A.4. Symmetric KEK COSE_Encrypt 1568 This is an example of an encryption with a random CEK and an explicit 1569 key-encryption key (KEK) identified by a "kid". The keys used are 1570 shown in Figure 22. 1572 [ 1573 { 1574 / kty / 1: 4, / symmetric / 1575 / kid / 2: 'ExampleKEK', 1576 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf 1577 ae38ad7a972e' 1578 }, 1579 { 1580 / kty / 1: 4, / symmetric / 1581 / kid / 2: 'ExampleCEK', 1582 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1583 99dbae4ce45c' 1584 } 1585 ] 1587 Figure 22: Example Keys 1589 The external_aad is the encoded data from Figure 11. 1591 [ 1592 "Encrypt", / context / 1593 h'a10103', / protected / 1594 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1595 72632f820018281a000f424083010100f640' / external_aad / 1596 ] 1598 Figure 23: Enc_structure CBOR diagnostic 1600 The ASB item for this encryption operation is shown in Figure 24 and 1601 corresponds with the updated target block (containing the ciphertext) 1602 of Figure 12. 1604 [1], / targets / 1605 0, / security context TBD-COSE / 1606 1, / flags: params-present / 1607 [1, "//src/"], / security source / 1608 [ / parameters / 1609 [ 1610 5, / AAD-scope / 1611 0x03 / has-primary-ctx | has-target-ctx / 1612 ] 1613 ], 1614 [ 1615 [ / target block #1 / 1616 [ / result / 1617 96, / COSE_Encrypt tag / 1618 <<[ 1619 <<{ / protected / 1620 / alg / 1:3 / A256GCM / 1621 }>>, 1622 { / unprotected / 1623 / iv / 5: h'6f3093eba5d85143c3dc484a' 1624 }, 1625 null, / payload detached / 1626 [ 1627 [ / recipient / 1628 h'', / protected / 1629 { / unprotected / 1630 / alg / 1:-5, / A256KW / 1631 / kid / 4:'ExampleKEK' 1632 }, 1633 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d4 1634 03a6331159e3d691a708e9984d' / key-wrapped / 1635 ] 1636 ] 1637 ]>> 1638 ] 1639 ] 1640 ] 1642 Figure 24: Abstract Security Block CBOR diagnostic 1644 The final bundle is encoded as the byte string: 1646 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1647 632f820018281a000f4240850c0300005869810100018201662f2f7372632f818205 1648 03818182186058518443a10103a1054c6f3093eba5d85143c3dc484af6818340a201 1649 24044a4578616d706c654b454b5828917f2045e1169502756252bf119a94cdac6a9d 1650 8944245b5a9a26d403a6331159e3d691a708e9984d8501010000561fd25f64a2eea1 1651 2d4bb6c02d25bf33cec45f3e4f96b1ff' 1653 A.5. EC Keypair COSE_Encrypt 1655 This is an example of an encryption with an P-256 curve ephemeral 1656 sender keypair and a static recipient keypair identified by a "kid". 1657 The keys used are shown in Figure 25. 1659 [ 1660 { / sender ephemeral private key / 1661 / kty / 1: 2, / EC2 / 1662 / crv / -1: 1, / P-256 / 1663 / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788 1664 ca57d1df6bcc', 1665 / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c 1666 9c0670f28d62', 1667 / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088 1668 0f9d9c3b122a' 1669 }, 1670 { / recipient private key / 1671 / kty / 1: 2, / EC2 / 1672 / kid / 2: 'ExampleEC2', 1673 / crv / -1: 1, / P-256 / 1674 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 1675 e4fe0a1787a8', 1676 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1677 1639960a0c7a', 1678 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 1679 89786ea63842' 1680 }, 1681 { 1682 / kty / 1: 4, / symmetric / 1683 / kid / 2: 'ExampleCEK', 1684 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1685 99dbae4ce45c' 1686 } 1687 ] 1689 Figure 25: Example Keys 1691 The external_aad is the encoded data from Figure 11. 1693 [ 1694 "Encrypt", / context / 1695 h'a10103', / protected / 1696 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1697 72632f820018281a000f424083010100f640' / external_aad / 1698 ] 1700 Figure 26: Enc_structure CBOR diagnostic 1702 The ASB item for this encryption operation is shown in Figure 27 and 1703 corresponds with the updated target block (containing the ciphertext) 1704 of Figure 12. 1706 [1], / targets / 1707 0, / security context TBD-COSE / 1708 1, / flags: params-present / 1709 [1, "//src/"], / security source / 1710 [ / parameters / 1711 [ 1712 5, / AAD-scope / 1713 0x03 / has-primary-ctx | has-target-ctx / 1714 ] 1715 ], 1716 [ 1717 [ / target block #1 / 1718 [ / result / 1719 96, / COSE_Encrypt tag / 1720 <<[ 1721 <<{ / protected / 1722 / alg / 1:3 / A256GCM / 1723 }>>, 1724 { / unprotected / 1725 / iv / 5: h'6f3093eba5d85143c3dc484a' 1726 }, 1727 null, / payload detached / 1728 [ 1729 [ / recipient / 1730 h'', / protected / 1731 { / unprotected / 1732 / alg / 1:-31, / ECDH-ES + A256KW / 1733 / kid / 4:'ExampleEC2', 1734 / ephemeral key / -1:{ 1735 1:2, 1736 -1:1, 1737 -2:h'fedaba748882050d1bef8ba992911898f554450952070ae 1738 b4788ca57d1df6bcc', 1739 -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f4 1740 93c1c9c0670f28d62' 1741 } 1742 }, 1743 h'cb530b03f1e4b09ec1a0ca19afafbf280284106ab407aaf9bfed6e 1744 666c8f2f9ab5465cf11ef02756' / key-wrapped / 1745 ] 1746 ] 1747 ]>> 1748 ] 1749 ] 1750 ] 1752 Figure 27: Abstract Security Block CBOR diagnostic 1754 The final bundle is encoded as the byte string: 1756 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1757 632f820018281a000f4240850c03000058b6810100018201662f2f7372632f818205 1758 038181821860589e8443a10103a1054c6f3093eba5d85143c3dc484af6818340a301 1759 381e044a4578616d706c6545433220a401022001215820fedaba748882050d1bef8b 1760 a992911898f554450952070aeb4788ca57d1df6bcc225820ceaa8e7ff4751a4f81c7 1761 0e98f1713378b0bd82a1414a2f493c1c9c0670f28d625828cb530b03f1e4b09ec1a0 1762 ca19afafbf280284106ab407aaf9bfed6e666c8f2f9ab5465cf11ef0275685010100 1763 00561fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f96b1ff' 1765 A.6. RSA Keypair COSE_Encrypt 1767 This is an example of an encryption with a recipient having a 1768 1024-bit RSA keypair identified by a "kid". The associated public 1769 key is included as a security parameter. 1771 This key strength is not supposed to be a secure configuration, only 1772 intended to explain the procedure. This padding scheme uses a random 1773 salt, so the full layer-2 ciphertext output is not deterministic. 1775 [ 1776 { / recipient private key / 1777 / kty / 1: 3, / RSA / 1778 / kid / 2: 'ExampleRSA', 1779 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 1780 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 1781 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 1782 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 1783 25', 1784 / e / -2: h'010001', 1785 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1786 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde 1787 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 1788 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 1789 01', 1790 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 1791 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e 1792 c3d00e75', 1793 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 1794 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 1795 7effb9f1', 1796 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 1797 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 1798 7eea427e1', 1799 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 1800 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 1801 05ba3af91', 1802 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e 1803 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 1804 f4f92865ca3' 1805 }, 1806 { 1807 / kty / 1: 4, / symmetric / 1808 / kid / 2: 'ExampleCEK', 1809 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1810 99dbae4ce45c' 1811 } 1812 ] 1814 Figure 28: Example Keys 1816 The external_aad is the encoded data from Figure 11. 1818 [ 1819 "Encrypt", / context / 1820 h'a10103', / protected / 1821 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1822 72632f820018281a000f424083010100f640' / external_aad / 1823 ] 1825 Figure 29: Enc_structure CBOR diagnostic 1827 The ASB item for this encryption operation is shown in Figure 30 and 1828 corresponds with the updated target block (containing the ciphertext) 1829 of Figure 12. 1831 [1], / targets / 1832 0, / security context TBD-COSE / 1833 1, / flags: params-present / 1834 [1, "//src/"], / security source / 1835 [ / parameters / 1836 [ 1837 5, / AAD-scope / 1838 0x03 / has-primary-ctx | has-target-ctx / 1839 ] 1840 ], 1841 [ 1842 [ / target block #1 / 1843 [ / result / 1844 96, / COSE_Encrypt tag / 1845 <<[ 1846 <<{ / protected / 1847 / alg / 1:3 / A256GCM / 1848 }>>, 1849 { / unprotected / 1850 / iv / 5: h'6f3093eba5d85143c3dc484a' 1851 }, 1852 null, / payload detached / 1853 [ 1854 [ / recipient / 1855 h'', / protected / 1856 { / unprotected / 1857 / alg / 1:-41, / RSAES-OAEP w SHA-256 / 1858 / kid / 4:'ExampleRSA' 1859 }, 1860 h'89d4367b14e3c663bf0352f8fc4b206f197d78f3f05dda90b3a88c 1861 db2354bdd25eee0cab60f987b6f1441afea8301fc4be22607569a5571bef86900ff8 1862 00a1b52764557382220afa2d115ddbe06729f8c621c440b6341deae871426a9038d0 1863 281d348d6fdf7c130139f5d1bb84c07d93f6d1eed15af81305cc634088fc3f79 1864 32' / key-wrapped / 1865 ] 1866 ] 1867 ]>> 1868 ] 1869 ] 1870 ] 1872 Figure 30: Abstract Security Block CBOR diagnostic 1874 The final bundle is encoded as the byte string: 1876 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372 1877 632f820018281a000f4240850c03000058c2810100018201662f2f7372632f818205 1878 03818182186058aa8443a10103a1054c6f3093eba5d85143c3dc484af6818340a201 1879 3828044a4578616d706c65525341588089d4367b14e3c663bf0352f8fc4b206f197d 1880 78f3f05dda90b3a88cdb2354bdd25eee0cab60f987b6f1441afea8301fc4be226075 1881 69a5571bef86900ff800a1b52764557382220afa2d115ddbe06729f8c621c440b634 1882 1deae871426a9038d0281d348d6fdf7c130139f5d1bb84c07d93f6d1eed15af81305 1883 cc634088fc3f79328501010000561fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f 1884 96b1ff' 1886 Author's Address 1888 Brian Sipos 1889 RKF Engineering Solutions, LLC 1890 7500 Old Georgetown Road 1891 Suite 1275 1892 Bethesda, MD 20814-6198 1893 United States of America 1895 Email: BSipos@rkf-eng.com