draft-ietf-dtn-bpsec-cose-03.txt		draft-ietf-dtn-bpsec-cose-04.txt
	Delay-Tolerant Networking B. Sipos		Delay-Tolerant Networking B. Sipos
	Internet-Draft JHU/APL		Internet-Draft JHU/APL
	Intended status: Standards Track 3 January 2024		Intended status: Standards Track 2 July 2024
	Expires: 6 July 2024		Expires: 3 January 2025
	DTN Bundle Protocol Security (BPSec) COSE Context		DTN Bundle Protocol Security (BPSec) COSE Context
	draft-ietf-dtn-bpsec-cose-03		draft-ietf-dtn-bpsec-cose-04
	Abstract		Abstract
	This document defines a security context suitable for using CBOR		This document defines a security context suitable for using CBOR
	Object Signing and Encryption (COSE) algorithms within Bundle		Object Signing and Encryption (COSE) algorithms within Bundle
	Protocol Security (BPSec) integrity and confidentiality blocks. A		Protocol Security (BPSec) integrity and confidentiality blocks. A
	profile for COSE, focused on asymmetric-keyed algorithms, and for		profile for COSE, focused on asymmetric-keyed algorithms, and for
	PKIX certificates are also defined for BPSec interoperation.		PKIX certificates are also defined for BPSec interoperation.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 6 July 2024.		This Internet-Draft will expire on 3 January 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4		1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4
	1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 5		2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 5
	2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5		2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2.1. Additional Header Maps . . . . . . . . . . . . . . . 7		2.2.1. Additional Header Maps . . . . . . . . . . . . . . . 7
	2.2.2. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 8		2.2.2. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 8
	2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 10		2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 10
	2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 11		2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 11
	2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 11		2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 12
	2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 12		2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 12
	2.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 12		2.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 12
	2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 13		2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 13
	2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 13		2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 13
	2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 14		2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 14
	2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 15		2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 15
	3. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 15		3. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 16		3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 16
	3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 16		3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 16
	3.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 18		3.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 19
	3.3.1. Policy Recommendations . . . . . . . . . . . . . . . 19		3.3.1. Policy Recommendations . . . . . . . . . . . . . . . 20
	4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 20		4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 20
	4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 21		4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 21
	5. Implementation Status . . . . . . . . . . . . . . . . . . . . 21		5. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 22		6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 22		6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 23
	6.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 23		6.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 23
	6.3. Threat: Certificate Validation Vulnerabilities . . . . . 23		6.3. Threat: Certificate Validation Vulnerabilities . . . . . 23
	6.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 23		6.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 24
	6.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 23		6.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 24
	6.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 24		6.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 24
	6.7. Threat: Passive Leak of Key Material . . . . . . . . . . 24		6.7. Threat: Passive Leak of Key Material . . . . . . . . . . 25
	6.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 24		6.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	7.1. BPSec Security Context Identifiers . . . . . . . . . . . 25		7.1. BPSec Security Context Identifiers . . . . . . . . . . . 25
	7.2. BPSec COSE AAD Scope Flags . . . . . . . . . . . . . . . 25		7.2. BPSec COSE AAD Scope Flags . . . . . . . . . . . . . . . 25
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8.1. Normative References . . . . . . . . . . . . . . . . . . 25		8.1. Normative References . . . . . . . . . . . . . . . . . . 26
	8.2. Informative References . . . . . . . . . . . . . . . . . 27		8.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
	A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 30		A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 31
	A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 32		A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 32
	A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 34		A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 34
	A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 37		A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 37
	A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 39		A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 39
	A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 42		A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 42
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	1.2. PKIX Environments and CA Policy		1.2. PKIX Environments and CA Policy
	This specification gives requirements about how to use PKIX		This specification gives requirements about how to use PKIX
	certificates issued by a Certificate Authority (CA), but does not		certificates issued by a Certificate Authority (CA), but does not
	define any mechanisms for how those certificates come to be.		define any mechanisms for how those certificates come to be.
	To support the PKIX uses defined in this document, the CA(s) issuing		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		certificates for BP nodes are aware of the end use of the
	certificate, have a mechanism for verifying ownership of a Node ID,		certificate, have a mechanism for verifying ownership of a Node ID,
	and are issuing certificates directly for that Node ID. BPSec		and are issuing certificates directly for that Node ID. BPSec
	security acceptors authenticate the Node ID of security sources when		security verifiers and acceptors authenticate the Node ID of security
	verifying integrity (see Section 2.6.1) using a public key provided		sources when verifying integrity (see Section 2.6.1) using a public
	by a PKIX certificate (see Section 2.6.1) following the certificate		key provided by a PKIX certificate (see Section 2.6.1) following the
	profile of Section 4.		certificate profile of Section 4.
	1.3. Use of CDDL		1.3. Use of CDDL
	This document defines CBOR structure using the Concise Data		This document defines CBOR structure using the Concise Data
	Definition Language (CDDL) of [RFC8610]. The entire CDDL structure		Definition Language (CDDL) of [RFC8610]. The entire CDDL structure
	can be extracted from the XML version of this document using the		can be extracted from the XML version of this document using the
	XPath expression:		XPath expression:
	'//sourcecode[@type="cddl"]'		'//sourcecode[@type="cddl"]'
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	The COSE security context SHALL have the Security Context ID		The COSE security context SHALL have the Security Context ID
	specified in Section 7.1.		specified in Section 7.1.
	Both types of security block can use the same parameters, defined in		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		Section 2.2, to carry public key-related information and each type of
	security block allows specific COSE message results, defined in		security block allows specific COSE message results, defined in
	Section 2.3.		Section 2.3.
	; Specialize the ASB for this context		; Specialize the ASB for this context
	bpsec-cose-asb = bpsec-context-use<		bpsec-cose-asb = bpsec-context-use<
	-1, ; Context ID TBD-COSE		-1, ; Context ID TBA-COSE
	$bpsec-cose-param,		$bpsec-cose-param,
	$bpsec-cose-result		$bpsec-cose-result
	>		>
	$ext-data-asb /= bpsec-cose-asb		$ext-data-asb /= bpsec-cose-asb
	Figure 1: COSE context declaration CDDL		Figure 1: COSE context declaration CDDL
	2.1. Security Scope		2.1. Security Scope
	The scope here refers to the set of information used by the security		The scope here refers to the set of information used by the security
	skipping to change at page 6, line 48 ¶		skipping to change at page 6, line 48 ¶
	+--------------+------------------------+------------------+		+--------------+------------------------+------------------+
	Table 1: COSE Context Parameters		Table 1: COSE Context Parameters
	When a parameter is not present and a default value is defined below,		When a parameter is not present and a default value is defined below,
	the security acceptor SHALL use that default value to process the		the security acceptor SHALL use that default value to process the
	target:		target:
	* The default additional-protected is '' (an empty byte string).		* The default additional-protected is '' (an empty byte string).
	* The default additional-unprotected is {} (an empty map).		* The default additional-unprotected is '' (an empty byte string).
	* The default AAD-scope is {0:0b1,-1:0b1,-2:0b1} (a map which		* The default AAD-scope is {0:0b1,-1:0b1,-2:0b1} (a map which
	indicates the AAD contains the metadata of the primary, security,		indicates the AAD contains the metadata of the primary, security,
	and target blocks).		and target blocks).
	2.2.1. Additional Header Maps		2.2.1. Additional Header Maps
	The two parameters Additional Protected and Additional Unprotected		The two parameters Additional Protected and Additional Unprotected
	allow de-duplicating header items which are common to all COSE		allow de-duplicating header items which are common to all COSE
	results. Both additional header values contain a CBOR map which is		results. Both additional header values contain a CBOR map which is
	to be merged with each of the result's unprotected headers. Although		to be merged with each of the result's unprotected headers. Although
	the additional header items are all treated as unprotected from the		the additional header items are all treated as unprotected from the
	perspective of the COSE message, the additional protected map is		perspective of the COSE message, the additional protected map is
	included within the external_aad (see Section 2.5.1). The expected		included within the external_aad (see Section 2.5.1). The expected
	use of additional header map is to contain a certificate (chain) or		use of additional header map is to contain a certificate (chain) or
	identifier (see Section 3.3) which applies to all results in the same		identifier (see Section 3.3) which applies to all results in the same
	security block.		security block.
	Following the same pattern as COSE, when both additional header maps		Following the same pattern as COSE, when both additional header maps
	are present in a single security block they SHALL not contain any		are present in a single security block they SHALL not contain any
	duplicated labels. Security acceptors SHALL treat a pair of		duplicated labels. Security verifiers and acceptors SHALL treat a
	additional header maps containing duplicated labels as invalid.		pair of additional header maps containing duplicated labels as
			invalid.
	No more than one of each Additional Protected and Additional		No more than one of each Additional Protected and Additional
	Unprotected parameter SHALL be present in a single security block.		Unprotected parameter SHALL be present in a single security block.
	Security acceptors SHALL treat a security block with multiple		Security verifiers and acceptors SHALL treat a security block with
	instances of either additional header type as invalid. There is no		multiple instances of either additional header type as invalid.
	well-defined behavior for a security acceptor to handle multiple		There is no well-defined behavior for a security acceptor to handle
	Additional Protected parameters.		multiple Additional Protected parameters.
	Security sources SHOULD NOT include an additional header parameter		Security sources SHOULD NOT include an additional header parameter
	which represents an empty map. Security acceptors SHALL handle empty		which represents an empty map. Security verifiers and acceptors
	header map parameters, specifically the Additional Protected		SHALL handle empty header map parameters, specifically the Additional
	parameter because it is part of the external_aad.		Protected parameter because it is part of the external_aad.
	Security acceptors SHALL treat the aggregate of both additional		Security verifiers and acceptors SHALL treat the aggregate of both
	header maps as being present in the unprotected header map of the		additional header maps as being present in the unprotected header map
	highest-layers of the COSE message of each result. For single-layer		of the highest-layers of the COSE message of each result. For
	messages (i.e., COSE_Encrypt0, COSE_MAC0, and COSE_Sign1) the		single-layer messages (i.e., COSE_Encrypt0, COSE_MAC0, and
	additional headers apply to the message itself (layer 0) and for		COSE_Sign1) the additional headers apply to the message itself (layer
	other messages the additional headers apply to the final recipients.		0) and for other messages the additional headers apply to the final
	If the same header label is present in a additional header map and a		recipients. If the same header label is present in a additional
	COSE layer's headers the item in the result header SHALL take		header map and a COSE layer's headers the item in the result header
	precedence (i.e., the additional header items are added only if they		SHALL take precedence (i.e., the additional header items are added
	are not already present in a layer's header).		only if they are not already present in a layer's header).
	Additional header maps SHALL NOT contain any private key material.		Additional header maps SHALL NOT contain any private key material.
	The security parameters are all stored in the bundle as plaintext and		The security parameters are all stored in the bundle as plaintext and
	are visible to any bundle handlers.		are visible to any bundle handlers.
	$bpsec-cose-param /= [3, additional-protected]		$bpsec-cose-param /= [3, additional-protected]
	additional-protected = empty_or_serialized_map		additional-protected = empty_or_serialized_map
	$bpsec-cose-param /= [4, additional-unprotected]		$bpsec-cose-param /= [4, additional-unprotected]
	additional-unprotected = header_map		additional-unprotected = empty_or_serialized_map
	Figure 2: Additional Headers CDDL		Figure 2: Additional Headers CDDL
	2.2.2. AAD Scope		2.2.2. AAD Scope
	The AAD Scope parameter controls what data is included in the AAD for		The AAD Scope parameter controls what data is included in the AAD for
	both integrity and confidentiality operations. The AAD Scope		both integrity and confidentiality operations. The AAD Scope
	parameter SHALL be encoded as a CBOR map containing keys referencing		parameter SHALL be encoded as a CBOR map containing keys referencing
	bundle blocks (as int items) and values representing a collection of		bundle blocks (as int items) and values representing a collection of
	bit flags (as uint items) defined in Table 2.		bit flags (as uint items) defined in Table 2.
	All non-negative AAD Scope keys SHALL correspond with block numbers		All non-negative AAD Scope keys SHALL correspond with block numbers
	in the bundle containing the AAD Scope parameter. Security acceptors		in the bundle containing the AAD Scope parameter. Security verifiers
	SHALL treat any AAD Scope with block numbers not actually present in		and acceptors SHALL treat any AAD Scope with block numbers not
	the containing bundle as invalid. The AAD Scope key -1 SHALL be		actually present in the containing bundle as invalid. The AAD Scope
	interpreted as corresponding to the target block of the security		key -1 SHALL be interpreted as corresponding to the target block of
	operation when the AAD is generated from the AAD Scope parameter.		the security operation when the AAD is generated from the AAD Scope
	The AAD Scope key -2 SHALL be interpreted as corresponding to the		parameter. The AAD Scope key -2 SHALL be interpreted as
	security block which contains the AAD Scope parameter.		corresponding to the security block which contains the AAD Scope
			parameter.
	+==============+==============+==========================+		+==============+==============+==========================+
	| Bit Position | Name | Description |		| Bit Position | Name | Description |
			| | | |
	| (from LSbit) | | |		| (from LSbit) | | |
	+==============+==============+==========================+		+==============+==============+==========================+
	| 0 | AAD-metadata | If bit is set, indicates |		| 0 | AAD-metadata | If bit is set, indicates |
	| | | that the block metadata |		| | | that the block metadata |
	| | | is included in the AAD. |		| | | is included in the AAD. |
	+--------------+--------------+--------------------------+		+--------------+--------------+--------------------------+
	| 1 | AAD-btsd | If bit is set, indicates |		| 1 | AAD-btsd | If bit is set, indicates |
	| | | that the BTSD is |		| | | that the BTSD is |
	| | | included in the AAD. |		| | | included in the AAD. |
	+--------------+--------------+--------------------------+		+--------------+--------------+--------------------------+
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 9 ¶
	represent the lack of presence in the AAD and serves no purpose.		represent the lack of presence in the AAD and serves no purpose.
	When the map key identifies the primary block (block number zero) the		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		bits SHALL only have AAD-metadata set, as the primary block has no
	BTSD. When the map key identifies the containing security block the		BTSD. When the map key identifies the containing security block the
	bits SHALL only have AAD-metadata set, as the security block BTSD		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		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		bits SHALL only have AAD-metadata set, as the target block BTSD is
	already part of the security operation (integrity or		already part of the security operation (integrity or
	confidentiality). All reserved bits SHALL be set to zero (which will		confidentiality). All reserved bits SHALL be set to zero (which will
	be elided by CBOR encoding) by security sources. All reserved bits		be elided by CBOR encoding) by security sources. All reserved bits
	SHALL be ignored by security acceptors.		SHALL be ignored by security verifiers and acceptors.
	A CDDL representation of this definition is included in Figure 3 for		A CDDL representation of this definition is included in Figure 3 for
	reference.		reference.
	$bpsec-cose-param /= [5, AAD-scope]		$bpsec-cose-param /= [5, AAD-scope]
	AAD-scope = {		AAD-scope = {
	*blk-id => (uint .bits AAD-scope-flags)		*blk-id => (uint .bits AAD-scope-flags)
	}		}
	blk-id = uint / blk-target / blk-sec		blk-id = uint / blk-target / blk-sec
	blk-target = -1		blk-target = -1
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 33 ¶
	+-----------+-----------------------+-----------+		+-----------+-----------------------+-----------+
	| 16 | encoded COSE_Encrypt0 | [RFC9052] |		| 16 | encoded COSE_Encrypt0 | [RFC9052] |
	+-----------+-----------------------+-----------+		+-----------+-----------------------+-----------+
	Table 4: COSE Confidentiality Results		Table 4: COSE Confidentiality Results
	Only algorithms which support Authenticated Encryption with		Only algorithms which support Authenticated Encryption with
	Authenticated Data (AEAD) SHALL be usable in the first (content)		Authenticated Data (AEAD) SHALL be usable in the first (content)
	layer of a confidentiality result. Because COSE encryption with AEAD		layer of a confidentiality result. Because COSE encryption with AEAD
	appends the authentication tag with the ciphertext, the size of the		appends the authentication tag with the ciphertext, the size of the
	BTSD will grow after an encryption operation. Security acceptors		BTSD will grow after an encryption operation. Security verifiers and
	MUST NOT assume that the size of the plaintext is the same as the		acceptors MUST NOT assume that the size of the plaintext is the same
	size of the ciphertext.		as the size of the ciphertext.
	Each confidentiality result SHALL use the "detached" payload form		Each confidentiality result SHALL use the "detached" payload form
	with null payload value. The confidentiality result for COSE_Encrypt		with null payload value. The confidentiality result for COSE_Encrypt
	and COSE_Encrypt0 messages are computed by the procedure in		and COSE_Encrypt0 messages are computed by the procedure in
	Section 5.3 of [RFC9052].		Section 5.3 of [RFC9052].
	The COSE "protected attributes from the application" used for an		The COSE "protected attributes from the application" used for an
	encryption result SHALL be the encoded data defined in Section 2.5.1.		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 of		The COSE payload used for an encryption result SHALL be the BTSD of
	the target. Because confidentiality of the primary block is		the target. Because confidentiality of the primary block is
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 34 ¶
	which is likely to be discarded is wasteful of bundle size and		which is likely to be discarded is wasteful of bundle size and
	transport resources.		transport resources.
	2.6.1.1. Certificate Identification		2.6.1.1. Certificate Identification
	Because of the standard policy of using separate certificates for		Because of the standard policy of using separate certificates for
	transport, signing, and encryption (see Section 4.1) a single Node ID		transport, signing, and encryption (see Section 4.1) a single Node ID
	is likely to be associated with multiple certificates, and any or all		is likely to be associated with multiple certificates, and any or all
	of those certificates MAY be present within an "x5bag" in an		of those certificates MAY be present within an "x5bag" in an
	Additional Protected parameter (see Section 2.2.1). When present, a		Additional Protected parameter (see Section 2.2.1). When present, a
	security acceptor SHALL use an "x5chain" or "x5t" to identify an end-		security verifier or acceptor SHALL use an "x5chain" or "x5t" to
	entity certificate to use for result processing. Security acceptors		identify an end-entity certificate to use for result processing.
	SHALL NOT assume that a validated certificate containing a NODE-ID		Security verifiers and acceptors SHALL NOT assume that a validated
	matching a security source is enough to associate a certificate with		certificate containing a NODE-ID matching a security source is enough
	a COSE message or recipient (see Section 3.3).		to associate a certificate with a COSE message or recipient (see
			Section 3.3).
	2.6.1.2. Certificate Validation		2.6.1.2. Certificate Validation
	For each end-entity certificate contained in or identified by by a		For each end-entity certificate contained in or identified by by a
	COSE result, the security acceptor SHALL perform the certification		COSE result, the security acceptor SHALL perform the certification
	path validation of Section 6 of [RFC5280] up to one of the acceptor's		path validation of Section 6 of [RFC5280] up to one of the acceptor's
	trusted CA certificates. When evaluating a certificate Validity		trusted CA certificates. When evaluating a certificate Validity
	period, the security acceptor SHALL use the bundle Creation Timestamp		period, the security acceptor SHALL use the bundle Creation Timestamp
	time (if not unknown) as the reference instead of the current time.		time (if not unknown) as the reference instead of the current time.
	If enabled by local policy, the entity SHALL perform an OCSP check of		If enabled by local policy, the entity SHALL perform an OCSP check of
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 51 ¶
	This policy requires that a certificate contain a NODE-ID and allows		This policy requires that a certificate contain a NODE-ID and allows
	the certificate to also contain network-level identifiers. A		the certificate to also contain network-level identifiers. A
	tailored policy on a more controlled network could relax the		tailored policy on a more controlled network could relax the
	requirement on Node ID validation and/or Extended Key Usage presence.		requirement on Node ID validation and/or Extended Key Usage presence.
	3. COSE Profile		3. COSE Profile
	This section contains requirements which apply to the use of COSE		This section contains requirements which apply to the use of COSE
	within the BPSec security context defined in this document. Other		within the BPSec security context defined in this document. Other
	variations of COSE within BPSec can be used but are not expected to		variations of COSE within BPSec can be used but are not expected to
	be interoperable or usable by all security acceptors.		be interoperable or usable by all security verifiers and acceptors.
	3.1. COSE Messages		3.1. COSE Messages
	When generating a BPSec result, security sources SHALL use only COSE		When generating a BPSec result, security sources SHALL use only COSE
	labels with a uint value. When processing a BPSec result, security		labels with a uint value. When processing a BPSec result, security
	acceptors MAY handle COSE labels with with a tstr value.		verifiers and acceptors MAY handle COSE labels with with a tstr
			value.
	When used in a BPSec result, each COSE message SHALL contain an		When used in a BPSec result, each COSE message SHALL contain an
	explicit algorithm identifier in the first (content) layers. When		explicit algorithm identifier in the first (content) layers. When
	available and not implied by the bundle source, a COSE message SHALL		available and not implied by the bundle source, a COSE message SHALL
	contain a key identifier in the last (recipient) layer. See		contain a key identifier in the last (recipient) layer. See
	Section 3.3 for specifics about asymmetric key identifiers. When a		Section 3.3 for specifics about asymmetric key identifiers. When a
	key identifier is not available, BPSec acceptors SHALL use the		key identifier is not available, BPSec acceptors SHALL use the
	Security Source (if available) and the Bundle Source to imply which		Security Source (if available) and the Bundle Source to imply which
	keys can be used for security operations. Using implied keys has an		keys can be used for security operations. Using implied keys has an
	interoperability risk, see Section 6.5 for details. A BPSec security		interoperability risk, see Section 6.5 for details. A BPSec security
	skipping to change at page 17, line 22 ¶		skipping to change at page 17, line 22 ¶
	| Integrity | 0 | ES256 | -7 | Recommended |		| Integrity | 0 | ES256 | -7 | Recommended |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Integrity | 0 | EdDSA | -8 | Recommended |		| Integrity | 0 | EdDSA | -8 | Recommended |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Integrity | 0 | PS256 | -37 | Recommended |		| Integrity | 0 | PS256 | -37 | Recommended |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Confidentiality | 0 | A256GCM | 3 | Required |		| Confidentiality | 0 | A256GCM | 3 | Required |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Confidentiality | 1 | A256KW | -5 | Required |		| Confidentiality | 1 | A256KW | -5 | Required |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
			| Confidentiality | 1 | direct | -6 | Recommended |
			| | | | | with caveats |
			+-----------------+------------+------------+------+----------------+
			| Confidentiality | 1 | ECDH-ES + | -25 | Recommended |
			| | | HKDF-256 | | |
			+-----------------+------------+------------+------+----------------+
			| Confidentiality | 1 | ECDH-SS + | -27 | Recommended |
			| | | HKDF-256 | | |
			+-----------------+------------+------------+------+----------------+
	| Confidentiality | 1 | ECDH-ES + | -31 | Recommended |		| Confidentiality | 1 | ECDH-ES + | -31 | Recommended |
	| | | A256KW | | |		| | | A256KW | | |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Confidentiality | 1 | ECDH-SS + | -34 | Recommended |		| Confidentiality | 1 | ECDH-SS + | -34 | Recommended |
	| | | A256KW | | |		| | | A256KW | | |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	| Confidentiality | 1 | RSAES-OAEP | -41 | Recommended |		| Confidentiality | 1 | RSAES-OAEP | -41 | Recommended |
	| | | w/ SHA-256 | | |		| | | w/ SHA-256 | | |
	+-----------------+------------+------------+------+----------------+		+-----------------+------------+------------+------+----------------+
	Table 5: Interoperability Algorithms		Table 5: Interoperability Algorithms
	The following are recommended key and recipient uses within COSE/		The following are recommended key and recipient uses within COSE/
	BPSec:		BPSec:
	Symmetric Key Integrity: When generating a BIB result from a		Symmetric Key Integrity:
	symmetric key, implementations SHALL use a COSE_Mac0 using the		When generating a BIB result from a symmetric key, implementations
	private key directly. When a COSE_Mac0 is used with a direct key,		SHALL use a COSE_Mac0 using the private key directly. When a
	the headers SHALL include a key identifier ("kid" header and		COSE_Mac0 is used with a direct key, the headers SHALL include a
	possibly "kid context" header).		key identifier ("kid" header and possibly "kid context" header).
	EC Keypair Integrity: When generating a BIB result from an EC		EC Keypair Integrity:
	keypair, implementations SHALL use a COSE_Sign1 using the private		When generating a BIB result from an EC keypair, implementations
	key directly. When a COSE_Sign1 is used with an EC keypair, the		SHALL use a COSE_Sign1 using the private key directly. When a
	headers SHALL include a public key identifier (see Section 3.3).		COSE_Sign1 is used with an EC keypair, the headers SHALL include a
			public key identifier (see Section 3.3).
	RSA Keypair Integrity: When generating a BIB result from an RSA		RSA Keypair Integrity:
	keypair, implementations SHALL use a COSE_Sign1 using the private		When generating a BIB result from an RSA keypair, implementations
	key directly. When a COSE_Sign1 is used with an RSA keypair, the		SHALL use a COSE_Sign1 using the private key directly. When a
	headers SHALL include a public key identifier (see Section 3.3).		COSE_Sign1 is used with an RSA keypair, the headers SHALL include
	When a COSE signature is generated with an RSA keypair, the		a public key identifier (see Section 3.3). When a COSE signature
	signature uses a PSS salt in accordance with Section 2 of		is generated with an RSA keypair, the signature uses a PSS salt in
	[RFC8230].		accordance with Section 2 of [RFC8230].
	Symmetric Key Confidentiality: When generating a BCB result from an		Symmetric Key Confidentiality:
	symmetric key, implementations SHALL use a COSE_Encrypt message		When generating a BCB result from a symmetric key-encryption key
	with a recipient containing an indirect (wrapped or derived)		(KEK), implementations SHOULD use a COSE_Encrypt message with a
	content encryption key (CEK). When generating a BCB result from a		recipient containing an indirect (wrapped or derived) content
	symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or		encryption key (CEK). When a COSE_Encrypt is used with an overall
	COSE_Encrypt with direct CEK. Doing so risks key overuse and the		KEK, the recipient layer SHALL include a key identifier for the
	vulnerabilities associated with large amount of ciphertext from		KEK.
	the same key. When a COSE_Encrypt is used with an overall key-
	encryption key (KEK), the recipient layer SHALL include a key
	identifier for the KEK.
	EC Keypair Confidentiality: When generating a BCB result from an EC		When generating a BCB result from a symmetric CEK, implementations
	public key, implementations SHALL use a COSE_Encrypt message with		SHOULD use COSE_Encrypt0 or COSE_Encrypt with direct CEK. Session
	a recipient containing an indirect (wrapped or derived) CEK. When		CEKs MUST be managed to avoid overuse and the vulnerabilities
	a COSE_Encrypt is used with an EC public key, the recipient layer		associated with large amount of ciphertext from the same key.
			EC Keypair Confidentiality:
			When generating a BCB result from an EC 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 EC public key, the recipient layer
	SHALL include a public key identifier (see Section 3.3). When a		SHALL include a public key identifier (see Section 3.3). When a
	COSE_Encrypt is used with an EC public key, the security source		COSE_Encrypt is used with an EC public key, the security source
	SHALL either generate an ephemeral EC keypair or choose a unique		SHALL either generate an ephemeral EC keypair or choose a unique
	"PartyU Nonce" for each security operation. When processing a		HKDF "salt" for each security operation. When a COSE_Encrypt is
	COSE_Encrypt with an EC public key, the security acceptor SHALL		used with an EC public key and a single recipient, the direct HKDF
	process all KDF and HMAC context data from the recipient headers		algorithms (code -25 and -27) are RECOMMENDED over the key wrapped
	in accordance with Section 5.2 of [RFC9053] even though the source		algorithms (code -31 and -34) to reduce message size. When
	is not required to provide any of those parameters.		processing a COSE_Encrypt with an EC public key, the security
			acceptor SHALL process all KDF and HMAC 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.
	RSA Keypair Confidentiality: When generating a BCB result from an		RSA Keypair Confidentiality:
	RSA public key, implementations SHALL use a COSE_Encrypt message		When generating a BCB result from an RSA public key,
	with a recipient containing a key-wrapped CEK. When a		implementations SHALL use a COSE_Encrypt message with a recipient
	COSE_Encrypt is used with an RSA public key, the recipient layer		containing a key-wrapped CEK. When a COSE_Encrypt is used with an
	SHALL include a public key identifier (see Section 3.3).		RSA public key, the recipient layer SHALL include a public key
			identifier (see Section 3.3).
			Implementations conforming to this specification SHALL support the
			hash algorithms SHA-256 (code -16) and SHA-256/64 (code -15) for use
			with the "x5t" identifier.
	3.3. Asymmetric Key Types and Identifiers		3.3. Asymmetric Key Types and Identifiers
	This section applies when a BIB uses a public key for verification or		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.		key-wrap, or when a BCB uses a public key for encryption or key-wrap.
	When using asymmetric keyed algorithms, the security source SHALL		When using asymmetric keyed algorithms, the security source SHALL
	include a public key container or public key identifier as a		include a public key container or public key identifier as a
	recipient header. The public key identifier SHALL be either an "x5t"		recipient header. The public key identifier SHALL be either an "x5t"
	or "x5chain" of [RFC9360], or "kid" of [RFC9052] and possibly "kid		or "x5chain" of [RFC9360], or "kid" of [RFC9052] and possibly "kid
	context" of [RFC8613], or an equivalent identifier.		context" of [RFC8613], or an equivalent identifier.
	When BIB result contains a "x5t" identifier, the security source MAY		When BIB result contains a "x5t" identifier, the security source MAY
	include an appropriate PKIX certificate container ("x5chain" or		include an appropriate PKIX certificate container ("x5chain" or
	"x5bag" of [RFC9360]) in a direct COSE header or an additional header		"x5bag" of [RFC9360]) in a direct COSE header or an additional header
	security parameter (see Section 2.2.1). When a BIB result contains		security parameter (see Section 2.2.1). When a BIB result contains
	an "x5chain", the security source SHOULD NOT also include an "x5t" as		an "x5chain", the security source SHOULD NOT also include an "x5t" as
	the first certificate in the chain is implicitly the applicable end-		the first certificate in the chain is implicitly the applicable end-
	entity certificate. For a BIB, if all potential security acceptors		entity certificate. For a BIB, if all potential security verifiers
	are known to possess related public key and/or certificate data then		and acceptors are known to possess related public key and/or
	the public key or additional header parameters can be omitted. Risks		certificate data then the public key or additional header parameters
	of not including related data are described in Section 6.5 and		can be omitted. Risks of not including related data are described in
	Section 6.6.		Section 6.5 and Section 6.6.
	When present, public keys and certificates SHOULD be included as		When present, public keys and certificates SHOULD be included as
	additional header parameters rather than within result COSE messages.		additional header parameters rather than within result COSE messages.
	This provides size efficiency when multiple security results are		This provides size efficiency when multiple security results are
	present because they will all be from the same security source and		present because they will all be from the same security source and
	likely share the same public key material. Security acceptors SHALL		likely share the same public key material. Security verifiers and
	still process public keys or certificates present in a result message		acceptors SHALL still process public keys or certificates present in
	or recipient as applying to that individual COSE level.		a result message or recipient as applying to that individual COSE
			level.
	Security acceptors SHALL aggregate all COSE_Key objects from all		Security verifiers and acceptors SHALL aggregate all COSE_Key objects
	parameters within a single BIB or BCB, independent of encoded type or		from all parameters within a single BIB or BCB, independent of
	order of parameters. Because each context contains a single set of		encoded type or order of parameters. Because each context contains a
	security parameters which apply to all results in the same context,		single set of security parameters which apply to all results in the
	security acceptors SHALL treat all public keys as being related to		same context, security verifiers and acceptors SHALL treat all public
	the security source itself and potentially applying to every result.		keys as being related to the security source itself and potentially
			applying to every result.
	3.3.1. Policy Recommendations		3.3.1. Policy Recommendations
	The RECOMMENDED priority policy for including PKIX material for BIB		The RECOMMENDED priority policy for including PKIX material for BIB
	results is as follows:		results is as follows:
	1. When receivers are not known to possess certificate chains, a		1. When receivers are not known to possess certificate chains, a
	full chain is included (as an "x5chain").		full chain is included (as an "x5chain").
	2. When receivers are known to possess root and intermediate CAs,		2. When receivers are known to possess root and intermediate CAs,
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 26 ¶
	3. When receivers are known to possess associated chains including		3. When receivers are known to possess associated chains including
	end-entity certificates, a certificate thumbnail (as an "x5t").		end-entity certificates, a certificate thumbnail (as an "x5t").
	4. Some arbitrary identifier is used to correlate to an end-entity		4. Some arbitrary identifier is used to correlate to an end-entity
	certificate (as a "kid" with an optional "kid context").		certificate (as a "kid" with an optional "kid context").
	5. The BIB Security Source is used to imply an associated end-entity		5. The BIB Security Source is used to imply an associated end-entity
	certificate which identifies that Node ID.		certificate which identifies that Node ID.
	When PKIX certificates are used by security acceptors and the end-		When PKIX certificates are used by security verifiers and acceptors
	entity certificate is not explicitly trusted (i.e. pinned), the		and the end-entity certificate is not explicitly trusted (i.e.
	security acceptor SHALL perform the certification path validation of		pinned), the security acceptor SHALL perform the certification path
	Section 2.6.1.2 up to one or more trusted CA certificates. Leaving		validation of Section 2.6.1.2 up to one or more trusted CA
	out part of the certification chain can cause the security acceptor		certificates. Leaving out part of the certification chain can cause
	to fail to validate a BIB if the left-out certificates are unknown to		the security acceptor to fail to validate a BIB if the left-out
	the acceptor (see Section 6.6).		certificates are unknown to the acceptor (see Section 6.6).
	Any end-entity certificate associated with a BPSec security source		Any end-entity certificate associated with a BPSec security source
	SHALL adhere to the profile of Section 4.		SHALL adhere to the profile of Section 4.
	4. PKIX Certificate Profile		4. PKIX Certificate Profile
	This section contains requirements on certificates used for the COSE		This section contains requirements on certificates used for the COSE
	context, while Section 3.3 contains requirements for how such		context, while Section 3.3 contains requirements for how such
	certificates are transported or identified.		certificates are transported or identified.
	All end-entity certificates used for BPSec SHALL conform to		All end-entity certificates used for BPSec SHALL conform to
	[RFC5280], or any updates or successors to that profile.		[RFC5280], or any updates or successors to that profile.
	This profile requires Version 3 certificates due to the extensions		This profile requires Version 3 certificates due to the extensions
	used by this profile. Security acceptors SHALL reject as invalid		used by this profile. Security verifiers and acceptors SHALL reject
	Version 1 and Version 2 end-entity certificates.		as invalid Version 1 and Version 2 end-entity certificates.
	Security acceptors SHALL accept certificates that contain an empty		Security verifiers and acceptors SHALL accept certificates that
	Subject field or contain a Subject without a Common Name. Identity		contain an empty Subject field or contain a Subject without a Common
	information in end-entity certificates SHALL be contained in the		Name. Identity information in end-entity certificates SHALL be
	Subject Alternative Name extension in accordance with Section 4.2.1.6		contained in the Subject Alternative Name extension in accordance
	of [RFC5280].		with Section 4.2.1.6 of [RFC5280].
	A BPSec end-entity certificate SHALL contain a NODE-ID in its Subject		A BPSec end-entity certificate SHALL contain a NODE-ID in its Subject
	Alternative Name extension which authenticates the Node ID of the		Alternative Name extension which authenticates the Node ID of the
	security source (for integrity) or the security acceptor (for		security source (for integrity) or the security acceptor (for
	confidentiality). The identifier type NODE-ID is defined in		confidentiality). The identifier type NODE-ID is defined in
	Section 4.4.1 of [RFC9174].		Section 4.4.1 of [RFC9174].
	All end-entity and CA certificates used for BPSec SHOULD contain both		All end-entity and CA certificates used for BPSec SHOULD contain both
	a Subject Key Identifier extension in accordance with Section 4.2.1.2		a Subject Key Identifier extension in accordance with Section 4.2.1.2
	of [RFC5280] and an Authority Key Identifier extension in accordance		of [RFC5280] and an Authority Key Identifier extension in accordance
	with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT		with Section 4.2.1.1 of [RFC5280]. Security verifiers and acceptors
	rely on either a Subject Key Identifier and an Authority Key		SHOULD NOT rely on either a Subject Key Identifier and an Authority
	Identifier being present in any received certificate. Including key		Key Identifier being present in any received certificate. Including
	identifiers simplifies the work of an entity needing to assemble a		key identifiers simplifies the work of an entity needing to assemble
	certification chain.		a certification chain.
	When allowed by CA policy, a BPSec end-entity certificate SHOULD		When allowed by CA policy, a BPSec end-entity certificate SHOULD
	contain a PKIX Extended Key Usage extension in accordance with		contain a PKIX Extended Key Usage extension in accordance with
	Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage		Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage
	extension is present, it SHALL contain a key purpose id-kp-		extension is present, it SHALL contain a key purpose id-kp-
	bundleSecurity of [IANA-SMI]. The id-kp-bundleSecurity purpose MAY		bundleSecurity of [IANA-SMI]. The id-kp-bundleSecurity purpose MAY
	be combined with other purposes in the same certificate.		be combined with other purposes in the same certificate.
	When allowed by CA policy, a BPSec end-entity certificate SHALL		When allowed by CA policy, a BPSec end-entity certificate SHALL
	contain a PKIX Key Usage extension in accordance with Section 4.2.1.3		contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
	of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE		of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE
	security are: digitalSignature, nonRepudiation, keyEncipherment, and		security are: digitalSignature, nonRepudiation, keyEncipherment, and
	keyAgreement. The specific algorithms used by COSE messages in		keyAgreement. The specific algorithms used by COSE messages in
	security results determine which of those key uses are exercised.		security results determine which of those key uses are exercised.
	See Section 4.1 for discussion of key use policies across multiple		See Section 4.1 for discussion of key use policies across multiple
	certificates.		certificates.
	A BPSec end-entity certificate MAY contain an Online Certificate		A BPSec end-entity certificate MAY contain an Online Certificate
	Status Protocol (OCSP) URI within an Authority Information Access		Status Protocol (OCSP) URI within an Authority Information Access
	extension in accordance with Section 4.2.2.1 of [RFC5280]. Security		extension in accordance with Section 4.2.2.1 of [RFC5280]. Security
	acceptors are not expected to have continuous internet connectivity		verifiers and acceptors are not expected to have continuous internet
	sufficient to perform OCSP verification.		connectivity sufficient to perform OCSP verification.
	4.1. Multiple-Certificate Uses		4.1. Multiple-Certificate Uses
	A RECOMMENDED security policy is to limit asymmetric keys (and thus		A RECOMMENDED security policy is to limit asymmetric keys (and thus
	public key certificates) to single uses among the following:		public key certificates) to single uses among the following:
	Bundle transport: With key uses as defined in the convergence layer		Bundle transport: With key uses as defined in the convergence layer
	specification(s). Transports can require additional Extended Key		specification(s). Transports can require additional Extended Key
	Usage, such as id-kp-serverAuth or id-kp-clientAuth.		Usage, such as id-kp-serverAuth or id-kp-clientAuth.
	skipping to change at page 23, line 10 ¶		skipping to change at page 23, line 30 ¶
	order to include the context of the encrypted data as AAD. If an		order to include the context of the encrypted data as AAD. If an
	agent mistakenly allows the use of non-AEAD encryption when		agent mistakenly allows the use of non-AEAD encryption when
	decrypting and verifying a BCB, the possibility of block replay		decrypting and verifying a BCB, the possibility of block replay
	attack is present.		attack is present.
	6.2. Threat: Untrusted End-Entity Certificate		6.2. Threat: Untrusted End-Entity Certificate
	The profile in Section 2.6.1 uses end-entity certificates chained up		The profile in Section 2.6.1 uses end-entity certificates chained up
	to a trusted root CA. A security source can include a certificate		to a trusted root CA. A security source can include a certificate
	set which does not contain the full chain, possibly excluding		set which does not contain the full chain, possibly excluding
	intermediate or root CAs. In an environment where security acceptors		intermediate or root CAs. In an environment where security verifiers
	are known to already contain needed root and intermediate CAs there		and acceptors are known to already contain needed root and
	is no need to include those CAs, but this has a risk of an acceptor		intermediate CAs there is no need to include those CAs, but this has
	not actually having one of the needed CAs.		a risk of an acceptor not actually having one of the needed CAs.
	6.3. Threat: Certificate Validation Vulnerabilities		6.3. Threat: Certificate Validation Vulnerabilities
	Even when a security acceptor is operating properly an attacker can		Even when a security acceptor is operating properly an attacker can
	attempt to exploit vulnerabilities within certificate check		attempt to exploit vulnerabilities within certificate check
	algorithms or configuration to authenticate using an invalid		algorithms or configuration to authenticate using an invalid
	certificate. An invalid certificate exploit could lead to higher-		certificate. An invalid certificate exploit could lead to higher-
	level security issues and/or denial of service to the Node ID being		level security issues and/or denial of service to the Node ID being
	impersonated.		impersonated.
	skipping to change at page 24, line 20 ¶		skipping to change at page 24, line 40 ¶
	acceptor to not be able to properly verify a valid signature or not		acceptor to not be able to properly verify a valid signature or not
	use the correct private key to decrypt valid ciphertext.		use the correct private key to decrypt valid ciphertext.
	6.6. Threat: Non-Trusted Public Key		6.6. Threat: Non-Trusted Public Key
	The profile in Section 3.2 allows the use of PKIX which typically		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		involves end-entity certificates chained up to a trusted root CA. A
	BIB can reference or contain end-entity certificates not previously		BIB can reference or contain end-entity certificates not previously
	known to a security acceptor but the acceptor can still trust the		known to a security acceptor but the acceptor can still trust the
	certificate by verifying it up to a trusted CA. In an environment		certificate by verifying it up to a trusted CA. In an environment
	where security acceptors are known to already contain needed root and		where security verifiers and acceptors are known to already contain
	intermediate CAs there is no need to include those CAs in a proper		needed root and intermediate CAs there is no need to include those
	chain within the security parameters, but this has a risk of an		CAs in a proper chain within the security parameters, but this has a
	acceptor not actually having one of the needed CAs.		risk of an acceptor not actually having one of the needed CAs.
	Because the security parameters are not included as AAD, there is		Because the security parameters are not included as AAD, there is
	still the possibility that an active attacker removes or alters		still the possibility that an active attacker removes or alters
	certification chain data in the parameters. This can cause the		certification chain data in the parameters. This can cause the
	security acceptor to be able to verify a valid signature but not		security acceptor to be able to verify a valid signature but not
	trust the public key used to perform the verification.		trust the public key used to perform the verification.
	6.7. Threat: Passive Leak of Key Material		6.7. Threat: Passive Leak of Key Material
	It is important that the key requirements of Section 2.2 apply only		It is important that the key requirements of Section 2.2 apply only
	skipping to change at page 25, line 14 ¶		skipping to change at page 25, line 33 ¶
	7.1. BPSec Security Context Identifiers		7.1. BPSec Security Context Identifiers
	Within the "Bundle Protocol" registry [IANA-BUNDLE], the following		Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
	entry has been added to the "BPSec Security Context Identifiers" sub-		entry has been added to the "BPSec Security Context Identifiers" sub-
	registry.		registry.
	+==========+=============+======================+		+==========+=============+======================+
	| Value | Description | Reference |		| Value | Description | Reference |
	+==========+=============+======================+		+==========+=============+======================+
	| TBD-COSE | COSE | [This specification] |		| TBA-COSE | COSE | [This specification] |
	+----------+-------------+----------------------+		+----------+-------------+----------------------+
	Table 6: BPSec Security Context Identifiers		Table 6: BPSec Security Context Identifiers
	7.2. BPSec COSE AAD Scope Flags		7.2. BPSec COSE AAD Scope Flags
	Within the "Bundle Protocol" registry [IANA-BUNDLE], the IANA has		Within the "Bundle Protocol" registry [IANA-BUNDLE], the IANA has
	created and now maintains a new registry named "BPSec COSE AAD Scope		created and now maintains a new registry named "BPSec COSE AAD Scope
	Flags" on the "Bundle Protocol" registry page. Table 7 shows the		Flags" on the "Bundle Protocol" registry page. Table 7 shows the
	initial values for this registry.		initial values for this registry.
	The registration policy for this registry is Specification Required.		The registration policy for this registry is Specification Required.
	The value range is unsigned 8-bit integer.		The value range is unsigned 8-bit integer.
	+===========================+==============+======================+		+==============+==============+================+
	| Bit Position (from LSbit) | Name | Reference |		| Bit Position | Name | Reference |
	+===========================+==============+======================+		| | | |
	| 0 | AAD-metadata | [This specification] |		| (from LSbit) | | |
	+---------------------------+--------------+----------------------+		+==============+==============+================+
	| 1 | AAD-btsd | [This specification] |		| 0 | AAD-metadata | [This |
	+---------------------------+--------------+----------------------+		| | | specification] |
	| 2-7 | Reserved | [This specification] |		+--------------+--------------+----------------+
	+---------------------------+--------------+----------------------+		| 1 | AAD-btsd | [This |
			| | | specification] |
			+--------------+--------------+----------------+
			| 2-7 | Reserved | [This |
			| | | specification] |
			+--------------+--------------+----------------+
	Table 7: BPSec COSE AAD Scope Flags		Table 7: BPSec COSE AAD Scope Flags
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IANA-BUNDLE]		[IANA-BUNDLE]
	IANA, "Bundle Protocol",		IANA, "Bundle Protocol",
	<https://www.iana.org/assignments/bundle/>.		<https://www.iana.org/assignments/bundle/>.
	[IANA-COSE]		[IANA-COSE]
	skipping to change at page 31, line 26 ¶		skipping to change at page 32, line 4 ¶
	The external_aad is the encoded data from Figure 10. The payload is		The external_aad is the encoded data from Figure 10. The payload is
	the encoded target BTSD from Figure 7.		the encoded target BTSD from Figure 7.
	[		[
	"MAC0", / context /		"MAC0", / context /
	h'a10105', / protected /		h'a10105', / protected /
	h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201		h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	h'6568656c6c6f' / payload /		h'6568656c6c6f' / payload /
	]		]
	Figure 13: MAC_structure CBOR diagnostic		Figure 13: MAC_structure CBOR diagnostic
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
	skipping to change at page 34, line 6 ¶		skipping to change at page 34, line 6 ¶
	"Signature1", / context /		"Signature1", / context /
	h'a10126', / protected /		h'a10126', / protected /
	h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201		h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	h'6568656c6c6f' / payload /		h'6568656c6c6f' / payload /
	]		]
	Figure 16: Sig_structure CBOR diagnostic		Figure 16: Sig_structure CBOR diagnostic
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
	skipping to change at page 36, line 16 ¶		skipping to change at page 36, line 16 ¶
	"Signature1", / context /		"Signature1", / context /
	h'a1013824', / protected /		h'a1013824', / protected /
	h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201		h'a200010101880700008201692f2f6473742f7376638201662f2f7372632f8201
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	h'6568656c6c6f' / payload /		h'6568656c6c6f' / payload /
	]		]
	Figure 19: Sig_structure CBOR diagnostic		Figure 19: Sig_structure CBOR diagnostic
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
	skipping to change at page 38, line 6 ¶		skipping to change at page 38, line 6 ¶
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	]		]
	Figure 22: Enc_structure CBOR diagnostic		Figure 22: Enc_structure CBOR diagnostic
	The ASB item for this encryption operation is shown in Figure 23 and		The ASB item for this encryption operation is shown in Figure 23 and
	corresponds with the updated target block (containing the ciphertext)		corresponds with the updated target block (containing the ciphertext)
	of Figure 11.		of Figure 11.
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
	skipping to change at page 41, line 6 ¶		skipping to change at page 41, line 6 ¶
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	]		]
	Figure 25: Enc_structure CBOR diagnostic		Figure 25: Enc_structure CBOR diagnostic
	The ASB item for this encryption operation is shown in Figure 26 and		The ASB item for this encryption operation is shown in Figure 26 and
	corresponds with the updated target block (containing the ciphertext)		corresponds with the updated target block (containing the ciphertext)
	of Figure 11.		of Figure 11.
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
	skipping to change at page 45, line 6 ¶		skipping to change at page 45, line 6 ¶
	662f2f7372632f820018281a000f424001010040', / external_aad /		662f2f7372632f820018281a000f424001010040', / external_aad /
	]		]
	Figure 28: Enc_structure CBOR diagnostic		Figure 28: Enc_structure CBOR diagnostic
	The ASB item for this encryption operation is shown in Figure 29 and		The ASB item for this encryption operation is shown in Figure 29 and
	corresponds with the updated target block (containing the ciphertext)		corresponds with the updated target block (containing the ciphertext)
	of Figure 11.		of Figure 11.
	[1], / targets /		[1], / targets /
	-1, / security context TBD-COSE /		-1, / security context TBA-COSE /
	1, / flags: params-present /		1, / flags: params-present /
	[1, "//src/"], / security source /		[1, "//src/"], / security source /
	[ / parameters /		[ / parameters /
	[		[
	5, / AAD-scope /		5, / AAD-scope /
	{0: 0b01, 1: 0b01}, / primary metadata, target metadata /		{0: 0b01, 1: 0b01}, / primary metadata, target metadata /
	]		]
	],		],
	[		[
	[ / target block #1 /		[ / target block #1 /
End of changes. 53 change blocks.
	164 lines changed or deleted		197 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/