idnits 2.17.1 draft-bsipos-dtn-bpsec-cose-05.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 (16 March 2021) is 1136 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 380 == Missing Reference: 'AAD-scope' is mentioned on line 380, but not defined -- Looks like a reference, but probably isn't: '0' on line 1238 -- Looks like a reference, but probably isn't: '40' on line 1238 -- Looks like a reference, but probably isn't: '2' on line 1761 -- 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 (-27) exists of draft-ietf-dtn-bpsec-26 == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-24 == 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-00 Summary: 2 errors (**), 0 flaws (~~), 7 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 16 March 2021 5 Expires: 17 September 2021 7 DTN Bundle Protocol Security COSE Security Context 8 draft-bsipos-dtn-bpsec-cose-05 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 17 September 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. 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 . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 29 97 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 31 98 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 32 99 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 34 100 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 36 101 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 39 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 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 | | 261 | | | document | (empty | 262 | | | | bstr) | 263 +-----------+------------------------+---------------+--------------+ 264 | 4 | additional-unprotected | Section 2.2.2 | {} | 265 | | | of this | | 266 | | | document | (empty | 267 | | | | map) | 268 +-----------+------------------------+---------------+--------------+ 269 | 5 | AAD_Scope | Section 2.2.3 | 0x7 | 270 | | | of this | | 271 | | | document | (all AAD | 272 | | | | contexts) | 273 +-----------+------------------------+---------------+--------------+ 275 Table 1: COSE Security Parameters 277 2.2.1. Key Containers 279 Implementations capable of handling asymmetric-keyed algorithms 280 SHOULD support the public key handling COSE_Key and COSE_KeySet 281 parameters. 283 No more than one total COSE_Key or COSE_KeySet parameter SHALL be 284 present in a single security block. Security acceptors are sill 285 required to aggregate multiple parameters, if present, in 286 Section 3.3. 288 Key container parameters SHALL NOT contain any private key material. 289 The security parameters are all stored in the bundle as plaintext and 290 are visible to any bundle handlers. 292 $bpsec-cose-param /= [1, COSE_Key] 293 $bpsec-cose-param /= [2, COSE_KeySet] 295 Figure 2: Key Containers CDDL 297 2.2.2. Additional Header Maps 299 The two parameters Additional Protected and Additional Unprotected 300 allow de-duplicating header items which are common to all COSE 301 results. Both additional header values contain a CBOR map which is 302 to be merged with each of the result's unprotected headers. Although 303 the additional header items are all treated as unprotected from the 304 perspective of the COSE message, the additional protected map is 305 included within the "external_aad" (see Section 2.5.1). The expected 306 use of additional header map is to contain a certificate (chain) or 307 identifier (see Section 3.3) which applies to all results in the same 308 security block. 310 Following the same pattern as COSE, when both additional header maps 311 are present in a single security block they SHALL not contain any 312 duplicated labels. Security acceptors SHALL treat a pair of 313 additional header maps containing duplicated labels as invalid. 315 No more than one of each Additional Protected and Additional 316 Unprotected parameter SHALL be present in a single security block. 317 Security acceptors SHALL treat a security block with multiple 318 instances of either additional header type as invalid. There is no 319 well-defined behavior for a security acceptor to handle multiple 320 Additional Protected parameters. 322 Security sources SHOULD NOT include an additional header parameter 323 which represents an empty map. Security acceptors SHALL handle empty 324 header map parameters, specifically the Additional Protected 325 parameter because it is part of the external_aad. 327 Security acceptors SHALL treat the aggregate of both additional 328 header maps as being present in the "unprotected" header map of the 329 COSE message of each result. If the same header label is present in 330 a additional header map and a result message the item in the result 331 message SHALL take precedence (i.e., the additional header items are 332 added only if they are not already present in a result message). 334 Additional header maps SHALL NOT contain any private key material. 335 The security parameters are all stored in the bundle as plaintext and 336 are visible to any bundle handlers. 338 $bpsec-cose-param /= [3, additional-protected] 339 additional-protected = empty_or_serialized_map 341 $bpsec-cose-param /= [4, additional-unprotected] 342 additional-unprotected = header_map 344 Figure 3: Additional Headers CDDL 346 2.2.3. AAD Scope 348 The AAD Scope parameter controls what data is included in the AAD for 349 both integrity and confidentiality operations. The AAD Scope 350 parameter SHALL be encoded as a uint value with bit flags defined in 351 Table 2. All reserved bits SHALL be set to zero (which will be 352 elided by CBOR encoding) by security sources. All reserved bits 353 SHALL be ignored by security acceptors. The default value for this 354 parameter has all flags set, meaning the AAD includes all available 355 context. 357 A CDDL representation of this definition is included in Figure 4 for 358 reference. 360 +==================+========+===============================+ 361 | Name | Code | Description | 362 +==================+========+===============================+ 363 | has-primary-ctx | 0x01 | If bit is set, indicates that | 364 | | | the primary block is included | 365 | | | in AAD scope. | 366 +------------------+--------+-------------------------------+ 367 | has-target-ctx | 0x02 | If bit is set, indicates that | 368 | | | the target block metadata is | 369 | | | included in AAD scope. | 370 +------------------+--------+-------------------------------+ 371 | has-security-ctx | 0x04 | If bit is set, indicates that | 372 | | | the security block metadata | 373 | | | is included in AAD scope. | 374 +------------------+--------+-------------------------------+ 375 | Reserved | others | | 376 +------------------+--------+-------------------------------+ 378 Table 2: AAD Scope Flags 380 $bpsec-cose-param /= [5, AAD-scope] 381 AAD-scope = uint .bits AAD-scope-flags 382 AAD-scope-flags = &( 383 has-primary-ctx: 0, 384 has-target-ctx: 1, 385 has-security-ctx: 2, 386 ) 388 Figure 4: AAD Scope CDDL 390 2.3. Results 392 Although each COSE context result is a COSE message, the types of 393 message allowed depend upon the security block type in which the 394 result is present: only MAC or signature messages are allowed in a 395 BIB and only encryption messages are allowed in a BCB. 397 The code points for Result ID values are identical to the existing 398 COSE message-marking tags in Section 2 of [RFC8152]. This avoids the 399 need for value-mapping between code points of the two registries. 401 When embedding COSE messages, the message CBOR structure SHALL be 402 encoded as a byte string used as the result value. This allows a 403 security acceptor to skip over unwanted results without needing to 404 decode the result structure. When embedding COSE messages, the CBOR- 405 tagged form SHALL NOT be used. The Result ID values already provide 406 the same information as the COSE tags (using the same code points). 408 These generic requirements are formalized in the CDDL fragment of 409 Figure 5. 411 $bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0] 412 $bpsec-cose-result /= [17, bstr .cbor COSE_Mac0] 413 $bpsec-cose-result /= [18, bstr .cbor COSE_Sign1] 414 $bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt] 415 $bpsec-cose-result /= [97, bstr .cbor COSE_Mac] 416 $bpsec-cose-result /= [98, bstr .cbor COSE_Sign] 418 Figure 5: COSE context results CDDL 420 2.3.1. Integrity Messages 422 When used within a Block Integrity Block, the COSE context SHALL 423 allow only the Result IDs from Table 3. Each integrity result value 424 SHALL consist of the COSE message indicated by Table 3 in its 425 untagged encoded form. 427 +===========+====================+===========+ 428 | Result ID | Result Structure | Reference | 429 +===========+====================+===========+ 430 | 97 | encoded COSE_Mac | [RFC8152] | 431 +-----------+--------------------+-----------+ 432 | 17 | encoded COSE_Mac0 | [RFC8152] | 433 +-----------+--------------------+-----------+ 434 | 98 | encoded COSE_Sign | [RFC8152] | 435 +-----------+--------------------+-----------+ 436 | 18 | encoded COSE_Sign1 | [RFC8152] | 437 +-----------+--------------------+-----------+ 439 Table 3: COSE Integrity Results 441 Each integrity result SHALL use the "detached" payload form with nil 442 payload value. The integrity result for COSE_Mac and COSE_Mac0 443 messages are computed by the procedure in Section 6.3 of [RFC8152]. 444 The integrity result for COSE_Sign and COSE_Sign1 messages are 445 computed by the procedure in Section 4.4 of [RFC8152]. 447 The COSE "protected attributes from the application" used for a 448 signature or MAC result SHALL be the encoded data defined in 449 Section 2.5.1. The COSE payload used for a signature or MAC result 450 SHALL be either the block-type-specific data of the target, if the 451 target is not the primary block, or an empty byte string if the 452 target is the primary block. 454 2.3.2. Confidentiality Messages 456 When used within a Block Confidentiality Block, COSE context SHALL 457 allow only the Result IDs from Table 4. Each confidentiality result 458 value SHALL consist of the COSE message indicated by Table 4 in its 459 untagged encoded form. 461 +===========+=======================+===========+ 462 | Result ID | Result Structure | Reference | 463 +===========+=======================+===========+ 464 | 96 | encoded COSE_Encrypt | [RFC8152] | 465 +-----------+-----------------------+-----------+ 466 | 16 | encoded COSE_Encrypt0 | [RFC8152] | 467 +-----------+-----------------------+-----------+ 469 Table 4: COSE Confidentiality Results 471 Only algorithms which support Authenticated Encryption with 472 Authenticated Data (AEAD) SHALL be usable in the first (content) 473 layer of a confidentiality result. Because COSE encryption with AEAD 474 appends the authentication tag with the ciphertext, the size of the 475 block-type-specific-data will grow after an encryption operation. 476 Security acceptors MUST NOT assume that the size of the plaintext is 477 the same as the size of the ciphertext. 479 Each confidentiality result SHALL use the "detached" payload form 480 with nil payload value. The confidentiality result for COSE_Encrypt 481 and COSE_Encrypt0 messages are computed by the procedure in 482 Section 5.3 of [RFC8152]. 484 The COSE "protected attributes from the application" used for an 485 encryption result SHALL be the encoded data defined in Section 2.5.1. 486 The COSE payload used for an encryption result SHALL be the block- 487 type-specific data of the target. Because confidentiality of the 488 primary block is disallowed by BPSec, there is no logic here for 489 handling a BCB with a target on the primary block. 491 2.4. Key Considerations 493 This specification does not impose any additional key requirements 494 beyond those already specified for each COSE algorithm required in 495 Section 3. 497 2.5. Canonicalization Algorithms 499 Generating or processing COSE messages for the COSE context follows 500 the profile defined in Section 3 with the "protected attributes from 501 the application" (i.e., the "external_aad" item) generated as defined 502 in Section 2.5.1. 504 2.5.1. Generating AAD 506 The AAD used for both integrity and confidentiality messages SHALL be 507 the deterministically encoded form of a CBOR array containing the 508 following: 510 1. The first item SHALL be either: the CBOR array (unencoded) form 511 of the primary block of the bundle if the AAD Scope has the has- 512 primary-ctx flag set, otherwise the null value. 514 2. The second item SHALL be either: a CBOR array containing the 515 first three fields of the target block (i.e., the block type 516 code, block number, and control flags) if the AAD Scope has the 517 has-target-ctx flag set, otherwise the null value. 519 3. The third item SHALL be either: a CBOR array containing the first 520 three fields of the security block containing the result (i.e., 521 the block type code, block number, and control flags) if the AAD 522 Scope has the has-security-ctx flag set, otherwise the null 523 value. 525 4. The fourth item SHALL be the Additional Protected header map, 526 which is a bstr value and has a default value of the empty bstr. 528 A CDDL representation of this data is shown below in Figure 6. 530 AAD-structure = [ 531 ; non-null if has-primary-ctx is set 532 primary-ctx: null / primary-block, 533 ; non-null if has-target-ctx is set 534 target-ctx: null / block-metadata, 535 ; non-null if has-security-ctx is set 536 security-ctx: null / block-metadata, 537 ; copy of additional-protected (or default) 538 additional-protected 539 ] 540 ; The first three fields of BP "canonical-block-structure" 541 block-metadata = [ 542 block-type-code: uint, 543 block-number: uint, 544 block-control-flags, 545 ] 547 Figure 6: COSE context AAD CDDL 549 2.5.2. Payload Data 551 When correlating between BPSec target block-type-specific-data and 552 COSE plaintext or payload, any byte string SHALL be handled in its 553 decoded (CBOR item) form. This means any CBOR header or tag in a 554 source encoding are ignored for the purposes of security processing. 555 This also means that if the source byte string was encoded in a non- 556 conforming way, for example in indefinite-length form or with a non- 557 minimum-size length, the security processing always treats it in a 558 deterministically encoded CBOR form. 560 2.6. Processing 562 This section describes block-level requirements for handling COSE 563 security data. 565 Security results generated for BIB or BCB results SHALL conform to 566 the COSE profile of Section 3. 568 2.6.1. Node Authentication 570 This section explains how the certificate profile of Section 4 is 571 used by a security acceptor to both validate an end-entity 572 certificate and to use that certificate to authenticate the security 573 source for an integrity result. For a confidentiality result, some 574 of the requirements in this section are implicit in an implementation 575 using a private key associated with a certificate used by a result 576 recipient. It is an implementation matter to ensure that a BP agent 577 is configured to generate or receive results associated with valid 578 certificates. 580 A security source MAY prohibit generating a result (either integrity 581 or confidentiality) for an end-entity certificate which is not 582 considered valid according to Section 2.6.1.2. Generating a result 583 which is likely to be discarded is wasteful of bundle size and 584 transport resources. 586 2.6.1.1. Certificate Identification 588 Because of the standard policy of using separate certificates for 589 transport, signing, and encryption (see Section 4.1) a single Node ID 590 is likely to be associated with multiple certificates, and any or all 591 of those certificates MAY be present within an "x5bag" in an 592 Additional Protected parameter (see Section 2.2.2). When present, a 593 security acceptor SHALL use an "x5chain" or "x5t" to identify an end- 594 entity certificate to use for result processing. Security acceptors 595 SHALL NOT assume that a validated certificate containing a NODE-ID 596 matching a security source is enough to associate a certificate with 597 a COSE message or recipient (see Section 3.3). 599 2.6.1.2. Certificate Validation 601 For each end-entity certificate contained in or identified by by a 602 COSE result, the security acceptor SHALL perform the certification 603 path validation of Section 6 of [RFC5280] up to one of the acceptor's 604 trusted CA certificates. When evaluating a certificate Validity 605 period, the security acceptor SHALL use the bundle Creation Timestamp 606 time (if not unknown) as the reference instead of the current time. 607 If enabled by local policy, the entity SHALL perform an OCSP check of 608 each certificate providing OCSP authority information in accordance 609 with [RFC6960]. If certificate validation fails or if security 610 policy disallows a certificate for any reason, the acceptor SHALL 611 treat the associated security result as failed. Leaving out part of 612 the certification chain can cause the entity to fail to validate a 613 certificate if the left-out certificates are unknown to the entity 614 (see Section 6.2). 616 For each end-entity certificate contained in or identified by a COSE 617 context result, the security acceptor SHALL apply security policy to 618 the Key Usage extension (if present) and Extended Key Usage extension 619 (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the 620 profile in Section 4. 622 2.6.1.3. Node ID Authentication 624 If required by security policy, for each end-entity certificate 625 referenced by a COSE context integrity result the security acceptor 626 SHALL validate the certificate NODE-ID in accordance with Section 6 627 of [RFC6125] using the NODE-ID reference identifier from the Security 628 Source of the containing security block. If the NODE-ID validation 629 result is Failure or if the result is Absent and security policy 630 requires an authenticated Node ID, the security acceptor SHALL treat 631 the result as failed. 633 2.6.2. Policy Recommendations 635 A RECOMMENDED security policy is to enable the use of OCSP checking 636 when internet connectivity is present. A RECOMMENDED security policy 637 is that if an Extended Key Usage is present that it needs to contain 638 "id-kp-bundleSecurity" to be usable as an end-entity certificate for 639 COSE security results. A RECOMMENDED security policy is to require a 640 validated Node ID (of Section 2.6.1.3) and to ignore any other 641 identifiers in the end-entity certificate. 643 This policy relies on and informs the certificate requirements in 644 Section 3.3.1 and Section 4. This policy assumes that a DTN-aware CA 645 (see Section 1.2) will only issue a certificate for a Node ID when it 646 has verified that the private key holder actually controls the DTN 647 node; this is needed to avoid the threat identified in Section 6.4. 648 This policy requires that a certificate contain a NODE-ID and allows 649 the certificate to also contain network-level identifiers. A 650 tailored policy on a more controlled network could relax the 651 requirement on Node ID validation and/or Extended Key Usage presence. 653 3. COSE Profile for BPSec 655 This section contains requirements which apply to the use of COSE 656 within BPSec across any security context use. 658 3.1. COSE Messages 660 When generating a BPSec result, security sources SHALL use encode 661 COSE labels with a uint value. When processing a BPSec result, 662 security acceptors MAY handle COSE labels with with a tstr value. 664 When used in a BPSec result, each COSE message SHALL contain an 665 explicit algorithm identifier in the lower (content) layers. When 666 available and not implied by the bundle source, a COSE message SHALL 667 contain a key identifier in the highest (recipient) layer. See 668 Section 3.3 for specifics about asymmetric key identifiers. When a 669 key identifier is not available, BPSec acceptors SHALL use the 670 Security Source (if available) and the Bundle Source to imply which 671 keys can be used for security operations. Using implied keys has an 672 interoperability risk, see Section 6.5 for details. A BPSec security 673 operation always occurs within the context of the immutable primary 674 block with its parameters (specifically the Source Node ID) and the 675 security block with its optional Security Source. 677 The algorithms required by this profile focuses on networks using 678 shared symmetric-keys, with recommended algorithms for Elliptic Curve 679 (EC) keypairs and RSA keypairs. The focus of this profile is to 680 enable interoperation between security sources and acceptors on an 681 open network, where more explicit COSE parameters make it easier for 682 BPSec acceptors to avoid assumptions and avoid out-of-band 683 parameters. The requirements of this profile still allow the use of 684 potentially not-easily-interoperable algorithms and message/recipient 685 configurations for use by private networks, where message size is 686 more important than explicit COSE parameters. 688 3.2. Interoperability Algorithms 690 The set of integrity algorithms needed for interoperability is listed 691 here. The full set of COSE algorithms available is managed at 692 [IANA-COSE]. 694 Implementations conforming to this specification SHALL support the 695 symmetric keyed and key-encryption algorithms of Table 5. 696 Implementations capable of doing so SHOULD support the asymmetric 697 keyed and key-encryption algorithms of Table 5. 699 | The layer-1 required list is identical to the 700 | [I-D.ietf-dtn-bpsec-default-sc] context list. 702 +=================+============+============+======+================+ 703 | BPSec Block | COSE | Name | Code | Implementation | 704 | | Layer | | | Requirements | 705 +=================+============+============+======+================+ 706 | Integrity | 1 | HMAC | 5 | Required | 707 | | | 256/256 | | | 708 +-----------------+------------+------------+------+----------------+ 709 | Integrity | 1 | ES256 | -7 | Recommended | 710 +-----------------+------------+------------+------+----------------+ 711 | Integrity | 1 | EdDSA | -8 | Recommended | 712 +-----------------+------------+------------+------+----------------+ 713 | Integrity | 1 | PS256 | -37 | Recommended | 714 +-----------------+------------+------------+------+----------------+ 715 | Confidentiality | 1 | A256GCM | 3 | Required | 716 +-----------------+------------+------------+------+----------------+ 717 | Confidentiality | 2 | A256KW | -5 | Required | 718 +-----------------+------------+------------+------+----------------+ 719 | Confidentiality | 2 | ECDH-ES + | -31 | Recommended | 720 | | | A256KW | | | 721 +-----------------+------------+------------+------+----------------+ 722 | Confidentiality | 2 | ECDH-SS + | -34 | Recommended | 723 | | | A256KW | | | 724 +-----------------+------------+------------+------+----------------+ 725 | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended | 726 | | | w/ SHA-256 | | | 727 +-----------------+------------+------------+------+----------------+ 729 Table 5: Interoperability Algorithms 731 The following are recommended key and recipient uses within COSE/ 732 BPSec: 734 Symmetric Key Integrity: When generating a BIB result from a 735 symmetric key, implementations SHALL use a COSE_Mac0 using the 736 private key directly. When a COSE_Mac0 is used with a direct key, 737 the headers SHALL include a key identifier ("kid" header). 739 EC Keypair Integrity: When generating a BIB result from an EC 740 keypair, implementations SHALL use a COSE_Sign1 using the private 741 key directly. When a COSE_Sign1 is used with an EC keypair, the 742 headers SHALL include a public key identifier (see Section 3.3). 744 RSA Keypair Integrity: When generating a BIB result from an RSA 745 keypair, implementations SHALL use a COSE_Sign1 using the private 746 key directly. When a COSE_Sign1 is used with an RSA keypair, the 747 headers SHALL include a public key identifier (see Section 3.3). 748 When a COSE signature is generated with an RSA keypair, the 749 signature uses a PSS salt in accordance with Section 2 of 750 [RFC8230]. 752 Symmetric Key Confidentiality: When generating a BCB result from an 753 symmetric key, implementations SHALL use a COSE_Encrypt message 754 with a recipient containing an indirect (wrapped or derived) 755 content encryption key (CEK). When generating a BCB result from a 756 symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or 757 COSE_Encrypt with direct CEK. Doing so risks key overuse and the 758 vulnerabilities associated with large amount of ciphertext from 759 the same key. When a COSE_Encrypt is used with an overall key- 760 encryption key (KEK), the recipient layer SHALL include a key 761 identifier for the KEK. 763 EC Keypair Confidentiality: When generating a BCB result from an EC 764 keypair, implementations SHALL use a COSE_Encrypt message with a 765 recipient containing an indirect (wrapped or derived) CEK. When a 766 COSE_Encrypt is used with an EC keypair, the recipient layer SHALL 767 include a public key identifier (see Section 3.3). When a 768 COSE_Encrypt is used with an EC keypair, the security source SHALL 769 either generate an ephemeral EC keypair or choose a unique PartyU 770 Nonce for each security operation. When processing a COSE_Encrypt 771 with an EC keypair, the security acceptor SHALL process all KDF 772 and HMAC context data from the recipient headers in accordance 773 with Section 11.2 of [RFC8152] even though the source is not 774 required to provide any of those parameters. 776 RSA Keypair Confidentiality: When generating a BCB result from an 777 RSA keypair, implementations SHALL use a COSE_Encrypt message with 778 a recipient containing a key-wrapped CEK. When a COSE_Encrypt is 779 used with an RSA keypair, the recipient layer SHALL include a 780 public key identifier (see Section 3.3). 782 3.3. Asymmetric Key Types and Identifiers 784 This section applies when a BIB uses a public key for verification, 785 or when a BCB uses a public key for encryption. When using 786 asymmetric keyed algorithms, the security source SHALL include a 787 public key identifier as a recipient header. The public key 788 identifier SHALL be either a "kid" of [RFC8152], an "x5t" or 789 "x5chain" of [I-D.ietf-cose-x509], or an equivalent identifier. 791 When a BIB result contains a "kid" identifier, the security source 792 MAY include an appropriate COSE public key "COSE_Key" in a key 793 container security parameter (see Section 2.2.1). When BIB result 794 contains a "x5t" identifier, the security source MAY include an 795 appropriate PKIX certificate container ("x5chain" or "x5bag" of 796 [I-D.ietf-cose-x509]) in a direct COSE header or an additional header 797 security parameter (see Section 2.2.2). When a BIB result contains 798 an "x5chain", the security source SHOULD NOT also include an "x5t" as 799 the first certificate in the chain is implicitly the applicable end- 800 entity certificate. For a BIB, if all potential security acceptors 801 are known to possess related public key and/or certificate data then 802 the public key or additional header parameters can be omitted. Risks 803 of not including related data are described in Section 6.5 and 804 Section 6.6. 806 When present, public keys and certificates SHOULD be included as 807 additional header parameters rather than within result COSE messages. 808 This provides size efficiency when multiple security results are 809 present because they will all be from the same security source and 810 likely share the same public key material. Security acceptors SHALL 811 still process public keys or certificates present in a result message 812 or recipient as applying to that individual COSE level. 814 Security acceptors SHALL aggregate all COSE_Key objects from all 815 parameters within a single BIB or BCB, independent of encoded type or 816 order of parameters. Because each context contains a single set of 817 security parameters which apply to all results in the same context, 818 security acceptors SHALL treat all public keys as being related to 819 the security source itself and potentially applying to every result. 821 3.3.1. Policy Recommendations 823 The RECOMMENDED priority policy for including PKIX material for BIB 824 results is as follows: 826 1. When receivers are not known to possess certificate chains, a 827 full chain is included (as an "x5chain"). 829 2. When receivers are known to possess root and intermediate CAs, 830 just the end-entity certificate is included (again as an 831 "x5chain"). 833 3. When receivers are known to possess associated chains including 834 end-entity certificates, a certificate thumbnail (as an "x5t"). 836 4. Some arbitrary identifier is used to correlate to an end-entity 837 certificate (as a "kid"). 839 5. The BIB Security Source is used to imply an associated end-entity 840 certificate which identifies that Node ID. 842 When PKIX certificates are used by security acceptors and the end- 843 entity certificate is not explicitly trusted (i.e. pinned), the 844 security acceptor SHALL perform the certification path validation of 845 Section 2.6.1.2 up to one or more trusted CA certificates. Leaving 846 out part of the certification chain can cause the security acceptor 847 to fail to validate a BIB if the left-out certificates are unknown to 848 the acceptor (see Section 6.6). 850 Any end-entity certificate associated with a BPSec security source 851 SHALL adhere to the profile of Section 4. 853 4. PKIX Certificate Profile 855 This section contains requirements on certificates used for the COSE 856 context, while Section 3.3 contains requirements for how such 857 certificates are transported or identified. 859 All end-entity certificates used for BPSec SHALL conform to 860 [RFC5280], or any updates or successors to that profile. 862 This profile requires Version 3 certificates due to the extensions 863 used by this profile. Security acceptors SHALL reject as invalid 864 Version 1 and Version 2 end-entity certificates. 866 Security acceptors SHALL accept certificates that contain an empty 867 Subject field or contain a Subject without a Common Name. Identity 868 information in end-entity certificates is contained entirely in the 869 subjectAltName extension as a NODE-ID, as defined in 870 [I-D.ietf-dtn-tcpclv4]. 872 All end-entity and CA certificates used for BPSec SHOULD contain both 873 a Subject Key Identifier extension in accordance with Section 4.2.1.2 874 of [RFC5280] and an Authority Key Identifier extension in accordance 875 with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT 876 rely on either a Subject Key Identifier and an Authority Key 877 Identifier being present in any received certificate. Including key 878 identifiers simplifies the work of an entity needing to assemble a 879 certification chain. 881 A BPSec end-entity certificate SHALL contain a NODE-ID which 882 authenticates the Node ID of the security source (for integrity) or 883 the security acceptor (for confidentiality). The identifier type 884 NODE-ID is defined in [I-D.ietf-dtn-tcpclv4]. 886 When allowed by CA policy, a BPSec end-entity certificate SHOULD 887 contain a PKIX Extended Key Usage extension in accordance with 888 Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage 889 extension is present, it SHALL contain a key purpose "id-kp- 890 bundleSecurity" of [IANA-SMI]. The "id-kp-bundleSecurity" purpose 891 MAY be combined with other purposes in the same certificate. 893 When allowed by CA policy, a BPSec end-entity certificate SHALL 894 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 895 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE 896 security are: digitalSignature, nonRepudiation, keyEncipherment, and 897 keyAgreement. The specific algorithms used by COSE messages in 898 security results determine which of those key uses are exercised. 899 See Section 4.1 for discussion of key use policies across multiple 900 certificates. 902 A BPSec end-entity certificate MAY contain an Online Certificate 903 Status Protocol (OCSP) URI within an Authority Information Access 904 extension in accordance with Section 4.2.2.1 of [RFC5280]. Security 905 acceptors are not expected to have continuous internet connectivity 906 sufficient to perform OCSP verification. 908 4.1. Multiple-Certificate Uses 910 A RECOMMENDED security policy is to limit asymmetric keys (and thus 911 public key certificates) to single uses among the following: 913 Bundle transport: With key uses as defined in the convergence layer 914 specification(s). 916 Block signing: With key use digitalSignature and/or nonRepudiation. 918 Block encryption: With key use keyEncipherment and/or keyAgreement. 920 This policy is the same one recommended by Section 6 of [RFC8551] for 921 email security and by Section 5.2 of [NIST-SP800-57] more generally. 922 Effectively this means that a BP node uses separate certificates for 923 transport (e.g., as a TCPCL entity), BIB signing (as a security 924 source), and BCB encryption (as a security acceptor). 926 5. Implementation Status 928 This section is to be removed before publishing as an RFC. 930 [NOTE to the RFC Editor: please remove this section before 931 publication, as well as the reference to [RFC7942] and 932 [github-dtn-bpsec-cose].] 933 This section records the status of known implementations of the 934 protocol defined by this specification at the time of posting of this 935 Internet-Draft, and is based on a proposal described in [RFC7942]. 936 The description of implementations in this section is intended to 937 assist the IETF in its decision processes in progressing drafts to 938 RFCs. Please note that the listing of any individual implementation 939 here does not imply endorsement by the IETF. Furthermore, no effort 940 has been spent to verify the information presented here that was 941 supplied by IETF contributors. This is not intended as, and must not 942 be construed to be, a catalog of available implementations or their 943 features. Readers are advised to note that other implementations can 944 exist. 946 An example implementation of COSE over Blocks has been created as a 947 GitHub project [github-dtn-bpsec-cose] and is intended to use as a 948 proof-of-concept and as a possible source of interoperability 949 testing. This example implementation only handles CBOR encoding/ 950 decoding and cryptographic functions, it does not construct actual 951 BIB or BCB and does not integrate with a BP Agent. 953 6. Security Considerations 955 This section separates security considerations into threat categories 956 based on guidance of BCP 72 [RFC3552]. 958 All of the security considerations of the underlying BPSec 959 [I-D.ietf-dtn-bpsec] apply to these new security contexts. 961 6.1. Threat: BPSec Block Replay 963 The bundle's primary block contains fields which uniquely identify a 964 bundle: the Source Node ID, Creation Timestamp, and fragment 965 parameters (see Section 4.3.1 of [I-D.ietf-dtn-bpbis]). These same 966 fields are used to correlate Administrative Records with the bundles 967 for which the records were generated. Including the primary block in 968 the AAD Scope for integrity and confidentiality (see Section 2.2.3) 969 binds the verification of the secured block to its parent bundle and 970 disallows replay of any block with its BIB or BCB. 972 This profile of COSE limits the encryption algorithms to only AEAD in 973 order to include the context of the encrypted data as AAD. If an 974 agent mistakenly allows the use of non-AEAD encryption when 975 decrypting and verifying a BCB, the possibility of block replay 976 attack is present. 978 6.2. Threat: Untrusted End-Entity Certificate 980 The profile in Section 2.6.1 uses end-entity certificates chained up 981 to a trusted root CA. A security source can include a certificate 982 set which does not contain the full chain, possibly excluding 983 intermediate or root CAs. In an environment where security acceptors 984 are known to already contain needed root and intermediate CAs there 985 is no need to include those CAs, but this has a risk of an acceptor 986 not actually having one of the needed CAs. 988 6.3. Threat: Certificate Validation Vulnerabilities 990 Even when a security acceptor is operating properly an attacker can 991 attempt to exploit vulnerabilities within certificate check 992 algorithms or configuration to authenticate using an invalid 993 certificate. An invalid certificate exploit could lead to higher- 994 level security issues and/or denial of service to the Node ID being 995 impersonated. 997 There are many reasons, described in [RFC5280] and [RFC6125], why a 998 certificate can fail to validate, including using the certificate 999 outside of its valid time interval, using purposes for which it was 1000 not authorized, or using it after it has been revoked by its CA. 1001 Validating a certificate is a complex task and can require network 1002 connectivity outside of the primary BP convergence layer network 1003 path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The 1004 configuration and use of particular certificate validation methods 1005 are outside of the scope of this document. 1007 6.4. Threat: BP Node Impersonation 1009 When certificates are referenced by BIB results it is possible that 1010 the certificate does not contain a NODE-ID or does contain one but 1011 has a mismatch with the actual security source (see Section 1.2). 1012 Having a CA-validated certificate does not alone guarantee the 1013 identity of the security source from which the certificate is 1014 provided; additional validation procedures in Section 2.6.1 bind the 1015 Node ID based on the contents of the certificate. 1017 6.5. Threat: Unidentifiable Key 1019 The profile in Section 3.2 recommends key identifiers when possible 1020 and the parameters in section Section 2.2 allow encoding public keys 1021 where available. If the application using a COSE Integrity or COSE 1022 Confidentiality context leaves out key identification data (in a COSE 1023 recipient structure), the security acceptor for those BPSec blocks 1024 only has the primary block available to use when verifying or 1025 decrypting the target block. This leads to a situation, identified 1026 in BPSec Security Considerations, where a signature is verified to be 1027 valid but not from the expected Security Source. 1029 Because the key identifier headers are unprotected (see Section 3.3), 1030 there is still the possibility that an active attacker removes or 1031 alters key identifier(s) in the result. This can cause the security 1032 acceptor to not be able to properly verify a valid signature or not 1033 use the correct private key to decrypt valid ciphertext. 1035 6.6. Threat: Non-Trusted Public Key 1037 The profile in Section 3.2 allows the use of PKIX which typically 1038 involves end-entity certificates chained up to a trusted root CA. 1039 This allows a BIB to contain end-entity certificates not previously 1040 known to a security acceptor but still trust the certificate by 1041 verifying it up to a trusted CA. In an environment where security 1042 acceptors are known to already contain needed root and intermediate 1043 CAs there is no need to include those CAs in a proper chain within 1044 the security parameters, but this has a risk of an acceptor not 1045 actually having one of the needed CAs. 1047 Because the security parameters are not included as AAD, there is 1048 still the possibility that an active attacker removes or alters 1049 certification chain data in the parameters. This can cause the 1050 security acceptor to be able to verify a valid signature but not 1051 trust the public key used to perform the verification. 1053 6.7. Threat: Passive Leak of Key Material 1055 It is important that the key requirements of Section 2.2 apply only 1056 to public keys and PKIX certificates. Including non-public key 1057 material in ASB parameters will expose that material in the bundle 1058 data and over the bundle convergence layer during transport. 1060 6.8. Threat: Algorithm Vulnerabilities 1062 Because this use of COSE leaves the specific algorithms chosen for 1063 BIB and BCB use up to the applications securing bundle data, it is 1064 important to use only COSE algorithms which are marked as recommended 1065 in the IANA registry [IANA-COSE]. 1067 7. IANA Considerations 1069 Registration procedures referred to in this section are defined in 1070 [RFC8126]. 1072 7.1. BPSec Security Contexts 1074 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following 1075 entry has been added to the "BPSec Security Context Identifiers" sub- 1076 registry. 1078 +==========+=============+=====================+ 1079 | Value | Description | Reference | 1080 +==========+=============+=====================+ 1081 | TBD-COSE | COSE | This specification. | 1082 +----------+-------------+---------------------+ 1084 Table 6 1086 8. Acknowledgments 1088 The interoperability minimum algorithms and parameters are based on 1089 the draft [I-D.ietf-dtn-bpsec-default-sc]. 1091 9. References 1093 9.1. Normative References 1095 [IANA-BUNDLE] 1096 IANA, "Bundle Protocol", 1097 . 1099 [IANA-COSE] 1100 IANA, "CBOR Object Signing and Encryption (COSE)", 1101 . 1103 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 1104 . 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1112 Housley, R., and W. Polk, "Internet X.509 Public Key 1113 Infrastructure Certificate and Certificate Revocation List 1114 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1115 . 1117 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1118 Verification of Domain-Based Application Service Identity 1119 within Internet Public Key Infrastructure Using X.509 1120 (PKIX) Certificates in the Context of Transport Layer 1121 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1122 2011, . 1124 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1125 Galperin, S., and C. Adams, "X.509 Internet Public Key 1126 Infrastructure Online Certificate Status Protocol - OCSP", 1127 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1128 . 1130 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1131 Writing an IANA Considerations Section in RFCs", BCP 26, 1132 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1133 . 1135 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1136 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1137 . 1139 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1140 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1141 May 2017, . 1143 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 1144 and Encryption (COSE) Messages", RFC 8230, 1145 DOI 10.17487/RFC8230, September 2017, 1146 . 1148 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1149 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1150 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1151 April 2019, . 1153 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1154 Definition Language (CDDL): A Notational Convention to 1155 Express Concise Binary Object Representation (CBOR) and 1156 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1157 June 2019, . 1159 [I-D.ietf-dtn-bpsec] 1160 Birrane, E. and K. McKeever, "Bundle Protocol Security 1161 Specification", Work in Progress, Internet-Draft, draft- 1162 ietf-dtn-bpsec-26, 8 January 2021, 1163 . 1165 [I-D.ietf-dtn-tcpclv4] 1166 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1167 Tolerant Networking TCP Convergence Layer Protocol Version 1168 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1169 tcpclv4-24, 7 December 2020, 1170 . 1172 [I-D.ietf-cose-x509] 1173 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1174 Header parameters for carrying and referencing X.509 1175 certificates", Work in Progress, Internet-Draft, draft- 1176 ietf-cose-x509-08, 14 December 2020, 1177 . 1179 9.2. Informative References 1181 [NIST-SP800-57] 1182 National Institute of Standards and Technology, 1183 "Recommendation for Key Management - Part 1: General", 1184 NIST Special Publication 800-57 Revision 4, DOI 10.6028/ 1185 NIST.SP.800-57pt1r5, May 2020, 1186 . 1189 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1190 Text on Security Considerations", BCP 72, RFC 3552, 1191 DOI 10.17487/RFC3552, July 2003, 1192 . 1194 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1195 Code: The Implementation Status Section", BCP 205, 1196 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1197 . 1199 [I-D.ietf-dtn-bpbis] 1200 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1201 Version 7", Work in Progress, Internet-Draft, draft-ietf- 1202 dtn-bpbis-31, 25 January 2021, 1203 . 1205 [I-D.ietf-dtn-bpsec-default-sc] 1206 Birrane, E., "BPSec Default Security Contexts", Work in 1207 Progress, Internet-Draft, draft-ietf-dtn-bpsec-default-sc- 1208 00, 26 January 2021, . 1211 [github-dtn-bpsec-cose] 1212 Sipos, B., "DTN Bundle Protocol Security COSE Security 1213 Context", . 1215 [github-dtn-demo-agent] 1216 Sipos, B., "Demo Convergence Layer Agent", 1217 . 1219 Appendix A. Examples 1221 These examples are intended to have the correct structure of COSE 1222 security blocks but in some cases use simplified algorithm parameters 1223 or smaller key sizes than are required by the actual COSE profile 1224 defined in this documents. Each example indicates how it differs 1225 from the actual profile if there is a meaningful difference. 1227 All of these examples operate within the context of the bundle 1228 primary block of Figure 7 with a security target block of Figure 8. 1229 All example figures use the extended diagnostic notation [RFC8610]. 1231 [ 1232 7, / BP version / 1233 0, / flags / 1234 0, / CRC type / 1235 [1, "//dst/svc"], / destination / 1236 [1, "//src/"], / source / 1237 [1, "//src/"], / report-to / 1238 [0, 40], / timestamp / 1239 1000000 / lifetime / 1240 ] 1242 Figure 7: Primary block CBOR diagnostic 1244 [ 1245 7, / type code - bundle age / 1246 2, / block num / 1247 0, / flags / 1248 0, / CRC type / 1249 <<300>> / type-specific-data: age / 1250 ] 1252 Figure 8: Target block CBOR diagnostic 1254 All of the examples also operate within a security block containing 1255 the AAD Scope parameter with only "has-primary-ctx" and "has-target- 1256 ctx" flags set. This results in a consistent AAD-structure as shown 1257 in Figure 9, which is encoded as the byte string for COSE 1258 external_aad in all of the examples. 1260 [ 1261 [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ], 1262 [ 0, 40 ], 1000000 ], / primary-ctx / 1263 [ 7, 2, 0 ], / target-ctx / 1264 null, / security-ctx / 1265 '' / additional-protected / 1266 ] 1268 Figure 9: Example scope AAD-structure CBOR diagnostic 1270 The only differences between these examples which use EC or RSA 1271 keypairs and a use of a PKIX public key certificate are: the 1272 parameters would have an x5chain parameter instead of a COSE_Key 1273 type, and the recipient would contain an "x5t" value instead of a 1274 "kid" value. Neither of these is a change to a protected header so, 1275 given the same private key, there would be no change to the signature 1276 or wrapped-key data. 1278 Because each of the encryption examples use the same CEK within the 1279 same AAD, the target ciphertext is also identical. The target block 1280 after application of the encryption is shown in Figure 10. 1282 [ 1283 7, / type code - bundle age / 1284 2, / block num / 1285 0, / flags / 1286 0, / CRC type / 1287 h'63bb166949afd31b50841ee05153b9cfaf788d' / ciphertext / 1288 ] 1290 Figure 10: Encrypted Target block CBOR diagnostic 1292 A.1. Symmetric Key COSE_Mac0 1294 This is an example of a MAC with recipient having a 256-bit symmetric 1295 key identified by a "kid". 1297 [ 1298 { 1299 / kty / 1: 4, / symmetric / 1300 / kid / 2: 'ExampleMAC', 1301 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1302 99dbae4ce45c' 1303 } 1304 ] 1306 Figure 11: Symmetric Key 1308 The external_aad is the encoded data from Figure 9. The payload is 1309 the encoded target block-type-specific data from Figure 8. 1311 [ 1312 "MAC0", / context / 1313 h'a10105', / protected / 1314 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1315 72632f820018281a000f424083070200f640', / external_aad / 1316 h'19012c' / payload / 1317 ] 1319 Figure 12: MAC_structure CBOR diagnostic 1321 [ 1322 [2], / targets / 1323 0, / security context TBD-COSE / 1324 1, / flags: params-present / 1325 [ / parameters / 1326 [ 1327 5, / AAD-scope / 1328 0x03 / has-primary-ctx | has-target-ctx / 1329 ] 1330 ], 1331 [ 1332 [ / target block #2 / 1333 [ / result / 1334 17, / COSE_Mac0 tag / 1335 <<[ 1336 <<{ / protected / 1337 / alg / 1:5 / HMAC 256//256 / 1338 }>>, 1339 { / unprotected / 1340 / kid / 4:'ExampleMAC' 1341 }, 1342 null, / payload detached / 1343 h'fa8b08724db1f0f4097156b12e65a1e7d57cfcdd413ced62d9e20f2b 1344 a4efcea5' / tag / 1345 ]>> 1346 ] 1347 ] 1348 ] 1349 ] 1351 Figure 13: Abstract Security Block CBOR diagnostic 1353 A.2. EC Keypair COSE_Sign1 1355 This is an example of a signature with a recipient having a P-256 1356 curve EC keypair identified by a "kid". The associated public key is 1357 included as a security parameter. 1359 [ 1360 { / signing private key / 1361 / kty / 1: 2, / EC2 / 1362 / kid / 2: 'ExampleEC2', 1363 / crv / -1: 1, / P-256 / 1364 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 1365 e4fe0a1787a8', 1366 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1367 1639960a0c7a', 1368 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 1369 89786ea63842' 1370 } 1371 ] 1373 Figure 14: Example Keys 1375 The external_aad is the encoded data from Figure 9. The payload is 1376 the encoded target block-type-specific data from Figure 8. 1378 [ 1379 "Signature1", / context / 1380 h'a10126', / protected / 1381 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1382 72632f820018281a000f424083070200f640', / external_aad / 1383 h'19012c' / payload / 1384 ] 1386 Figure 15: Sig_structure CBOR diagnostic 1388 [ 1389 [2], / targets / 1390 0, / security context TBD-COSE / 1391 1, / flags: params-present / 1392 [ / parameters / 1393 [ 1394 5, / AAD-scope / 1395 0x03 / has-primary-ctx | has-target-ctx / 1396 ] 1397 ], 1398 [ 1399 [ / target block #2 / 1400 [ / result / 1401 18, / COSE_Sign1 tag / 1402 <<[ 1403 <<{ / protected / 1404 / alg / 1:-7 / ES256 / 1405 }>>, 1406 { / unprotected / 1407 / kid / 4:'ExampleEC2' 1408 }, 1409 null, / payload detached / 1410 h'66358aa1ee41276688e417d7686db3914f3a6d061a31145912fc18ac 1411 68c1b980e9bbae2d18887677f9f8fb1d0a6133e62d89a2616826fd1109620122cde6 1412 eb5c' / signature / 1413 ]>> 1414 ] 1415 ] 1416 ] 1417 ] 1419 Figure 16: Abstract Security Block CBOR diagnostic 1421 A.3. RSA Keypair COSE_Sign1 1423 This is an example of a signature with a recipient having a 1024-bit 1424 RSA keypair identified by a "kid". The associated public key is 1425 included as a security parameter. 1427 This key strength is not supposed to be a secure configuration, only 1428 intended to explain the procedure. This signature uses a random 1429 salt, so the full signature output is not deterministic. 1431 [ 1432 { / signing private key / 1433 / kty / 1: 3, / RSA / 1434 / kid / 2: 'ExampleRSA', 1435 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 1436 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 1437 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 1438 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 1439 25', 1440 / e / -2: h'010001', 1441 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1442 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde 1443 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 1444 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 1445 01', 1446 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 1447 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e 1448 c3d00e75', 1449 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 1450 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 1451 7effb9f1', 1452 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 1453 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 1454 7eea427e1', 1455 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 1456 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 1457 05ba3af91', 1458 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e 1459 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 1460 f4f92865ca3' 1461 } 1462 ] 1464 Figure 17: Example Keys 1466 The external_aad is the encoded data from Figure 9. The payload is 1467 the encoded target block-type-specific data from Figure 8. 1469 [ 1470 "Signature1", / context / 1471 h'a1013824', / protected / 1472 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1473 72632f820018281a000f424083070200f640', / external_aad / 1474 h'19012c' / payload / 1475 ] 1477 Figure 18: Sig_structure CBOR diagnostic 1479 [ 1480 [2], / targets / 1481 0, / security context TBD-COSE / 1482 1, / flags: params-present / 1483 [ / parameters / 1484 [ 1485 5, / AAD-scope / 1486 0x03 / has-primary-ctx | has-target-ctx / 1487 ] 1488 ], 1489 [ 1490 [ / target block #2 / 1491 [ / result / 1492 18, / COSE_Sign1 tag / 1493 <<[ 1494 <<{ / protected / 1495 / alg / 1:-37 / PS256 / 1496 }>>, 1497 { / unprotected / 1498 / kid / 4:'ExampleRSA' 1499 }, 1500 null, / payload detached / 1501 h'8e469941a292d3554c81d1a69330b88563b28b415cf777c694d83272 1502 550d232b57ed4046d03849c2ade086145339872f7712e36ab4c382c1c541185fb15c 1503 036f00fd2842dff3e9d4f4068716d853f7bfe13791521e28faf42db085ab259a009a 1504 dceeb2acb7852bec6ec5069fc0d237883da8656aa6773682c3e01bd9732028 1505 c6' / signature / 1506 ]>> 1507 ] 1508 ] 1509 ] 1510 ] 1512 Figure 19: Abstract Security Block CBOR diagnostic 1514 A.4. Symmetric KEK COSE_Encrypt 1516 This is an example of an encryption with a random CEK and an explicit 1517 key-encryption key (KEK) identified by a "kid". The keys used are 1518 shown in Figure 20. 1520 [ 1521 { 1522 / kty / 1: 4, / symmetric / 1523 / kid / 2: 'ExampleKEK', 1524 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf 1525 ae38ad7a972e' 1526 }, 1527 { 1528 / kty / 1: 4, / symmetric / 1529 / kid / 2: 'ExampleCEK', 1530 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1531 99dbae4ce45c' 1532 } 1533 ] 1535 Figure 20: Example Keys 1537 The external_aad is the encoded data from Figure 9. 1539 [ 1540 "Encrypt", / context / 1541 h'a10103', / protected / 1542 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1543 72632f820018281a000f424083070200f640' / external_aad / 1544 ] 1546 Figure 21: Enc_structure CBOR diagnostic 1548 The ASB item for this encryption operation is shown in Figure 22 and 1549 corresponds with the updated target block (containing the ciphertext) 1550 of Figure 10. 1552 [ 1553 [2], / targets / 1554 0, / security context TBD-COSE / 1555 1, / flags: params-present / 1556 [ / parameters / 1557 [ 1558 5, / AAD-scope / 1559 0x03 / has-primary-ctx | has-target-ctx / 1560 ] 1561 ], 1562 [ 1563 [ / target block #2 / 1564 [ / result / 1565 96, / COSE_Encrypt tag / 1566 <<[ 1567 <<{ / protected / 1568 / alg / 1:3 / A256GCM / 1569 }>>, 1570 { / unprotected / 1571 / iv / 5: h'6f3093eba5d85143c3dc484a' 1572 }, 1573 null, / payload detached / 1574 [ 1575 [ / recipient / 1576 h'', / protected / 1577 { / unprotected / 1578 / alg / 1:-5, / A256KW / 1579 / kid / 4:'ExampleKEK' 1580 }, 1581 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26 1582 d403a6331159e3d691a708e9984d' / key-wrapped / 1583 ] 1584 ] 1585 ]>> 1586 ] 1587 ] 1588 ] 1589 ] 1591 Figure 22: Abstract Security Block CBOR diagnostic 1593 A.5. EC Keypair COSE_Encrypt 1595 This is an example of an encryption with an P-256 curve ephemeral 1596 sender keypair and a static recipient keypair identified by a "kid". 1597 The keys used are shown in Figure 23. 1599 [ 1600 { / sender ephemeral private key / 1601 / kty / 1: 2, / EC2 / 1602 / crv / -1: 1, / P-256 / 1603 / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788 1604 ca57d1df6bcc', 1605 / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c 1606 9c0670f28d62', 1607 / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088 1608 0f9d9c3b122a' 1609 }, 1610 { / recipient private key / 1611 / kty / 1: 2, / EC2 / 1612 / kid / 2: 'ExampleEC2', 1613 / crv / -1: 1, / P-256 / 1614 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 1615 e4fe0a1787a8', 1616 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1617 1639960a0c7a', 1618 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 1619 89786ea63842' 1620 }, 1621 { 1622 / kty / 1: 4, / symmetric / 1623 / kid / 2: 'ExampleCEK', 1624 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1625 99dbae4ce45c' 1626 } 1627 ] 1629 Figure 23: Example Keys 1631 The external_aad is the encoded data from Figure 9. 1633 [ 1634 "Encrypt", / context / 1635 h'a10103', / protected / 1636 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1637 72632f820018281a000f424083070200f640' / external_aad / 1638 ] 1640 Figure 24: Enc_structure CBOR diagnostic 1642 The ASB item for this encryption operation is shown in Figure 25 and 1643 corresponds with the updated target block (containing the ciphertext) 1644 of Figure 10. 1646 [ 1647 [2], / targets / 1648 0, / security context TBD-COSE / 1649 1, / flags: params-present / 1650 [ / parameters / 1651 [ 1652 5, / AAD-scope / 1653 0x03 / has-primary-ctx | has-target-ctx / 1654 ] 1655 ], 1656 [ 1657 [ / target block #2 / 1658 [ / result / 1659 96, / COSE_Encrypt tag / 1660 <<[ 1661 <<{ / protected / 1662 / alg / 1:3 / A256GCM / 1663 }>>, 1664 { / unprotected / 1665 / iv / 5: h'6f3093eba5d85143c3dc484a' 1666 }, 1667 null, / payload detached / 1668 [ 1669 [ / recipient / 1670 h'', / protected / 1671 { / unprotected / 1672 / alg / 1:-31, / ECDH-ES + A256KW / 1673 / kid / 4:'ExampleEC2', 1674 / ephemeral key / -1:{ 1675 1:2, 1676 -1:1, 1677 -2:h'fedaba748882050d1bef8ba992911898f554450952070 1678 aeb4788ca57d1df6bcc', 1679 -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2 1680 f493c1c9c0670f28d62' 1681 } 1682 }, 1683 h'cb530b03f1e4b09ec1a0ca19afafbf280284106ab407aaf9bfed 1684 6e666c8f2f9ab5465cf11ef02756' / key-wrapped / 1685 ] 1686 ] 1687 ]>> 1688 ] 1689 ] 1690 ] 1691 ] 1693 Figure 25: Abstract Security Block CBOR diagnostic 1695 A.6. RSA Keypair COSE_Encrypt 1697 This is an example of an encryption with a recipient having a 1698 1024-bit RSA keypair identified by a "kid". The associated public 1699 key is included as a security parameter. 1701 This key strength is not supposed to be a secure configuration, only 1702 intended to explain the procedure. This padding scheme uses a random 1703 salt, so the full layer-2 ciphertext output is not deterministic. 1705 [ 1706 { / recipient private key / 1707 / kty / 1: 3, / RSA / 1708 / kid / 2: 'ExampleRSA', 1709 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 1710 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 1711 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 1712 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 1713 25', 1714 / e / -2: h'010001', 1715 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1716 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde 1717 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 1718 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 1719 01', 1720 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 1721 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e 1722 c3d00e75', 1723 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 1724 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 1725 7effb9f1', 1726 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 1727 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 1728 7eea427e1', 1729 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 1730 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 1731 05ba3af91', 1732 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e 1733 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 1734 f4f92865ca3' 1735 }, 1736 { 1737 / kty / 1: 4, / symmetric / 1738 / kid / 2: 'ExampleCEK', 1739 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 1740 99dbae4ce45c' 1741 } 1742 ] 1743 Figure 26: Example Keys 1745 The external_aad is the encoded data from Figure 9. 1747 [ 1748 "Encrypt", / context / 1749 h'a10103', / protected / 1750 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 1751 72632f820018281a000f424083070200f640' / external_aad / 1752 ] 1754 Figure 27: Enc_structure CBOR diagnostic 1756 The ASB item for this encryption operation is shown in Figure 28 and 1757 corresponds with the updated target block (containing the ciphertext) 1758 of Figure 10. 1760 [ 1761 [2], / targets / 1762 0, / security context TBD-COSE / 1763 1, / flags: params-present / 1764 [ / parameters / 1765 [ 1766 5, / AAD-scope / 1767 0x03 / has-primary-ctx | has-target-ctx / 1768 ] 1769 ], 1770 [ 1771 [ / target block #2 / 1772 [ / result / 1773 96, / COSE_Encrypt tag / 1774 <<[ 1775 <<{ / protected / 1776 / alg / 1:3 / A256GCM / 1777 }>>, 1778 { / unprotected / 1779 / iv / 5: h'6f3093eba5d85143c3dc484a' 1780 }, 1781 null, / payload detached / 1782 [ 1783 [ / recipient / 1784 h'', / protected / 1785 { / unprotected / 1786 / alg / 1:-41, / RSAES-OAEP w SHA-256 / 1787 / kid / 4:'ExampleRSA' 1788 }, 1789 h'66e76f3e924674c02c98ddef1cfee0d79718549849d1bb008993 1790 28d4b66c8ac481de1ddd258f20514cfe040ead00afeb0709ef22e67607ef5ab62562 1791 4753cb247152b54240e51e96b5d7fdd37cf97af23e2292d6c6a0d2a8ab25a82b8a6c 1792 af1d4fa2f1bd7f1fd17d89506e75a1e2687374aa2a1cf21ce387916039d84ecc14 1793 03' / key-wrapped / 1794 ] 1795 ] 1796 ]>> 1797 ] 1798 ] 1799 ] 1800 ] 1802 Figure 28: Abstract Security Block CBOR diagnostic 1804 Author's Address 1805 Brian Sipos 1806 RKF Engineering Solutions, LLC 1807 7500 Old Georgetown Road 1808 Suite 1275 1809 Bethesda, MD 20814-6198 1810 United States of America 1812 Email: BSipos@rkf-eng.com