Bundle Protocol Security (BPSec) COSE Context

1.2. PKIX Environments and CA Policy

This specification gives requirements about how to use PKIX certificates issued by a Certificate Authority (CA), but does not define any mechanisms for how those certificates come to be.¶

To support the PKIX uses defined in this document, the CA(s) issuing certificates for BP nodes are aware of the end use of the certificate, have a mechanism for verifying ownership of a Node ID, and are issuing certificates directly for that Node ID. BPSec security verifiers and acceptors authenticate the Node ID of security sources when verifying integrity (see Section 2.6.1) using a public key provided by a PKIX certificate (see Section 2.6.1) following the certificate profile of Section 4.¶

2.1. Security Scope

The scope here refers to the set of information used by the security context to cryptographically bind with the plaintext data being integrity-protected or confidentiality-protected. This information is generically referred to as additional authenticated data (AAD), which is also the term used by COSE to describe the same kind of data. COSE distinguishes between its internal portion of AAD, derived from COSE message content, and external AAD provided by the embedding application, which in this case is the BPSec security context.¶

The sources for external AAD within this COSE context are described below, controlled by the AAD Scope parameter (Section 2.2.2), and implemented as defined in Section 2.5.1. The purpose of this parameter is similar to the "AAD Scope" parameter and "Integrity Scope" parameter of the Default Security Contexts [RFC9173] but expanded to allow including any block in the bundle as AAD.¶

Primary Block:

The primary block identifies a bundle and, once created, the contents of this block are immutable. Changes to the primary block associated with the security target indicate that the target is no longer in its original bundle. Including the primary block as part of AAD ensures that security target block-type-specific data (BTSD) appears in the same bundle that the security source intended.¶

Other Canonical Block BTSD:

Including the BTSD of an other, non-target block as part of AAD ensures that that other block's BTSD does not change after the security operation is added. This can guarantee that not only has the security target BTSD not changed but the additional blocks' BTSD have not changed.¶

Other Canonical Block Metadata:

Including block metadata, which identifies and types a block, as part of AAD ensures that the block presence does not change after the security operation is added. This metadata explicitly excludes the CRC type and value fields because the CRC is derived from the BTSD. The metadata of the security block and the target block are also allowed (as described below), which binds the security result to that specific target block.¶

Target Block Metadata:

One special case of including block metadata as AAD is for the target block itself, which ensures that the target BTSD is bound to its specific containing block. This case uses AAD Scope key -1 and the value flag for metadata to indicate that the block metadata is taken from the target of the security operation.¶

Containing Security Block Metadata:

Another special case of including block metadata is for the security block containing the security operation itself, which ensures that the security operation is bound to its specific containing block. This case uses AAD scope key -2 and the value flag for metadata to indicate that the block metadata is taken from the containing security block.¶

Containing Security Block BTSD:

The BTSD content of the security block itself (as defined in Section 3.6 of [RFC9172]) is also partially covered by AAD as explained below.¶

• The Security Targets field can be included indirectly by using AAD scope key -1 to ensure the AAD includes each target block number.¶
• The Security Context ID is not included directly, but modification of this field will cause processing (verification or acceptance) of the associated security operations to fail.¶
• The Security Source field is always included as external AAD, so is protected from modification.¶
• The Security Context Flags and Security Context Parameters are not all included directly, but the modification of parameters will cause processing of security operations to fail. The Additional Protected parameter is the portion of this data which is included in the external AAD.¶
• The Security Results are also not included directly, but these are the COSE messages themselves which are designed to be handled as plaintext. There are portions of each COSE message (result) which is included in the internal AAD (via MAC_structure, Sig_structure, or Enc_structure) as defined by COSE [RFC9052].¶

Because of these options, it is possible for a security source to create a COSE context integrity operation which covers every block of a bundle at the time the BIB is added (excluding CRC Type and value fields). By using a minimal AAD scope it is also possible for an integrity operation to cover only the BTSD of its single target block independently of the block metadata or bundle primary block associated with the target at the time the BIB is added. Likewise, it is possible for a COSE context confidentiality operation to be bound to every other block of a bundle at the time the BCB is added or bound to no context outside the BTSD of the target block.¶

2.2. Parameters

Each COSE context parameter value SHALL consist of the COSE structure indicated by Table 1 in its decoded CBOR item form.¶

Each security block SHALL contain no more than one instance of each parameter ID. Security verifiers and acceptors SHALL treat a security block with multiple instances of any parameter ID as invalid. There is no well-defined behavior for a security acceptor to handle multiple Additional Protected or AAD Scope parameters.¶

When a parameter is not present and a default value is defined below, a security verifier or acceptor SHALL use that default value to process the target:¶

• The default additional-protected is '' (an empty byte string).¶
• The default additional-unprotected is '' (an empty byte string).¶
• The default AAD-scope is {0:0b1,-1:0b1,-2:0b1} (a map which indicates the AAD contains the metadata of the primary, target, and security blocks).¶

$bpsec-cose-param /= [3, additional-protected]
additional-protected = empty_or_serialized_map

$bpsec-cose-param /= [4, additional-unprotected]
additional-unprotected = empty_or_serialized_map

$bpsec-cose-param /= [5, AAD-scope]
AAD-scope = {
    *AAD-scope-key => AAD-scope-val
}
; All uint keys are block numbers
AAD-scope-key = uint / ($blk-id-special .within (-1 .. -65536))
$blk-id-special /= -1 ; target block
$blk-id-special /= -2 ; security block

AAD-scope-val = uint .bits $AAD-scope-flags
$AAD-scope-flags /= 0 ; AAD-metadata
$AAD-scope-flags /= 1 ; AAD-btsd

