Delay-Tolerant Networking B. Sipos Internet-Draft JHU/APL Updates: 9172 (if approved) 21 November 2025 Intended status: Standards Track Expires: 25 May 2026 Bundle Protocol Security (BPSec) COSE Context draft-ietf-dtn-bpsec-cose-13 Abstract This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Sipos Expires 25 May 2026 [Page 1] Internet-Draft BPSec COSE November 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 4 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 5 2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 6 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Additional Header Maps . . . . . . . . . . . . . . . 9 2.2.2. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 12 2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 13 2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 14 2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 14 2.5.1. Generating External AAD . . . . . . . . . . . . . . . 14 2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 17 2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 17 2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 17 2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 18 3. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 20 3.2.1. Hashing Algorithms . . . . . . . . . . . . . . . . . 20 3.2.2. Symmetric Algorithms . . . . . . . . . . . . . . . . 21 3.2.3. ECC Algorithms . . . . . . . . . . . . . . . . . . . 22 3.2.4. RSA Algorithms . . . . . . . . . . . . . . . . . . . 24 3.3. Needed Header Parameters . . . . . . . . . . . . . . . . 25 3.4. Symmetric Keys and Identifiers . . . . . . . . . . . . . 27 3.5. Asymmetric Key Types and Identifiers . . . . . . . . . . 27 3.6. Policy Recommendations . . . . . . . . . . . . . . . . . 28 4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 29 4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 31 5.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 31 5.3. Threat: Certificate Validation Vulnerabilities . . . . . 32 5.4. Threat: Security Source Impersonation . . . . . . . . . . 32 5.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 33 5.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 33 5.7. Threat: Passive Leak of Key Material . . . . . . . . . . 33 5.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 34 5.9. Inherited Security Considerations . . . . . . . . . . . . 34 5.10. AAD-Covered Block Modification . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6.1. Bundle Protocol . . . . . . . . . . . . . . . . . . . . . 35 Sipos Expires 25 May 2026 [Page 2] Internet-Draft BPSec COSE November 2025 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 7.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Example Security Operations . . . . . . . . . . . . 40 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 42 A.2. ECC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 44 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 45 A.4. Symmetric CEK COSE_Encrypt0 . . . . . . . . . . . . . . . 49 A.5. Symmetric Key COSE_Encrypt with Key Wrap . . . . . . . . 51 A.6. Symmetric Key COSE_Encrypt with HKDF . . . . . . . . . . 53 A.7. ECC Keypair COSE_Encrypt with Key Wrap . . . . . . . . . 55 A.8. ECC Keypair COSE_Encrypt with HKDF . . . . . . . . . . . 58 A.9. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 61 Appendix B. Example Public Key Certificates . . . . . . . . . . 65 B.1. Root CA Certificate . . . . . . . . . . . . . . . . . . . 65 B.2. Signing Source End-Entity Certificate . . . . . . . . . . 67 B.3. Encryption Recipient End-Entity Certificate . . . . . . . 69 Appendix C. CDDL Definitions for BPSec . . . . . . . . . . . . . 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 72 Implementation Status . . . . . . . . . . . . . . . . . . . . . . 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73 1. Introduction The Bundle Protocol Security (BPSec) Specification [RFC9172] defines structure and encoding for Block Integrity Block (BIB) and Block Confidentiality Block (BCB) types but does not specify any security contexts to be used by either of the security block types. The CBOR Object Signing and Encryption (COSE) specifications [RFC9052] and [RFC9053] defines a structure, encoding, and algorithms to use for cryptographic signing and encryption. This document describes how to use the algorithms and encodings of COSE within BPSec blocks to apply those algorithms to Bundle security in Section 2. A bare minimum of interoperability algorithms and algorithm parameters is specified by this document in Section 3. The focus of the recommended algorithms is to allow BPSec to be used in a Public Key Infrastructure (PKI) as described in Section 1.2 using a certificate profile defined in Section 4. Examples of specific security operations are provided in Appendix A to aid in implementation support of the interoperability algorithms of Section 3.2. Examples of public key certificates are provided in Appendix B which are compatible with the profile in Section 4 and specific corresponding algorithms. Sipos Expires 25 May 2026 [Page 3] Internet-Draft BPSec COSE November 2025 1.1. Scope This document describes a profile of COSE which is tailored for use in BPSec and a method of including full COSE messages within BPSec security blocks. This document does not address: * Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network. * Uses of COSE beyond the profile defined in this document. * How those COSE algorithms are intended to be used within a larger security context. Many header parameters used by COSE (e.g., key identifiers) depend on the network environment and security policy related to that environment. 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. 1.3. Use of CDDL This document defines CBOR structure using the Concise Data Definition Language (CDDL) of [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression: '//sourcecode[@type="cddl"]' The following initial fragment defines the top-level rules of this document's CDDL, including the ASB data structure with its parameter/ result sockets and rules needed for validating the example CBOR content. Sipos Expires 25 May 2026 [Page 4] Internet-Draft BPSec COSE November 2025 start = bpsec-cose-asb / external_aad / primary-block / extension-block / MAC_structure / Sig_structure / Enc_structure / COSE_KeySet The definitions for the rules MAC_structure, Sig_structure, Enc_structure, and COSE_KeySet are taken from COSE [RFC9052]. The definition for the rule COSE_CertHash is taken from COSE X.509 [RFC9360]. The definitions for the rules eid, primary-block, and extension-block, block-control-flags, the socket $extension-block, and the generic rule extension-block-use are taken from BP [RFC9171]. The BPSec specification [RFC9172] did not define its extension blocks using CDDL, so a supplementary definition for BPSec is provided in Appendix C. 1.4. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. BPSec Security Context This document specifies a single security context for use in both BPSec integrity and confidentiality blocks. This is done to save code points allocated to this specification and to simplify the encoding of COSE-in-BPSec; the BPSec block type uniquely defines the acceptable parameters and COSE messages which can be present. The COSE security context SHALL have the Security Context ID specified in Section 6.1. Both types of security block can use the same parameters, defined in Section 2.2, to carry public key-related information and each type of security block allows specific COSE message results, defined in Section 2.3. ; Specialize the ASB for this context $ext-data-asb /= bpsec-cose-asb bpsec-cose-asb = bpsec-context-use< 3, ; Context ID COSE $bpsec-cose-param, $bpsec-cose-result > Figure 1: COSE context declaration CDDL Sipos Expires 25 May 2026 [Page 5] Internet-Draft BPSec COSE November 2025 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 additionally 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. Sipos Expires 25 May 2026 [Page 6] Internet-Draft BPSec COSE November 2025 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 Sipos Expires 25 May 2026 [Page 7] Internet-Draft BPSec COSE November 2025 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 of each parameter type per target block. +==============+========================+==================+ | Parameter ID | Parameter Structure | Reference | +==============+========================+==================+ | 3 | additional-protected | Section 2.2.1 of | | | | this document | +--------------+------------------------+------------------+ | 4 | additional-unprotected | Section 2.2.1 of | | | | this document | +--------------+------------------------+------------------+ | 5 | AAD-scope | Section 2.2.2 of | | | | this document | +--------------+------------------------+------------------+ Table 1: COSE Context 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). Sipos Expires 25 May 2026 [Page 8] Internet-Draft BPSec COSE November 2025 2.2.1. Additional Header Maps The two parameters Additional Protected and Additional Unprotected allow de-duplicating header items which are common to all COSE results. Both additional header values contain a CBOR map which is to be merged with each of the result's unprotected headers. Although the additional header items are all treated as unprotected from the perspective of the COSE message, the additional protected map is included within the external AAD (Section 2.5.1). The expected use of additional header map is to contain a certificate (chain) or identifier (see Section 3.5) which applies to all results in the same security block. 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 verifiers and acceptors SHALL treat a pair of additional header maps containing duplicated labels as invalid. No more than one of each Additional Protected and Additional Unprotected parameter SHALL be present in a single security block. Security verifiers and acceptors SHALL treat a security block with multiple instances of either additional header type as invalid. There is no well-defined behavior for a security acceptor to handle multiple Additional Protected parameters. Security sources SHOULD NOT include an additional header parameter which represents an empty map. Security verifiers and acceptors SHALL handle empty header map parameters, specifically the Additional Protected parameter because it is part of the external AAD. Security verifiers and acceptors SHALL treat the aggregate of both additional header maps as being present in the unprotected header map of the highest-layers of the COSE message of each result. For single-layer messages (_i.e._, COSE_Encrypt0, COSE_MAC0, and COSE_Sign1) the additional headers apply to the message itself (layer 0) and for other messages the additional headers apply to the final recipients. If the same header label is present in a additional header map and a COSE layer's headers the item in the result header SHALL take precedence (_i.e._, the additional header items are added only if they are not already present in a layer's header). Additional header maps SHALL NOT contain any private key material. The security parameters are all stored in the bundle as plaintext and are visible to any bundle handlers. Sipos Expires 25 May 2026 [Page 9] Internet-Draft BPSec COSE November 2025 $bpsec-cose-param /= [3, additional-protected] additional-protected = empty_or_serialized_map $bpsec-cose-param /= [4, additional-unprotected] additional-unprotected = empty_or_serialized_map Figure 2: Additional Headers CDDL 2.2.2. AAD Scope The AAD Scope parameter controls what data is included in the AAD for both integrity and confidentiality operations. The AAD Scope parameter SHALL be encoded as a CBOR map containing keys referencing bundle blocks (as uint or nint items) and values representing a collection of bit flags (as uint items) as defined below. Non-negative integer AAD Scope keys SHALL be interpreted as block numbers in the bundle containing the AAD Scope parameter. Negative integer AAD Scope keys SHALL be interpreted as special (non-block- number) identifiers according to the IANA registry defined in Section 6.1. That registry contains the following initial values from Table 2 as well as reserved blocks for experimental and private use. +=======+==========+=============================================+ | Value | Name | Description | +=======+==========+=============================================+ | -1 | Target | Include the target block of the security | | | block | operation associated with the AAD. | +-------+----------+---------------------------------------------+ | -2 | Security | Include the security block containing the | | | block | security operation associated with the AAD. | +-------+----------+---------------------------------------------+ Table 2: AAD Scope Special Keys Sipos Expires 25 May 2026 [Page 10] Internet-Draft BPSec COSE November 2025 AAD Scope values SHALL be interpreted as bit flags according to the IANA registry defined in Section 6.1 with initial values defined in Table 3. Any AAD Scope value bits SHALL NOT all be set to zero, which would represent the lack of presence in the AAD and serves no purpose. When the map key identifies the primary block (block number zero) the bits SHALL only have AAD-metadata set, as the primary block has no BTSD. When the map key identifies the containing security block the bits SHALL only have AAD-metadata set, as the security block BTSD does not yet exist. When the map key identifies the target block the bits SHALL only have AAD-metadata set, as the target block BTSD is already part of the security operation (integrity or confidentiality). All unassigned bits SHALL be set to zero (which will be elided by CBOR encoding) by security sources. All unassigned bits SHALL be ignored by security verifiers and acceptors. +==============+==============+==========================+ | Bit Position | Name | Description | | | | | | (from LSbit) | | | +==============+==============+==========================+ | 0 | AAD-metadata | If bit is set, indicates | | | | that the block metadata | | | | is included in the AAD. | +--------------+--------------+--------------------------+ | 1 | AAD-btsd | If bit is set, indicates | | | | that the BTSD is | | | | included in the AAD. | +--------------+--------------+--------------------------+ Table 3: AAD Scope Flags A CDDL representation of this definition is included in Figure 3 for reference. $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 Figure 3: AAD Scope CDDL Sipos Expires 25 May 2026 [Page 11] Internet-Draft BPSec COSE November 2025 The default value for this parameter (in Section 2.2) includes the primary, target, and security block metadata. 2.3. Results Although each COSE context result is a COSE message, 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. 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 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] Figure 4: COSE context results CDDL 2.3.1. Integrity Messages When used within a Block Integrity Block, the COSE context SHALL allow only the Result IDs from Table 4. Each integrity result value SHALL consist of the COSE message indicated by Table 4 in its non- tagged encoded form. Sipos Expires 25 May 2026 [Page 12] Internet-Draft BPSec COSE November 2025 +===========+====================+===========+ | Result ID | Result Structure | Reference | +===========+====================+===========+ | 97 | encoded COSE_Mac | [RFC9052] | +-----------+--------------------+-----------+ | 17 | encoded COSE_Mac0 | [RFC9052] | +-----------+--------------------+-----------+ | 98 | encoded COSE_Sign | [RFC9052] | +-----------+--------------------+-----------+ | 18 | encoded COSE_Sign1 | [RFC9052] | +-----------+--------------------+-----------+ Table 4: COSE Integrity Results Each integrity result SHALL use the "detached" payload form with null payload value. The integrity result for COSE_Mac and COSE_Mac0 messages are computed by the procedure in Section 6.3 of [RFC9052]. The integrity result for COSE_Sign and COSE_Sign1 messages are computed by the procedure in Section 4.4 of [RFC9052]. The COSE "protected attributes from the application" used for a signature or MAC result SHALL be the encoded data defined in Section 2.5.1. The COSE payload used for a signature or MAC result SHALL be one of the following: the encoded form of the primary block if the target is the primary block (block number zero), or the BTSD content of the target if the target is not the primary block (block number non-zero). 2.3.2. Confidentiality Messages When used within a Block Confidentiality Block, COSE context SHALL allow only the Result IDs from Table 5. Each confidentiality result value SHALL consist of the COSE message indicated by Table 5 in its non-tagged encoded form. +===========+=======================+===========+ | Result ID | Result Structure | Reference | +===========+=======================+===========+ | 96 | encoded COSE_Encrypt | [RFC9052] | +-----------+-----------------------+-----------+ | 16 | encoded COSE_Encrypt0 | [RFC9052] | +-----------+-----------------------+-----------+ Table 5: COSE Confidentiality Results Only algorithms which support Authenticated Encryption with Authenticated Data (AEAD) SHALL be usable in the first (content) layer of a confidentiality result. Because COSE encryption with AEAD Sipos Expires 25 May 2026 [Page 13] Internet-Draft BPSec COSE November 2025 appends the authentication tag with the ciphertext, the size of the BTSD will grow after an encryption operation. Security verifiers and acceptors SHALL NOT assume that the size of the plaintext is the same as the size of the ciphertext. Each confidentiality result SHALL use the "detached" payload form with null payload value. The confidentiality result for COSE_Encrypt and COSE_Encrypt0 messages are computed by the procedure in Section 5.3 of [RFC9052]. The COSE "protected attributes from the application" used for an encryption result SHALL be the encoded data defined in Section 2.5.1. The COSE payload used for an encryption result SHALL be the BTSD content of the target. Because confidentiality of the primary block is disallowed by BPSec, there is no logic here for handling a BCB with a target on the primary block. 2.4. Key Considerations This specification does not impose any additional key requirements beyond those already specified for each COSE algorithm required in Section 3. It is expected, but not required, that keys referenced and used by COSE messages in this context will themselves be managed as COSE Key objects as defined in Section 7 of [RFC9052]. Using native COSE Key objects simplifies the work of an implementation to align with the key and credential identifiers contained in COSE header parameters. 2.5. Canonicalization Algorithms Generating or processing COSE messages for the COSE context follows the profile defined in Section 3 with the "protected attributes from the application" (_i.e._, the external AAD) generated as defined in Section 2.5.1 and the detached payload being the BTSD content from the target block as defined in Section 2.5.2. 2.5.1. Generating External AAD The COSE external AAD content defined in this section are used for both integrity and confidentiality messages. The encoding of this content is different from AAD of Section 4.7.2 of [RFC9173] and the front items of IPPT of Section 3.7 of [RFC9173] due to support for AAD scope (Section 2.2.2) covering the ASB security source field and covering an arbitrary number of blocks in the same bundle. Sipos Expires 25 May 2026 [Page 14] Internet-Draft BPSec COSE November 2025 If the AAD Scope map contains any key which is a positive integer (block number) referencing a block which does not exist in the current bundle or any key which is a negative integer (special key) not supported by the processing entity the generation of the AAD SHALL be considered failed. This external AAD SHALL be encoded in accordance with the core deterministic encoding requirements of Section 4.2.1 of [RFC8949]. The external AAD content SHALL consist of an encoded CBOR sequence, generated by concatenating the following byte string parts: 1. The first part SHALL be the encoded Security Source EID associated with the ASB containing this security operation. This is a CBOR array of length 2 in accordance with Section 4.2.5.1 of [RFC9171]. 2. The second part SHALL be the encoded AAD Scope value itself. This is a CBOR map in accordance with Section 2.2.2. Because of deterministic encoding, the negative keys will occur after positive keys. 3. For each entry of the AAD Scope map, in ascending block number order followed by the negative special keys in descending order, the next items SHALL be one or both of the following: a. If the map value has the AAD-metadata flag set, the next part is block metadata taken from either: * If the map key is block number zero, the next part SHALL be the encoded form of the primary block of the containing bundle. This is the full primary block, including its definite-length array head. This part will be identical to the encoded primary block from the containing bundle if that primary block conforms to encoding requirements of Section 4.3.1 of [RFC9171]. * Otherwise, next part SHALL be the encoded form of the first three fields of the block (_i.e._, the block type code, block number, and control flags) identified by the block number in the map key. This is just the three encoded CBOR unsigned integer fields concatenated with no framing (array or otherwise). Sipos Expires 25 May 2026 [Page 15] Internet-Draft BPSec COSE November 2025 b. If the map value has the AAD-btsd flag set and the map key is _not_ block number zero, the next part SHALL be the re- encoded BTSD of the block identified by the block number in the map key. This is a definite-length CBOR byte string. This part will be identical to the encoded BTSD item from the target block itself if that target block conforms to encoding requirements of Section 4.3.2 of [RFC9171]. 4. The last part SHALL be the encoded form of the Additional Protected parameter (Section 2.2.1). This is a definite-length CBOR byte string. This has a default value of an empty string, defined in Section 2.2. Be aware that, because of deterministic encoding requirements here, there is no guarantee that AAD parts containing the same CBOR data as the ASB or containing bundle (_e.g._, the Security Source field), result in the same encoded byte string. When generated by the same entity they are expected to be the same, but an entity verifying or accepting a security operation SHALL treat bundle and block contents as untrusted input and re-encode the AAD parts. A CDDL representation of this data is shown below in Figure 5. ; Specialized here to contain a specific sequence external_aad /= bstr .cborseq AAD-list AAD-list = [ security-source: eid, AAD-scope, *AAD-block, ; copy of additional-protected (or default empty bstr) additional-protected ] ; each AAD item is a group, not a sub-array AAD-block = ( ? primary-block, ; present for block number zero ? block-metadata, ; present if AAD-metadata flag set ? bstr, ; present if AAD-btsd flag set ) ; Selected fields of a canonical block block-metadata = ( block-type-code: uint, block-number: uint, block-control-flags, ) Figure 5: COSE context AAD CDDL Sipos Expires 25 May 2026 [Page 16] Internet-Draft BPSec COSE November 2025 2.5.2. Payload Data When correlating between BPSec target BTSD and COSE plaintext or payload, any byte string SHALL be handled in its decoded CBOR item form. This means the CBOR head in an encoded form is ignored for the purposes of security processing; only the BTSD content bytes are significant. This also means that if the target BTSD was encoded in a non-conforming way, for example in indefinite-length form or with a non-minimum-size length, the security processing always treats it in a deterministically encoded CBOR form. 2.6. Processing This section describes block-level requirements for handling COSE security data. All security results generated for BIB or BCB blocks SHALL conform to the COSE profile of Section 3 with header augmentation as defined in Section 2.2.1. 2.6.1. Node Authentication This section explains how the certificate profile of Section 4 is used by a security acceptor to both validate an end-entity certificate and to use that certificate to authenticate the security source for an integrity result. For a confidentiality result, some of the requirements in this section are implicit in an implementation using a private key associated with a certificate used by a result recipient. It is an implementation matter to ensure that a BP agent is configured to generate or receive results associated with valid certificates. A security source MAY prohibit generating a result (either integrity or confidentiality) for an end-entity certificate which is not considered valid according to Section 2.6.1.2. Generating a result which is likely to be discarded is wasteful of bundle size and transport resources. 2.6.1.1. Certificate Identification Because of the standard policy of using separate certificates for transport, signing, and encryption (see Section 4.1) a single Node ID is likely to be associated with multiple certificates, and any or all of those certificates MAY be present within an "x5bag" in an Additional Protected parameter (see Section 2.2.1). When present, a security verifier or acceptor SHALL use an "x5chain" or "x5t" to identify an end-entity certificate to use for result processing. Security verifiers and acceptors SHALL NOT assume that a validated Sipos Expires 25 May 2026 [Page 17] Internet-Draft BPSec COSE November 2025 certificate containing a NODE-ID matching a security source is enough to associate a certificate with a COSE message or recipient (see Section 3.5). 2.6.1.2. Certificate Validation For each end-entity certificate contained in or identified by by a COSE result, a security verifier or acceptor SHALL perform the certification path validation of Section 6 of [RFC5280] up to one of the acceptor's trusted CA certificates. When evaluating a certificate Validity time interval, a security verifier or acceptor SHALL use the Bundle Creation Time of the primary block as the reference instead of the current time. If enabled by local policy, the entity SHALL perform an OCSP check of each certificate providing OCSP authority information in accordance with [RFC6960]. If certificate validation fails or if security policy disallows a certificate for any reason, the acceptor SHALL treat the associated security result as failed. Leaving out part of the certification chain can cause the entity to fail to validate a certificate if the left-out certificates are unknown to the entity (see Section 5.2). For each end-entity certificate contained in or identified by a COSE context result, a security verifier or acceptor SHALL apply security policy to the Key Usage extension (if present) and Extended Key Usage extension (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the profile in Section 4. 2.6.1.3. Node ID Authentication If required by security policy, for each end-entity certificate referenced by a COSE context integrity result a security verifier or acceptor SHALL validate the certificate NODE-ID in accordance with Section 6 of [RFC6125] using the NODE-ID reference identifier from the Security Source of the containing security block. If the NODE-ID validation result is Failure or if the result is Absent and security policy requires an authenticated Node ID, a security verifier or acceptor SHALL treat the result as failed. 2.6.2. Policy Recommendations A RECOMMENDED security policy is to enable the use of OCSP checking when internet connectivity is present. A RECOMMENDED security policy is that if an Extended Key Usage is present that it needs to contain id-kp-bundleSecurity of [IANA-SMI] to be usable as an end-entity certificate for COSE security results. A RECOMMENDED security policy is to require a validated Node ID (of Section 2.6.1.3) and to ignore any other identifiers in the end-entity certificate. Sipos Expires 25 May 2026 [Page 18] Internet-Draft BPSec COSE November 2025 This policy relies on and informs the certificate requirements in Section 3.6 and Section 4. This policy assumes that a DTN-aware CA (see Section 1.2) will only issue a certificate for a Node ID when it has verified that the private key holder actually controls the DTN node; this is needed to avoid the threat identified in Section 5.4. This policy requires that a certificate contain a NODE-ID and allows the certificate to also contain network-level identifiers. A tailored policy on a more controlled network could relax the requirement on Node ID validation and/or Extended Key Usage presence. 3. COSE Profile This section contains requirements which apply to the use of COSE within the BPSec security context defined in this document. Other variations of COSE within BPSec can be used but are not expected to be interoperable or usable by all security verifiers and acceptors. 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. Sipos Expires 25 May 2026 [Page 19] Internet-Draft BPSec COSE November 2025 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.2.1. Hashing Algorithms Implementations conforming to this specification SHALL support the non-keyed hash algorithms in Table 6 if they will operate with public key certificates. +=============+======+==================+ | Name | Code | Conformance | +=============+======+==================+ | SHA-256/64 | -15 | | +-------------+------+------------------+ | SHA-256 | -16 | | +-------------+------+------------------+ | SHA-512/256 | -17 | | +-------------+------+------------------+ | SHA-384 | -43 | CNSA 1.0 and 2.0 | +-------------+------+------------------+ | SHA-512 | -44 | CNSA 2.0 | +-------------+------+------------------+ Table 6: Hash Algorithms Sipos Expires 25 May 2026 [Page 20] Internet-Draft BPSec COSE November 2025 These algorithms are currently used in the COSE_CertHash of "x5t" header parameters, which are expected to be included as unprotected (see Section 3.5). The truncated algorithms are useful for certificate filtering using shorter thumbprints, so are included here even though they fall below the CNSA 1.0 minimum strength for protecting data. 3.2.2. Symmetric Algorithms Implementations conforming to this specification SHALL support the symmetric keyed algorithms in Table 7. | The symmetric keyed algorithms here are not a super-set of | those available in [RFC9173], this list includes only those | which are CNSA 1.0 or 2.0 conformant. The "direct" algorithm is really just a recipient placeholder to allow using a content encryption key (CEK) identifier in a that COSE layer, so has no cryptographic function or effect on security strength. +=================+=======+=====================+====+=============+ | BPSec Block | COSE | Name |Code| Conformance | | | Layer | | | | +=================+=======+=====================+====+=============+ | Integrity | 0 | HMAC 384/384 |6 | CNSA 1.0 | | | | | | and 2.0 | +-----------------+-------+---------------------+----+-------------+ | Integrity | 0 | HMAC 512/512 |7 | CNSA 2.0 | +-----------------+-------+---------------------+----+-------------+ | Confidentiality | 0 | A256GCM |3 | CNSA 1.0 | | | | | | and 2.0 | +-----------------+-------+---------------------+----+-------------+ | Integrity or | 1 | A256KW |-5 | CNSA 1.0 | | Confidentiality | | | | and 2.0 | +-----------------+-------+---------------------+----+-------------+ | Integrity or | 1 | direct |-6 | _N/A_ | | Confidentiality | | | | | +-----------------+-------+---------------------+----+-------------+ | Integrity or | 1 | direct+HKDF-SHA-512 |-11 | CNSA 1.0 | | Confidentiality | | | | and 2.0 | +-----------------+-------+---------------------+----+-------------+ Table 7: Symmetric Algorithms Sipos Expires 25 May 2026 [Page 21] Internet-Draft BPSec COSE November 2025 When generating a BIB result from a symmetric key, implementations SHALL use a COSE_Mac or COSE_Mac0 using the private key directly. When a COSE_Mac or COSE_Mac0 is used with a direct key, the top-layer headers SHALL include a key identifier (see Section 3.4). The key length used for HMAC algorithms SHALL be equal to the hash function output length. This is consistent with COSE requirements on derived keys for HMAC but more strict to apply to all keys used for HMAC. When generating a BCB result from a symmetric CEK, implementations SHOULD use COSE_Encrypt or COSE_Encrypt0 with direct CEK. Session CEKs SHALL be managed to avoid overuse and the vulnerabilities associated with large amount of ciphertext from the same key. When generating a BCB result from a symmetric key-encryption key (KEK), implementations SHOULD use a COSE_Encrypt message with a recipient containing an indirect (wrapped or derived) CEK. When a COSE_Encrypt is used with an overall KEK, the recipient layer SHALL include a key identifier for the KEK. When a COSE_Encrypt is used with a symmetric KEK and a single recipient, the direct HKDF algorithms (code -10 and -11) are RECOMMENDED over the key wrapped algorithms (code -3 through -5) to reduce message size and the need for symmetric key generation. When processing a COSE_Encrypt with a symmetric KEK, a security verifier or acceptor SHALL process all KDF context data from the recipient headers in accordance with Section 5.2 of [RFC9053] even though the source is not required to provide any of those parameters. 3.2.3. ECC Algorithms Implementations conforming to this specification SHALL support the ECC algorithms in Table 8 if they will operate with ECC key material using NIST curves. | The ECC-based algorithms are CNSA 1.0 conformant [CNSA1] only | when used with a key having curve P-384. | | The current ECC-based algorithms using AES key wrap (code -29 | through -34) use HKDF with SHA-256, so do not conform to CNSA | 1.0. Sipos Expires 25 May 2026 [Page 22] Internet-Draft BPSec COSE November 2025 +=================+============+===========+======+=============+ | BPSec Block | COSE Layer | Name | Code | Conformance | +=================+============+===========+======+=============+ | Integrity | 0 or 1 | ESP384 | -51 | CNSA 1.0 | +-----------------+------------+-----------+------+-------------+ | Integrity | 0 or 1 | ESP512 | -52 | | +-----------------+------------+-----------+------+-------------+ | Confidentiality | 1 | ECDH-ES + | -26 | CNSA 1.0 | | | | HKDF-512 | | | +-----------------+------------+-----------+------+-------------+ | Confidentiality | 1 | ECDH-SS + | -28 | CNSA 1.0 | | | | HKDF-512 | | | +-----------------+------------+-----------+------+-------------+ | Confidentiality | 1 | ECDH-ES + | -31 | | | | | A256KW | | | +-----------------+------------+-----------+------+-------------+ | Confidentiality | 1 | ECDH-SS + | -34 | | | | | A256KW | | | +-----------------+------------+-----------+------+-------------+ Table 8: ECC Algorithms When generating a BIB result from an ECC private key, implementations SHALL use a COSE_Sign or COSE_Sign1 using the private key directly. When a COSE_Sign or COSE_Sign1 is used with an ECC private key, the top-layer headers SHALL include a corresponding public key identifier (see Section 3.5). When generating a BCB result from an ECC public key, implementations SHALL use a COSE_Encrypt message with a recipient containing an indirect (wrapped or derived) CEK. When a COSE_Encrypt is used with an ECC public key, the recipient layer SHALL include a public key identifier (see Section 3.5). When a COSE_Encrypt is used with an ECC public key, the security source SHALL either generate an ephemeral ECC keypair or choose a unique HKDF "salt" for each security operation. When a COSE_Encrypt is used with an ECC public key and a single recipient, the direct HKDF algorithms (code -25 through -28) are RECOMMENDED over the key wrapped algorithms (code -29 through -34) to reduce message size and the need for symmetric key generation. When processing a COSE_Encrypt with an ECC public key, a security verifier or acceptor SHALL process all KDF context data from the recipient headers in accordance with Section 5.2 of [RFC9053] even though the source is not required to provide any of those parameters. Sipos Expires 25 May 2026 [Page 23] Internet-Draft BPSec COSE November 2025 The choice of whether to use ECDH in static-static (SS) or ephemeral- static (EH) mode depends on what security properties are needed for the operation. ECDH-SS can reduce message size and allows key generation to happen outside of the source entity, but also requires the ECC public key to either be known by the recipient(s) and identified by or be fully transmitted by a header parameter (as discussed in Section 6.3.1 of [RFC9053]). ECDH-ES can provide forward secrecy by using the ephemeral key only for single messages, but also requires the source to generate a new key when needed. 3.2.4. RSA Algorithms Implementations conforming to this specification SHALL support the RSA algorithms in Table 9 if they will operate with RSA key material. | The RSA-based algorithms are CNSA 1.0 conformant [CNSA1] only | when used with a key modulus of 3072 bits or larger. +=================+============+============+======+=============+ | BPSec Block | COSE Layer | Name | Code | Conformance | +=================+============+============+======+=============+ | Integrity | 0 or 1 | PS384 | -38 | CNSA 1.0 | +-----------------+------------+------------+------+-------------+ | Integrity | 0 or 1 | PS512 | -39 | | +-----------------+------------+------------+------+-------------+ | Confidentiality | 1 | RSAES-OAEP | -42 | CNSA 1.0 | | | | w/ SHA-512 | | | +-----------------+------------+------------+------+-------------+ Table 9: RSA Algorithms When generating a BIB result from an RSA keypair, implementations SHALL use a COSE_Sign or COSE_Sign1 using the private key directly. When a COSE_Sign or COSE_Sign1 is used with an RSA keypair, the top- layer headers SHALL include a public key identifier (see Section 3.5). When a COSE signature is generated with an RSA keypair, the signature uses a PSS salt in accordance with Section 2 of [RFC8230]. When generating a BCB result from an RSA public key, implementations SHALL use a COSE_Encrypt message with a recipient containing a key- wrapped CEK. When a COSE_Encrypt is used with an RSA public key, the recipient layer SHALL include a public key identifier (see Section 3.5). Sipos Expires 25 May 2026 [Page 24] Internet-Draft BPSec COSE November 2025 3.3. Needed Header Parameters The set of COSE header parameters needed for interoperability is listed in this section. The full set of COSE header parameters available is managed at [IANA-COSE]. Implementations conforming to this specification SHALL support the header parameters in Table 10. This support means required-to- implement not required-to-use for any particular COSE message. Specific COSE algorithms have their own requirements about which header parameters are mandatory or optional to use in the associated COSE message layer. The phrasing in Table 10 uses the term "required" where the parameter needs to be understood by all message processors, "optional" where the need for a parameter is determined by the specific end use, and "conditional" for cases where one parameter of several options is needed by this profile. For example, a choice of specific symmetric key identifier (Section 3.4) or asymmetric key identifier (Section 3.5) is conditional and chosen by the source. Sipos Expires 25 May 2026 [Page 25] Internet-Draft BPSec COSE November 2025 +================+=======+===================================+ | Name | Label | Need | +================+=======+===================================+ | alg | 1 | Required for COSE [RFC9052] | +----------------+-------+-----------------------------------+ | crit | 2 | Required for COSE [RFC9052] | +----------------+-------+-----------------------------------+ | content type | 3 | Optional for COSE [RFC9052] | +----------------+-------+-----------------------------------+ | kid | 4 | Conditional for this COSE profile | +----------------+-------+-----------------------------------+ | IV | 5 | Conditional for symmetric | | | | encryption algorithms | +----------------+-------+-----------------------------------+ | Partial IV | 6 | Conditional for symmetric | | | | encryption algorithms | +----------------+-------+-----------------------------------+ | kid context | 10 | Optional for this COSE profile | +----------------+-------+-----------------------------------+ | x5bag | 32 | Conditional for public key | | | | algorithms | +----------------+-------+-----------------------------------+ | x5chain | 33 | Conditional for public key | | | | algorithms | +----------------+-------+-----------------------------------+ | x5t | 34 | Conditional for public key | | | | algorithms | +----------------+-------+-----------------------------------+ | ephemeral key | -1 | Required for ECDH-ES algorithms | +----------------+-------+-----------------------------------+ | static key | -2 | Conditional for ECDH-SS | | | | algorithms | +----------------+-------+-----------------------------------+ | static key id | -3 | Conditional for ECDH-SS | | | | algorithms | +----------------+-------+-----------------------------------+ | salt | -20 | Required for ECDH-SS algorithms, | | | | optional for ECDH-ES | +----------------+-------+-----------------------------------+ | x5t-sender | -27 | Conditional for ECDH-SS | | | | algorithms | +----------------+-------+-----------------------------------+ | x5chain-sender | -29 | Conditional for ECDH-SS | | | | algorithms | +----------------+-------+-----------------------------------+ Table 10: Interoperability Header Parameters Sipos Expires 25 May 2026 [Page 26] Internet-Draft BPSec COSE November 2025 This profile of COSE does not use in-message KDF context information as defined in Section 5.2 of [RFC9053]. The context header parameters for PartyU (code -21 through -23) and PartyV (code -24 through -26) SHALL NOT be present in any COSE message within this security context. A side effect of this is that, to satisfy COSE requirements, the "salt" parameter SHALL always be present in a layer when an HKDF is used by the algorithm for that layer. 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. Sipos Expires 25 May 2026 [Page 27] Internet-Draft BPSec COSE November 2025 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"). Sipos Expires 25 May 2026 [Page 28] Internet-Draft BPSec COSE November 2025 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. PKIX Certificate Profile This section contains requirements on certificates used for the COSE context, while Section 3.5 contains requirements for how such certificates are transported or identified. The profile here mandates specific data to be present in CA and end-entity certificates but does not mandate any specific key types or signing algorithms to be used. Such details are left to algorithm-specific profiles such as [RFC8603] for CNSA 1.0. All end-entity X.509 certificates used for BPSec SHALL conform to [RFC5280], or any updates or successors to that profile. This profile requires Version 3 certificates due to the extensions used by this profile. Security verifiers and acceptors SHALL reject as invalid Version 1 and Version 2 end-entity certificates. Security verifiers and acceptors SHALL accept certificates that contain an empty Subject field or contain a Subject without a Common Name. Security verifiers and acceptors SHALL use the Subject Alternative Name extension for identity information in end-entity certificates. Sipos Expires 25 May 2026 [Page 29] Internet-Draft BPSec COSE November 2025 All BPSec end-entity certificates SHALL contain a Basic Constraints extension in accordance with Section 4.2.1.9 of [RFC5280] marked as critical. All BPSec end-entity certificates SHALL contain a Subject Alternative Name extension in accordance with Section 4.2.1.1 of [RFC5280] marked as critical. A BPSec end-entity certificate SHALL contain a NODE-ID in its Subject Alternative Name extension which authenticates the Node ID of the security source (for integrity) or a security verifier or acceptor (for confidentiality). The identifier type NODE-ID is defined in Section 4.4.1 of [RFC9174]. All BPSec CA certificates SHOULD contain both a Subject Key Identifier extension in accordance with Section 4.2.1.2 of [RFC5280] and an Authority Key Identifier extension in accordance with Section 4.2.1.1 of [RFC5280]. All BPSec end-entity certificates SHOULD contain an Authority Key Identifier extension in accordance with Section 4.2.1.1 of [RFC5280]. Security verifiers and acceptors SHOULD NOT rely on either a Subject Key Identifier and an Authority Key Identifier being present in any received certificate. Including key identifiers simplifies the work of an entity needing to assemble a certification chain. All BPSec CA certificates SHOULD contain an Extended Key Usage extension in accordance with Section 4.2.1.12 of [RFC5280]. When allowed by CA policy, a BPSec end-entity certificate SHALL contain an Extended Key Usage extension in accordance with Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage extension is present, it SHALL contain a key purpose id-kp-bundleSecurity of [IANA-SMI]. The id-kp-bundleSecurity purpose MAY be combined with other purposes in the same certificate. When allowed by CA policy, a BPSec end-entity certificate SHALL contain a Key Usage extension in accordance with Section 4.2.1.3 of [RFC5280] marked as critical. The PKIX Key Usage bits which are consistent with COSE security are: digitalSignature, nonRepudiation, keyEncipherment, and keyAgreement. The specific algorithms used by COSE messages in security results determine which of those key uses are exercised. See Section 4.1 for discussion of key use policies across multiple certificates. A BPSec end-entity certificate MAY contain an Online Certificate Status Protocol (OCSP) URI within an Authority Information Access extension in accordance with Section 4.2.2.1 of [RFC5280]. Security verifiers and acceptors are not expected to have continuous internet connectivity sufficient to perform OCSP verification. Sipos Expires 25 May 2026 [Page 30] Internet-Draft BPSec COSE November 2025 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. Security Considerations This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552]. 5.1. Threat: BPSec Block Replay The bundle's primary block contains fields which uniquely identify a bundle: the Source Node ID, Creation Timestamp, and fragment parameters (see Section 4.3.1 of [RFC9171]). These same fields are used to correlate Administrative Records with the bundles for which the records were generated. Including the primary block in the AAD Scope for integrity and confidentiality (see Section 2.2.2) binds the verification of the secured block to its parent bundle and disallows replay of any block with its BIB or BCB. This profile of COSE limits the encryption algorithms to only AEAD in order to include the context of the encrypted data as AAD. If an agent mistakenly allows the use of non-AEAD encryption when decrypting and verifying a BCB, the possibility of block replay attack is present. 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. Sipos Expires 25 May 2026 [Page 31] Internet-Draft BPSec COSE November 2025 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.3. Threat: Certificate Validation Vulnerabilities Even when a security acceptor is operating properly an attacker can attempt to exploit vulnerabilities within certificate check algorithms or configuration to authenticate using an invalid certificate. An invalid certificate exploit could lead to higher- level security issues and/or denial of service to the Node ID being impersonated. There are many reasons, described in [RFC5280] and [RFC6125], why a certificate can fail to validate, including using the certificate outside of its validity time interval, using purposes for which it was not authorized, or using it after it has been revoked by its CA. Validating a certificate is a complex task and can require network connectivity outside of the primary BP convergence layer network path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The configuration and use of particular certificate validation methods are outside of the scope of this document. 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. Sipos Expires 25 May 2026 [Page 32] Internet-Draft BPSec COSE November 2025 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.7. Threat: Passive Leak of Key Material It is important that the key requirements of Section 2.2 apply only to public keys and PKIX certificates. Including non-public key material in ASB parameters will expose that material in the bundle data and over the bundle convergence layer during transport. Sipos Expires 25 May 2026 [Page 33] Internet-Draft BPSec COSE November 2025 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. 5.9. Inherited Security Considerations All of the security considerations of the underlying BPSec [RFC9172] apply to this security context. Because this security context uses whole COSE messages and inherits all COSE processing, all of the security considerations of [RFC9052] apply to this security context. When public key certificates are used, all of the security considerations of [RFC5280] and any other narrowing PKIX profile apply to this security context. 5.10. AAD-Covered Block Modification The AAD Scope parameter (Section 2.2.2) can be used to refer to any other block within the same bundle (by its unique block number) at the time the associated security operation is added to a bundle. Because of this, if any block within the AAD coverage is modified (by any node along the bundle's forwarding path) in a way which affects the generated AAD value (Section 2.5.1) it will cause verification or acceptance of the containing security operation to fail. One reason why such a modification would be made is that the other block has an expected lifetime shorter than the security operation. For example, a Previous Node block (Section 4.4.1 of [RFC9171]) is expected to be removed or replaced at each hop. The AAD Scope parameter SHALL NOT reference any other block with an expected lifetime shorter than the containing security operation. Another reason for a modification is that the other block is designed to be updated along the forwarding path. For example, a Hop Count block (Section 4.4.3 of [RFC9171]) is expected to be modified as the bundle is forwarded by each node. The AAD Scope parameter SHALL NOT reference any other block using the flag AAD-btsd (Table 3) if that other block is expected to be modified by intermediate nodes during the lifetime of the containing security operation. Sipos Expires 25 May 2026 [Page 34] Internet-Draft BPSec COSE November 2025 One reason for a block to be removed is if it has its block processing control flags (Section 4.2.4 of [RFC9171]) have the bit set indicating "Discard block if it can't be processed" and the block type or type-specific data cannot be handled by any node along the forwarding path. The AAD Scope parameter SHALL NOT reference any other block having block processing control flags with the bit set indicating "Discard block if it can't be processed" unless it is known that all possible receiving nodes can process the associated block type during the lifetime of the containing security operation. 6. IANA Considerations Registration procedures referred to in this section are defined in [RFC8126]. 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. +=======+=============+======================+ | Value | Description | Reference | +=======+=============+======================+ | 3 | COSE | [This specification] | +-------+-------------+----------------------+ Table 11: BPSec Security Context Identifiers 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). Sipos Expires 25 May 2026 [Page 35] Internet-Draft BPSec COSE November 2025 +==============+==================+======================+ | Value | Name | Reference | +==============+==================+======================+ | -1 | Target block | [This specification] | +--------------+------------------+----------------------+ | -2 | Security block | [This specification] | +--------------+------------------+----------------------+ | -3 to -238 | Unassigned | | +--------------+------------------+----------------------+ | -239 to -240 | Reserved for | [This specification] | | | Experimental Use | | +--------------+------------------+----------------------+ | -241 to -256 | Reserved for | [This specification] | | | Private Use | | +--------------+------------------+----------------------+ | -257 to | Reserved | | | -65536 | | | +--------------+------------------+----------------------+ Table 12: BPSec COSE AAD Scope Special Keys 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. +==============+==============+================+ | Bit Position | Name | Reference | | | | | | (from LSbit) | | | +==============+==============+================+ | 0 | AAD-metadata | [This | | | | specification] | +--------------+--------------+----------------+ | 1 | AAD-btsd | [This | | | | specification] | +--------------+--------------+----------------+ | 2-64 | Unassigned | | +--------------+--------------+----------------+ Table 13: BPSec COSE AAD Scope Flags 7. References Sipos Expires 25 May 2026 [Page 36] Internet-Draft BPSec COSE November 2025 7.1. Normative References [IANA-BUNDLE] IANA, "Bundle Protocol",