2.3. Results

Each COSE context result contains a COSE message, but the types of message allowed depend upon the security block type in which the result is present: only MAC or signature messages are allowed in a BIB and only encryption messages are allowed in a BCB.¶

Additionally, this context restricts each security operation (embodied as a security target with a result array) to be associated with only a single COSE message (i.e., a single result for each target). Within the security context defined in this section, each abstract security block SHALL contain exactly one result per security target. Security verifiers and acceptors SHALL treat other combinations of results-per-target as invalid. Security policies can be tailored for this constraint, which has a side effect that each security operation also has only a single set of COSE layer 0 header parameters (e.g., COSE algorithm).¶

The code points for Result ID values are identical to the existing COSE message-marking tags in Section 2 of [RFC9052]. This avoids the need for value-mapping between code points of the two registries.¶

When embedding COSE messages, the message CBOR structure SHALL be encoded as a byte string used as the result value. This allows a security verifier or acceptor to skip over unwanted results without needing to decode the result structure. When embedding COSE messages, the CBOR-tagged form SHALL NOT be used. The Result ID values already provide the same information as the COSE tags (using the same code points).¶

These generic requirements are formalized in the CDDL fragment of Figure 4.¶

$bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0]
$bpsec-cose-result /= [17, bstr .cbor COSE_Mac0]
$bpsec-cose-result /= [18, bstr .cbor COSE_Sign1]
$bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt]
$bpsec-cose-result /= [97, bstr .cbor COSE_Mac]
$bpsec-cose-result /= [98, bstr .cbor COSE_Sign]

3.1. COSE Messages

When generating a BPSec result, security sources SHALL use only COSE labels with a uint value. When processing a BPSec result, security verifiers and acceptors MAY handle COSE labels with with a tstr value.¶

When used in a BPSec result, each COSE message SHALL contain an explicit algorithm identifier in the first (content) layer in accordance with [RFC9052]. When available, each COSE message SHALL contain a key identifier in the last layer for all signatures or recipients. See Section 3.4 and Section 3.5 for specifics about key identifiers. When a key identifier is not available, BPSec verifiers and acceptors SHALL use the Security Source and the Bundle Source to imply which keys can be used for security operations. Using implied keys has an interoperability risk, see Section 5.5 for details. A BPSec security operation always occurs within the context of the immutable primary block with its parameters (specifically the Source Node ID) and the security block with its optional Security Source.¶

The algorithms required by this profile support using shared symmetric keys using modern key strengths, with recommended algorithms to support elliptic curve cryptography (ECC) keypairs and RSA keypairs. The focus of this profile is to enable interoperation between security sources and acceptors on an open network, where more explicit COSE parameters make it easier for BPSec acceptors to avoid assumptions and avoid out-of-band parameters. The requirements of this profile still allow the use of potentially not-easily-interoperable algorithms and message/recipient configurations for use by private networks, where message size is more important than explicit COSE parameters.¶

3.2. Interoperability Algorithms

The minimum set of COSE algorithms needed for interoperability in non-constrained devices is listed in this section and organized by the type of associated key material. This profile intentionally does not prohibit the use of any other algorithms in specific implementations, devices, or networks and is meant only to provide a starting point for general purpose implementations. It also does not address post-quantum algorithms which have been finalized by NIST but are still undergoing standardization in the IETF (see Section 5.8. The full set of COSE algorithms available is managed at [IANA-COSE].¶

Each algorithm in this profile is marked as being US CNSS CNSA 1.0 conformant [CNSA1] or CNSA 2.0 conformant [CNSA2] to aid in further narrowing of network-specific profiles and implementations. All of these algorithms in this profile are approved by US NIST FIPS 140-3 [FIPS-140], however FIPS 140 certification involves review of software and hardware design and implementation detail outside the scope of this document.¶

The threshold for minimum security strength to be included in this interoperability minimum is roughly equivalent to CNSA 1.0 and the CCSDS Space Data Link Security rationale green book [SDLS]. The breadth of algorithm variety is intended to cover many different current use cases beyond simple symmetric key security and be compatible with current PKIX mechanisms and strategies.¶

3.4. Symmetric Keys and Identifiers

This section applies when a BIB or BCB uses a shared symmetric key for MAC, encryption, or key-wrap. When using symmetric keyed algorithms, the security source SHALL include a symmetric key identifier as a signature or recipient header. The symmetric key identifier SHALL be either a "kid" of [RFC9052] (possibly with "kid context" of [RFC8613]), or an equivalent identifier. This requirement makes the selection of keys by verifiers and acceptors unambiguous.¶

When present, a "kid" parameter is used to uniquely identify a single shared key known to the security source and all expected security verifiers and acceptors. Specific strategies or mechanisms to generate or ensure uniqueness of "kid" values within some domain of use is outside the scope of this profile. Specific users of this profile can define such mechanisms specific to their abilities and needs.¶

When present, a "kid context" parameter SHALL be used as a correlator with a larger scope than an individual "kid" value. The use of a "kid context" allows security verifiers and acceptors to correlate using that larger scope even if they cannot match the sibling "kid" value. For example, a "kid context" can be used to identify a long-lived security association between two entities while an individual "kid" identifies a single shared key agreed within that larger association.¶

3.5. Asymmetric Key Types and Identifiers

This section applies when a BIB uses a public key for verification or key-wrap, or when a BCB uses a public key for encryption or key-wrap. When using asymmetric keyed algorithms, the security source SHALL include a public key container or public key identifier as a signature or recipient header. The public key identifier SHALL be either an "x5t" or "x5chain" of [RFC9360], or "kid" (possibly with "kid context"), or an equivalent identifier.¶

When BIB result contains a "x5t" identifier, the security source MAY include an appropriate certificate container ("x5chain" or "x5bag") in a direct COSE header or an additional header security parameter (see Section 2.2.1). When a BIB result contains an "x5chain", the security source SHOULD NOT also include an "x5t" because the first certificate in the chain is implicitly the applicable end-entity certificate. For a BIB, if all potential security verifiers and acceptors are known to possess related public key and/or certificate data then the public key or additional header parameters can be omitted. Risks of not including related credential data are described in Section 5.5 and Section 5.6.¶

When present, public keys and certificates SHOULD be included as additional header parameters rather than within result COSE messages. This provides size efficiency when multiple security results are present because they will all be from the same security source and likely share the same public key material. Security verifiers and acceptors SHALL still process public keys or certificates present in a result message or recipient as applying to that individual COSE level.¶

Security verifiers and acceptors SHALL aggregate all COSE Key objects from all parameters within a single BIB or BCB, independent of encoded type or order of parameters. Because each context contains a single set of security parameters which apply to all results in the same context, security verifiers and acceptors SHALL treat all public keys as being related to the security source itself and potentially applying to every result.¶

3.6. Policy Recommendations

The RECOMMENDED priority policy for including public key identifiers for BIB results is as follows:¶

1. When receivers are not known to possess certificate chains, a full chain is included (as an "x5chain").¶
2. When receivers are known to possess root and intermediate CAs, just the end-entity certificate is included (again as an "x5chain").¶
3. When receivers are known to possess associated chains including end-entity certificates, a certificate thumbnail (as an "x5t").¶
4. Some arbitrary identifier is used to correlate to an end-entity certificate (as a "kid" with an optional "kid context").¶
5. The BIB Security Source is used to imply an associated end-entity certificate which identifies that Node ID.¶

When certificates are used for public key data and the end-entity certificate is not explicitly trusted (i.e. pinned), a security verifier or acceptor SHALL perform the certification path validation of Section 2.6.1.2 up to one or more trusted CA certificates. Leaving out part of the certification chain can cause a security verifier or acceptor to fail to validate a BIB if the left-out certificates are unknown to the acceptor (see Section 5.6).¶

The RECOMMENDED priority policy for including public key identifiers for BCB results is as follows:¶

1. When receivers are known to possess associated end-entity certificates, a certificate thumbnail (as an "x5t").¶
2. Some arbitrary identifier is used to correlate to the private key (as a "kid" with an optional "kid context").¶

Any end-entity certificate associated with a BIB security source or BCB result recipient SHALL adhere to the profile of Section 4.¶

4.1. Multiple-Certificate Uses

A RECOMMENDED security policy is to limit asymmetric keys (and thus public key certificates) to single uses among the following:¶

Bundle transport:

With key uses as defined in the convergence layer specification(s). Transports can require additional Extended Key Usage, such as id-kp-serverAuth or id-kp-clientAuth.¶

Block signing:

With key use digitalSignature and/or nonRepudiation.¶

Block encryption:

With key use keyEncipherment and/or keyAgreement.¶

This policy is the same one recommended by Section 6 of [RFC8551] for email security and by Section 5.2 of [SP800-57] more generally. Effectively this means that a BP node uses separate certificates for transport (e.g., as a TCPCL entity), BIB signing (as a security source), and BCB encryption (as a security acceptor).¶

5.2. Threat: Untrusted End-Entity Certificate

The profile in Section 2.6.1 uses end-entity certificates chained up to a trusted root CA, where each certificate has a specific validity time interval.¶

A security verifier or acceptor needs to assemble an entire certificate chain in order to validate the use of an end-entity certificate. A security source can include a certificate set which does not contain the full chain, possibly excluding intermediate or root CAs. In an environment where security verifiers and acceptors are known to already contain needed root and intermediate CAs there is no need to include those CAs, but this has a risk of a relying node not actually having one of the needed CAs.¶

A security verifier or acceptor needs to use the bundle creation time when assembling a certificate chain and and validating it. Because of this, a security source needs to use the bundle creation time as the specific instant for choosing appropriate certificate(s) based on their validity time interval. The selection of a certificate outside of its validity time period will cause the entire security operation to be unusable.¶

5.4. Threat: Security Source Impersonation

When certificates are referenced by BIB results it is possible that the certificate does not contain a NODE-ID or does contain one but has a mismatch with the actual security source (see Section 1.2). Having a CA-validated certificate does not alone guarantee the identity of the security source from which the certificate is provided; additional validation procedures in Section 2.6.1 bind the Node ID based on the contents of the certificate.¶

5.5. Threat: Unidentifiable Key

The profile in Section 3.2 recommends key identifiers when possible and the parameters in section Section 2.2 allow encoding public keys where available. If the application using a COSE Integrity or COSE Confidentiality context leaves out key identification data (in a COSE recipient structure), a security verifier or acceptor for those BPSec blocks only has the primary block available to use when verifying or decrypting the target block. This leads to a situation, identified in BPSec Security Considerations, where a signature is verified to be valid but not from the expected Security Source.¶

Because the key identifier headers are unprotected (see Section 3.5), there is still the possibility that an active attacker removes or alters key identifier(s) in the result. This can cause a security verifier or acceptor to not be able to properly verify a valid signature or not use the correct private key to decrypt valid ciphertext.¶

5.6. Threat: Non-Trusted Public Key

The profile in Section 3.2 allows the use of PKIX which typically involves end-entity certificates chained up to a trusted root CA. A BIB can reference or contain end-entity certificates not previously known to a security acceptor but the acceptor can still trust the certificate by verifying it up to a trusted CA. In an environment where security verifiers and acceptors are known to already contain needed root and intermediate CAs there is no need to include those CAs in a proper chain within the security parameters, but this has a risk of an acceptor not actually having one of the needed CAs.¶

Because the security parameters are not included as AAD, there is still the possibility that an active attacker removes or alters certification chain data in the parameters. This can cause a security verifier or acceptor to be able to verify a valid signature but not trust the public key used to perform the verification.¶

5.8. Threat: Algorithm Vulnerabilities

Because this use of COSE leaves the specific algorithms chosen for BIB and BCB use up to the applications securing bundle data, it is important to use only COSE algorithms which are marked as "recommended" in the IANA registry [IANA-COSE].¶

Specifically for the case of vulnerability to a cryptographically relevant quantum computer, algorithms for signing and key encapsulation have been identified in [CNSA2] but are not yet available as COSE code points allocated by published standards.¶

6.1. Bundle Protocol

Within the "Bundle Protocol" registry group [IANA-BUNDLE], the following entry has been added to the "BPSec Security Context Identifiers" registry.¶

Within the "Bundle Protocol" registry group [IANA-BUNDLE], the IANA has created and now maintains a new registry named "BPSec COSE AAD Scope Special Keys". Table 12 shows the initial values for this registry.¶

The registration policy for this registry is Specification Required. Specifications of new entries need to define how they relate to AAD generation procedure of Section 2.5.1.¶

The value range is negative 16-bit integer. This value range is combined with the non-negative 64-bit integer block numbers for the AAD Scope key domain (Section 2.2.2).¶

Within the "Bundle Protocol" registry group [IANA-BUNDLE], the IANA has created and now maintains a new registry named "BPSec COSE AAD Scope Flags". Table 13 shows the initial values for this registry.¶

The registration policy for this registry is Specification Required. Specifications of new entries need to define how they relate to AAD generation procedure of Section 2.5.1.¶

The value range is a bit position within an unsigned 64-bit integer.¶

A.2. ECC Keypair COSE_Sign1

This is an example of a signature with the signer having a P-384 curve ECC keypair identified by a "kid".¶

[
  { / signing private key /
    / kty / 1: 2, / EC2 /
    / kid / 2: 'ExampleA.2',
    / alg / 3: -51, / ESP384 /
    / ops / 4: [1, 2], / sign, verify /
    / crv / -1: 2, / P-384 /
    / x / -2: h'02dfc49747f5d3d219fe6185744729fa1672ef7d11cb57ca0320
c632be06ca3fdcc118e63140ba3ec57ea7b85d419568',
    / y / -3: h'4526e81bf0d9ea0924f05a3453ad75b92806671511544c993f6b
d908a7a4239d476cfdfd74d6c68836488ad1e60b0e7d',
    / d / -4: h'3494803544d85a84d802400b50f51eea23b72d7d850b53cbf300
6e5be2940d4a2c18d510a412efc7dc7875fbba22cca9'
  }
]

The external_aad is the encoded data from Figure 10. The payload is the encoded target BTSD from Figure 7.¶

[
  "Signature1", / context /
  h'a10126', / protected /
  h'8201662f2f7372632fa200012001890700028201692f2f6473742f7376638201
692f2f7372632f7376638201662f2f7372632f821b000000bd51281400001a000f42
404482a081c901010040', / external_aad /
  h'6568656c6c6f' / payload /
]

[1], / targets /
3, / security context /
1, / flags: params-present /
[1, "//src/"], / security source /
[ / parameters /
  [
    5, / AAD-scope /
    {0:0b1,-1:0b1} / primary metadata, target metadata /
  ]
],
[
  [ / target block #1 /
    [ / result /
      18, / COSE_Sign1 tag /
      <<[
        <<{ / protected /
           / alg / 1: -51 / ESP384 /
        }>>,
        { / unprotected /
          / kid / 4: 'ExampleA.2'
        },
        null, / payload detached /
        h'9c64328dfe9570262f5be687c35cc51ced48b8682d2a61d8baadfd3410
233634251c2c1862b0a194b8503985931051a77731a74a1514b83092d7c662e6dbcd
a2629af72b24bf1cc3c5e2552f54ddfcc1762e6bc46fd5e6c2137e4a695e563e
ae' / signature /
      ]>>
    ]
  ]
]

The final bundle is encoded as the following 229 octets in base-16:¶

9f890700028201692f2f6473742f7376638201692f2f7372632f7376638201662f2f
7372632f821b000000bd51281400001a000f42404482a081c9850b03000058918101
03018201662f2f7372632f818205a2000120018181821258768444a1013832a1044a
4578616d706c65412e32f658609c64328dfe9570262f5be687c35cc51ced48b8682d
2a61d8baadfd3410233634251c2c1862b0a194b8503985931051a77731a74a1514b8
3092d7c662e6dbcda2629af72b24bf1cc3c5e2552f54ddfcc1762e6bc46fd5e6c213
7e4a695e563eae8601010002466568656c6c6f444ec359d2ff

A.5. Symmetric Key COSE_Encrypt with Key Wrap

This is an example of an encryption with a random CEK and an explicit key-encryption key (KEK) identified by a "kid". The keys used are shown in Figure 25.¶

[
  {
    / kty / 1: 4, / symmetric /
    / kid / 2: 'ExampleA.5',
    / alg / 3: -5, / A256KW /
    / ops / 4: [5, 6], / wrap, unwrap /
    / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf
ae38ad7a972e'
  },
  { / wrapped CEK /
    / kty / 1: 4, / symmetric /
    / alg / 3: 3, / A256GCM /
    / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
99dbae4ce45c'
  }
]

The external_aad is the encoded data from Figure 10.¶

[
  "Encrypt", / context /
  h'a10103', / protected /
  h'8201662f2f7372632fa200012001890700028201692f2f6473742f7376638201
692f2f7372632f7376638201662f2f7372632f821b000000bd51281400001a000f42
404482a081c901010040' / external_aad /
]

The ASB item for this encryption operation is shown in Figure 27 and corresponds with the updated target block (containing the ciphertext) of Figure 11. The recipient does not have any protected header parameters because AES Key Wrap does not allow any AAD.¶

[1], / targets /
3, / security context /
1, / flags: params-present /
[1, "//src/"], / security source /
[ / parameters /
  [
    5, / AAD-scope /
    {0:0b1,-1:0b1} / primary metadata, target metadata /
  ]
],
[
  [ / target block #1 /
    [ / result /
      96, / COSE_Encrypt tag /
      <<[
        <<{ / protected /
           / alg / 1: 3 / A256GCM /
        }>>,
        { / unprotected /
          / iv / 5: h'6f3093eba5d85143c3dc484a'
        },
        null, / payload detached /
        [
          [ / recipient /
            <<>>, / protected /
            { / unprotected /
              / alg / 1: -5, / A256KW /
              / kid / 4: 'ExampleA.5'
            },
            h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d4
03a6331159e3d691a708e9984d' / key-wrapped /
          ]
        ]
      ]>>
    ]
  ]
]

The final bundle is encoded as the following 209 octets in base-16:¶

9f890700028201692f2f6473742f7376638201692f2f7372632f7376638201662f2f
7372632f821b000000bd51281400001a000f42404482a081c9850c030000586d8101
03018201662f2f7372632f818205a200012001818182186058518443a10103a1054c
6f3093eba5d85143c3dc484af6818340a20124044a4578616d706c65412e35582891
7f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d403a6331159e3d691
a708e9984d8601010002561fd25f64a2ee33e774abe16700bcfd9cf12ea5f7d84144
47abdef0ff

A.7. ECC Keypair COSE_Encrypt with Key Wrap

This is an example of an encryption with an P-384 curve ephemeral sender keypair and a static recipient keypair identified by a "kid". The keys used are shown in Figure 32.¶

[
  { / sender ephemeral private key /
    / kty / 1: 2, / EC2 /
    / crv / -1: 2, / P-384 /
    / x / -2: h'2f88f095c45c96e377e18d717a5e6007ce8f6076ae82009d1637
5e1b9abaa9497a4bde513be6c9b0e7dae96033968c45',
    / y / -3: h'fd27656fbb97f789d667f40d73b65ab362b22dd23bf492bee72b
f3409f68dddf208040a5fcbcbee74545741e2866cb2d',
    / d / -4: h'c4fff15193b8bceff5e221cc37b919fa8d33581a37c08d3e8520
a658b4040a443f8fb3b54fb4ce882510e76017b66261'
  },
  { / recipient private key /
    / kty / 1: 2, / EC2 /
    / kid / 2: 'ExampleA.7',
    / alg / 3: -31, / ECDH-ES + A256KW /
    / ops / 4: [7], / derive key /
    / crv / -1: 2, / P-384 /
    / x / -2: h'0057ea0e6fdc50ddc1111bd810eae7c0ba24645d44d4712db0c8
354c234b2970b4ac27e78f38250069d128f98e51ceb1',
    / y / -3: h'4b72c50b27267637c40adcd78bd025e4b654a645d2ba7ba9894c
c73b2431d4cdc040d66e8eb2dad731f7dca57108545c',
    / d / -4: h'7931af7cc3010ae457bcb8be100acdafab8492de633b20384c3e
4de5e5e94899d9d9de25c04d6205ae6bb9385ce16ff7'
  },
  { / wrapped CEK /
    / kty / 1: 4, / symmetric /
    / alg / 3: 3, / A256GCM /
    / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
99dbae4ce45c'
  }
]

The external_aad is the encoded data from Figure 10.¶

[
  "Encrypt", / context /
  h'a10103', / protected /
  h'8201662f2f7372632fa200012001890700028201692f2f6473742f7376638201
692f2f7372632f7376638201662f2f7372632f821b000000bd51281400001a000f42
404482a081c901010040' / external_aad /
]

The ASB item for this encryption operation is shown in Figure 34 and corresponds with the updated target block (containing the ciphertext) of Figure 11.¶

[1], / targets /
3, / security context /
1, / flags: params-present /
[1, "//src/"], / security source /
[ / parameters /
  [
    5, / AAD-scope /
    {0:0b1,-1:0b1} / primary metadata, target metadata /
  ]
],
[
  [ / target block #1 /
    [ / result /
      96, / COSE_Encrypt tag /
      <<[
        <<{ / protected /
           / alg / 1: 3 / A256GCM /
        }>>,
        { / unprotected /
          / iv / 5: h'6f3093eba5d85143c3dc484a'
        },
        null, / payload detached /
        [
          [ / recipient /
            <<{ / protected /
              / alg / 1: -31 / ECDH-ES + A256KW /
            }>>,
            { / unprotected /
              / kid / 4: 'ExampleA.7',
              / ephemeral key / -1: {
                1: 2,
                -1: 2,
                -2: h'2f88f095c45c96e377e18d717a5e6007ce8f6076ae8200
9d16375e1b9abaa9497a4bde513be6c9b0e7dae96033968c45',
                -3: h'fd27656fbb97f789d667f40d73b65ab362b22dd23bf492
bee72bf3409f68dddf208040a5fcbcbee74545741e2866cb2d'
              }
            },
            h'0eaff015e61418d8910ba25ed9733450558b6a20ab410f3c925b01
ac8d3aefcc12433f9563da401d' / key-wrapped /
          ]
        ]
      ]>>
    ]
  ]
]

The final bundle is encoded as the following 319 octets in base-16:¶

9f890700028201692f2f6473742f7376638201692f2f7372632f7376638201662f2f
7372632f821b000000bd51281400001a000f42404482a081c9850c03000058db8101
03018201662f2f7372632f818205a200012001818182186058bf8443a10103a1054c
6f3093eba5d85143c3dc484af6818344a101381ea2044a4578616d706c65412e3720
a4010220022158302f88f095c45c96e377e18d717a5e6007ce8f6076ae82009d1637
5e1b9abaa9497a4bde513be6c9b0e7dae96033968c45225830fd27656fbb97f789d6
67f40d73b65ab362b22dd23bf492bee72bf3409f68dddf208040a5fcbcbee7454574
1e2866cb2d58280eaff015e61418d8910ba25ed9733450558b6a20ab410f3c925b01
ac8d3aefcc12433f9563da401d8601010002561fd25f64a2ee33e774abe16700bcfd
9cf12ea5f7d8414447abdef0ff

A.8. ECC Keypair COSE_Encrypt with HKDF

This is an example of an encryption with an P-384 curve static sender keypair and a static recipient keypair each identified by a "kid". The keys used are shown in Figure 35, where the third key is the CEK derived from the ECDH secret via a salt value in the recipient header.¶

[
  {
    / kty / 1: 2, / EC2 /
    / kid / 2: 'SenderA.8',
    / alg / 3: -28, / ECDH-SS + HKDF-512 /
    / ops / 4: [7], / derive key /
    / crv / -1: 2, / P-384 /
    / x / -2: h'2f88f095c45c96e377e18d717a5e6007ce8f6076ae82009d1637
5e1b9abaa9497a4bde513be6c9b0e7dae96033968c45',
    / y / -3: h'fd27656fbb97f789d667f40d73b65ab362b22dd23bf492bee72b
f3409f68dddf208040a5fcbcbee74545741e2866cb2d',
    / d / -4: h'c4fff15193b8bceff5e221cc37b919fa8d33581a37c08d3e8520
a658b4040a443f8fb3b54fb4ce882510e76017b66261'
  },
  { / recipient private key /
    / kty / 1: 2, / EC2 /
    / kid / 2: 'ExampleA.8',
    / alg / 3: -28, / ECDH-SS + HKDF-512 /
    / ops / 4: [7], / derive key /
    / crv / -1: 2, / P-384 /
    / x / -2: h'0057ea0e6fdc50ddc1111bd810eae7c0ba24645d44d4712db0c8
354c234b2970b4ac27e78f38250069d128f98e51ceb1',
    / y / -3: h'4b72c50b27267637c40adcd78bd025e4b654a645d2ba7ba9894c
c73b2431d4cdc040d66e8eb2dad731f7dca57108545c',
    / d / -4: h'7931af7cc3010ae457bcb8be100acdafab8492de633b20384c3e
4de5e5e94899d9d9de25c04d6205ae6bb9385ce16ff7'
  },
  { / derived CEK /
    / kty / 1: 4, / symmetric /
    / alg / 3: 3, / A256GCM /
    / k / -1: h'67bb109aaee51e9616b512d5750139444ca26e6c0eeaa87f3917
de41dd9ad9f6'
  }
]

The external_aad is the encoded data from Figure 10.¶

[
  "Encrypt", / context /
  h'a10103', / protected /
  h'8201662f2f7372632fa200012001890700028201692f2f6473742f7376638201
692f2f7372632f7376638201662f2f7372632f821b000000bd51281400001a000f42
404482a081c901010040' / external_aad /
]

The ASB item for this encryption operation is shown in Figure 37 and corresponds with the updated target block (containing the ciphertext) of Figure 38. This ciphertext is different than the common one in Figure 11 because of the different derived CEK in Figure 35.¶

[1], / targets /
3, / security context /
1, / flags: params-present /
[1, "//src/"], / security source /
[ / parameters /
  [
    5, / AAD-scope /
    {0:0b1,-1:0b1} / primary metadata, target metadata /
  ]
],
[
  [ / target block #1 /
    [ / result /
      96, / COSE_Encrypt tag /
      <<[
        <<{ / protected /
           / alg / 1: 3 / A256GCM /
        }>>,
        { / unprotected /
          / iv / 5: h'6f3093eba5d85143c3dc484a'
        },
        null, / payload detached /
        [
          [ / recipient /
            <<{ / protected /
              / alg / 1: -28 / ECDH-SS + HKDF-512 /
            }>>,
            { / unprotected /
              / kid / 4: 'ExampleA.8',
              / sender kid / -3: 'SenderA.8',
              / salt / -20: h'2fa8c8352aea17faf7407271a5e90eb8'
            },
            h'' / empty /
          ]
        ]
      ]>>
    ]
  ]
]

[
  1, / type code: payload /
  1, / block num /
  0, / flags /
  2, / CRC type /
  h'925c33206eb89fdc076f17489de3056e997a227b8d53', / ciphertext /
  h'8eec52c4'
]

The final bundle is encoded as the following 199 octets in base-16:¶

9f890700028201692f2f6473742f7376638201692f2f7372632f7376638201662f2f
7372632f821b000000bd51281400001a000f42404482a081c9850c03000058638101
03018201662f2f7372632f818205a200012001818182186058478443a10103a1054c
6f3093eba5d85143c3dc484af6818344a101381ba3044a4578616d706c65412e3822
4953656e646572412e3833502fa8c8352aea17faf7407271a5e90eb8408601010002
56925c33206eb89fdc076f17489de3056e997a227b8d53448eec52c4ff

A.9. RSA Keypair COSE_Encrypt

This is an example of an encryption with a recipient having a 3072-bit RSA keypair identified by a "kid". The associated public key is included as a security parameter.¶

This key strength is not supposed to be a secure configuration, only intended to explain the procedure. This padding scheme uses a random salt, so the full Layer 1 ciphertext output is not deterministic.¶

[
  { / recipient private key /
    / kty / 1: 3, / RSA /
    / kid / 2: 'ExampleA.9',
    / alg / 3: -42, / RSAES-OAEP w SHA-512 /
    / ops / 4: [5, 6], / wrap, unwrap /
    / n / -1: h'bb4917794481770c92a1ba6a35fbe0677a5c3669cd39c530985a
234765d0c0acc874925b1578e08f5d71dec62c1d28bb237fc3f1ddf8f01cab5ac207
5ade1747958d818fd332781891dbda85e00d0006a538f88d28900f69d93c340bd7da
8d47d0e63b448671b885d35a275a7204ed15bea0276ace4bbca291d2843b4454fce8
5faf78056753b6331b01f54c52eca23c0c255ea53919a972b548777049dc64bc4261
7ae74fc1af5bd10d72102f32347e12161d9fb1d43c9cbf26a49bd65a6b282276a634
15c52b36ce2a186f0ecc6b15a4c596c67a9eafca72e665c3a91062b22d1f00d05fb3
fb120f34263406c64848d93baa65985a7974aafc39f83a39c896c907da9b7e6df1a6
f9c3588ebd5ae5d6dfce569e15d17a4594098c1606b3b94cfdeff8dc41e56e9592fc
59de96b6aae1729444ee28e6fedd59e432f0670465a65212774ece52c205748ec207
db332feef700d2b4a2c2a7d40efddac627d816b872c6e12b074704b12f2dbb92b44f
7bd799a2848ef0c17e1783baa33e89c1bb4b',
    / e / -2: h'010001',
    / d / -3: h'8d0b34532ce688fadcb4dea67fd303ad0c84632f87d2cf57e59a
80319defb97dfafa13c247d3828c6bcac2567507108e84ad8937cd25676ac70f45d6
07360efa5efd3daf42a19758dfd557775b56da4b68bc4f70c728ef09df397b57e01e
17f2c96afba541d096365e9c549df5ed82d9d9c0d43ca3f454af1c6701afd1749636
03f20f52f647225a24e81403c72dd0336ff99027d44f12b073d87faa8c263f1fe505
03757be3210c455df6e92f9aaf89a63ec49b884af7648c168a7116848087b94db5a8
2435e98249723543fdbe8bf420faa6f578c382738a2a2753e7886e8152ba5ec8291d
002b87a068a73fc5f3a3379424582d1ed5b4c338475c8de509f37c3092d3fd8337b0
9b0d9725add3380d921d4f9f90700116b5543cb8a40c3ec0e4661cf09f0ebf62c57c
dbf63c59390d6f1d2dbd2ea09be5c21d2732109e7787cb9a4582d8c2be712a2d9355
c1b8ba1e597dc2012bb920e551a6fddc0c7db08ab32b0add6ddedab6b70b4c3105dc
ed09a49c6cf6e325b8b80c65fc1859fcd5',
    / p / -4: h'fa214874981ce573589c4eb4682c12aed490c66714a4e339ea2d
b376b6dac4bd997fdeacccd4b514daeda487b86a273dec8746a5debb3f776c46367c
f163f968c76900de21a20b75201b9a376327158e90a52e3e24e3c60b79102a572ad9
f859364fdce1c14da0379480ee87c20fd54454847a41c644fff9e9e72b6d42dbcd5b
7d343abbf785e72d494fd60e309322e5bcb20763f56c6000ae975eb6d4c23e1f3e0b
6f6d52b74cefaa6045fbd0697740895b45af918faf75febec37f6e88eb55',
    / q / -5: h'bfae414a486903f3f203382d3995dcae8e1e716b8835d1126819
4879d9dad3d57396e3fd52a16272221d25a2f8e82eccc29c16751061e903566825cd
66e562bad038b002684356411bc323d8212c8b7aac4dd481b511e9de45ab3b6cab78
50d30f2861e0e7c6778d26b19458fff4f74d2b65af87234a090ab241ea8a51b8cb15
294b1b283bead83f9064cb32cbe0f25807ee946484c6a777c19a7bd2a214cbc9ed17
8552e0afd7748511333375753852fb0b4e9c8d4fcab2d2372be59c104c1f',
    / dP / -6: h'92f19ca44a7ca75b751216b6ab8040d58eb122ad8a16381b5cf
4ce3a8ebfc4d6f1e78a04902ce1d8c7a8d68099195bc6683f2c84e36db3a24fec8bb
42907a78d23a10f4e7009c79b5e6a78d5d31d31efd8100233a5ee5df97d7cbeb308c
c96b6aa4e8e9fddb4e1cbe5253d7c69c86d6cc00e37d88e4718ee53b867edbf5a6bb
134c3cb4183ef995924798f72349d2be235518d3feefd6504e18cb1aacd20f3e7dcc
65106b39255d3728f2e6dfa090b72d17eda5883361b4941880647c5c31025',
    / dQ / -7: h'933ea1191716d4da8886c098bd2bca22ad39e596dd43ba1f91a
81a6cc055c174af1eb274df0cea3b12c9a127d85d43d6378900175d4659611ef7525
2bf4066df6b24a0d0b89741a332586d2892134df2267a834c40744a5b5cd97504bd9
3e742bada22964a75c350c2f0972ce7329ee6c0f79427138cc3f55b8a1749ba0d62b
416cc83481cff02af91945c23e14a23e04bf79236c568752d21a4328a53c7f5e4602
5395db90c5b4e3f0a3f72c04013cc6adcfcbe762f5d5e90eda0e2f947ebb1',
    / qInv / -8: h'2f61ebed182ff0375be59300f2f0f4302f915274756b13dfa
3847b56259c87a204e7188656460afec04bf8889ad2ab6cd54d56cbff63eeac06620
ec6cadca22ba4cc4ee29b6195aaab25ef33455ef204eb75f93e9fc2b0c7bfe11f112
7c2b9102e729a504eb1bd350c70568acbab5b5feffa8272f0458ba66491fd93387e8
6b8c8c2ed69845b6dffc0b3800dc175d3bdf40e154053141e54db17f9515dfa719de
b426775bac26854b539e18176f89e785bacd4672534f683f80b2cc7927bf8f7'
  },
  { / encapsulated CEK /
    / kty / 1: 4, / symmetric /
    / alg / 3: 3, / A256GCM /
    / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
99dbae4ce45c'
  }
]

The external_aad is the encoded data from Figure 10.¶

[
  "Encrypt", / context /
  h'a10103', / protected /
  h'8201662f2f7372632fa200012001890700028201692f2f6473742f7376638201
692f2f7372632f7376638201662f2f7372632f821b000000bd51281400001a000f42
404482a081c901010040' / external_aad /
]

The ASB item for this encryption operation is shown in Figure 41 and corresponds with the updated target block (containing the ciphertext) of Figure 11. The recipient does not have any protected header parameters because RSA OAEP does not allow any AAD.¶

[1], / targets /
3, / security context /
1, / flags: params-present /
[1, "//src/"], / security source /
[ / parameters /
  [
    5, / AAD-scope /
    {0:0b1,-1:0b1} / primary metadata, target metadata /
  ]
],
[
  [ / target block #1 /
    [ / result /
      96, / COSE_Encrypt tag /
      <<[
        <<{ / protected /
           / alg / 1: 3 / A256GCM /
        }>>,
        { / unprotected /
          / iv / 5: h'6f3093eba5d85143c3dc484a'
        },
        null, / payload detached /
        [
          [ / recipient /
            <<>>, / protected /
            { / unprotected /
              / alg / 1: -42, / RSAES-OAEP w SHA-512 /
              / kid / 4: 'ExampleA.9'
            },
            h'50901651a7f2d911da19ced267bf2390bd9af7d0e0617a3212c59c
f1ae237041aa81ff8e169c49a570be2c5eeced21c4666d4b385b36462e486f011791
ec7f86e9b0afe0affafc12f26d605ef13396675d6d4642448a5fd9a1cfdd999f1423
31d894501f8b82d08e7d1703ab14eaf510bcc4e18e373ab2ed502ebb99dc0035f393
c4cbdea8b40535e528017087ee700442539e7cf079950de91c0aa9f058c66e15a640
eba39b4e619c4daf6c08beaf654932f8f88ad8685e87402f75be68bf3dd2e5539a7d
0ea880ec89788c36dc3a6603eda6999f519eed0f62302ea92adc13d52bf7898eb1ab
1aa587bf8f278059ede7c75204d3d69f67b00b50cd70a8724eb2a204c275981af92a
4ae21b77d9ca8be275fb4a1edbba3edcae4a0f964ca913326a9507c4c6647adc9487
82136036f73cbfba33e1b5977591931b99ce536015bfb89c062c3208189bdc43e530
6cdaefa81a769df267d00233e375e5b0b027974fda218f318c7cd7c1fdbfe8548fb2
71f3b14de9a50d7bb23e26feb3cc1ea882' / key-encapsulation /
          ]
        ]
      ]>>
    ]
  ]
]

The final bundle is encoded as the following 557 octets in base-16:¶

9f890700028201692f2f6473742f7376638201692f2f7372632f7376638201662f2f
7372632f821b000000bd51281400001a000f42404482a081c9850c0300005901c881
0103018201662f2f7372632f818205a20001200181818218605901ab8443a10103a1
054c6f3093eba5d85143c3dc484af6818340a2013829044a4578616d706c65412e39
59018050901651a7f2d911da19ced267bf2390bd9af7d0e0617a3212c59cf1ae2370
41aa81ff8e169c49a570be2c5eeced21c4666d4b385b36462e486f011791ec7f86e9
b0afe0affafc12f26d605ef13396675d6d4642448a5fd9a1cfdd999f142331d89450
1f8b82d08e7d1703ab14eaf510bcc4e18e373ab2ed502ebb99dc0035f393c4cbdea8
b40535e528017087ee700442539e7cf079950de91c0aa9f058c66e15a640eba39b4e
619c4daf6c08beaf654932f8f88ad8685e87402f75be68bf3dd2e5539a7d0ea880ec
89788c36dc3a6603eda6999f519eed0f62302ea92adc13d52bf7898eb1ab1aa587bf
8f278059ede7c75204d3d69f67b00b50cd70a8724eb2a204c275981af92a4ae21b77
d9ca8be275fb4a1edbba3edcae4a0f964ca913326a9507c4c6647adc948782136036
f73cbfba33e1b5977591931b99ce536015bfb89c062c3208189bdc43e5306cdaefa8
1a769df267d00233e375e5b0b027974fda218f318c7cd7c1fdbfe8548fb271f3b14d
e9a50d7bb23e26feb3cc1ea8828601010002561fd25f64a2ee33e774abe16700bcfd
9cf12ea5f7d8414447abdef0ff