rfc9891v3.txt		rfc9891.txt
	skipping to change at line 123 ¶		skipping to change at line 123 ¶
	Node, as defined in Section 4.2.5.2 of [RFC9171], which is equivalent		Node, as defined in Section 4.2.5.2 of [RFC9171], which is equivalent
	to the EID being usable as a singleton endpoint. One common EID used		to the EID being usable as a singleton endpoint. One common EID used
	as a Node ID is the Administrative EID, which is guaranteed to exist		as a Node ID is the Administrative EID, which is guaranteed to exist
	on any BP Node. At the time of writing, the URI schemes "dtn" and		on any BP Node. At the time of writing, the URI schemes "dtn" and
	"ipn" as defined in Section 4.2.5.1 of [RFC9171] are valid for a		"ipn" as defined in Section 4.2.5.1 of [RFC9171] are valid for a
	singleton endpoint and, thus, a Node ID. Because the BundleEID claim		singleton endpoint and, thus, a Node ID. Because the BundleEID claim
	is new to ACME, a new ACME Identifier type "bundleEID" is needed to		is new to ACME, a new ACME Identifier type "bundleEID" is needed to
	manage this claim within ACME messaging.		manage this claim within ACME messaging.
	Once an ACME server validates a Node ID, either as a pre-		Once an ACME server validates a Node ID, either as a pre-
	authorization of an identifier type "bundleEID" as one of the		authorization of an identifier type "bundleEID" or as one of the
	authorizations of an order containing an identifier type "bundleEID",		authorizations of an order containing an identifier type "bundleEID",
	the client can finalize the order using an associated Certificate		the client can finalize the order using an associated Certificate
	Signing Request (CSR). Because a single order can contain multiple		Signing Request (CSR). Because a single order can contain multiple
	identifiers of multiple types, there can be operational issues for a		identifiers of multiple types, there can be operational issues for a
	client attempting to, and possibly failing to, validate those		client attempting to, and possibly failing to, validate those
	multiple identifiers as described in Section 5.1. Once a certificate		multiple identifiers as described in Section 5.1. Once a certificate
	is issued for a Node ID, how the ACME client configures the BP Agent		is issued for a Node ID, how the ACME client configures the BP Agent
	with the new certificate is an implementation matter.		with the new certificate is an implementation matter.
	1.1. Scope		1.1. Scope
	skipping to change at line 431 ¶		skipping to change at line 431 ¶
	{		{
	"type": "bundleEID",		"type": "bundleEID",
	"value": "dtn://example/"		"value": "dtn://example/"
	}		}
	2.1. Subsets of Bundle EID		2.1. Subsets of Bundle EID
	A PKIX certificate SAN identity containing an Other Name form of		A PKIX certificate SAN identity containing an Other Name form of
	BundleEID can hold any EID value (as a text URI). But the		BundleEID can hold any EID value (as a text URI). But the
	certificate profile used by the TCP Convergence Layer [RFC9174] and		certificate profile used by the TCP CL in Section 4.4 of [RFC9174]
	supported by the ACME validation method in Section 3 requires that		and supported by the ACME validation method in Section 3 requires
	the value hold a Node ID (Section 1.4).		that the value hold a Node ID (Section 1.4).
	In addition to the narrowing of that certificate profile, this		In addition to the narrowing of that certificate profile, this
	validation method requires that the client's BP Agent respond to		validation method requires that the client's BP Agent respond to
	administrative records sent to the Node ID being validated.		administrative records sent to the Node ID being validated.
	Typically, this is limited to an Administrative EID (Section 1.4)		Typically, this is limited to an Administrative EID (Section 1.4)
	destination. However, the administrative element of a BP Node is not		destination. However, the administrative element of a BP Node is not
	prohibited from receiving administrative records for, or sending		prohibited from receiving administrative records for, or sending
	records from, other Node IDs in order to support this validation		records from, other Node IDs in order to support this validation
	method.		method.
	skipping to change at line 913 ¶		skipping to change at line 913 ¶
	An integrity gateway SHALL validate the Source Node ID of a Bundle,		An integrity gateway SHALL validate the Source Node ID of a Bundle,
	using local-network-specific means, before adding a BIB to the		using local-network-specific means, before adding a BIB to the
	Bundle. The exact means by which an integrity gateway validates a		Bundle. The exact means by which an integrity gateway validates a
	Bundle's source is network specific, but it could use physical-layer,		Bundle's source is network specific, but it could use physical-layer,
	network-layer, or BP-convergence-layer authentication. The Bundle		network-layer, or BP-convergence-layer authentication. The Bundle
	source could also add its own BIB with a local-network-specific		source could also add its own BIB with a local-network-specific
	security context or local-network-specific key material (i.e., a		security context or local-network-specific key material (i.e., a
	group key shared within the local network).		group key shared within the local network).
	When an integrity gateway adds a BIB, it SHALL be in accordance with		When an integrity gateway adds a BIB, it SHALL be in accordance with
	BPSec [RFC9172] requirements. The BIB targets SHALL cover both the		BPSec [RFC9172] requirements. The BIB integrity SHALL cover both the
	payload block and the primary block (either directly as a target or		payload block and the primary block, either directly as a target or
	as additional authenticated data for the payload block MAC/		as additional authenticated data for the payload block MAC/signature.
	signature). The Security Source of this BIB SHALL be either the		The Security Source of this BIB SHALL be either the Bundle source
	Bundle source Node ID itself or a routing node trusted by the		Node ID itself or a routing node trusted by the destination node (see
	destination node (see Section 6.2).		Section 6.2).
	5. Certificate Request Profile		5. Certificate Request Profile
	The ultimate purpose of this ACME validation is to allow a CA to		The ultimate purpose of this ACME validation is to allow a CA to
	issue certificates following the profiles of Section 4.4.2 of		issue certificates following the profiles of Section 4.4.2 of
	[RFC9174] and Section 4 of [BPSEC-COSE]. These purposes are referred		[RFC9174] and Section 4 of [BPSEC-COSE]. These purposes are referred
	to here as "Bundle security certificates".		to here as "Bundle security certificates".
	The ACME identifier type "bundleEID" correlates to the PKIX		The ACME identifier type "bundleEID" correlates to the PKIX
	certificate and certificate request "NODE-ID" as defined in		certificate and certificate request "NODE-ID" as defined in
	skipping to change at line 951 ¶		skipping to change at line 951 ¶
	includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of		includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of
	id-kp-bundleSecurity. When a Bundle security certificate is issued		id-kp-bundleSecurity. When a Bundle security certificate is issued
	based on a validated NODE-ID, the certificate SHALL include an		based on a validated NODE-ID, the certificate SHALL include an
	Extended Key Usage of id-kp-bundleSecurity.		Extended Key Usage of id-kp-bundleSecurity.
	5.1. Multiple Identity Claims		5.1. Multiple Identity Claims
	A single Bundle security CSR MAY contain a mixed set of SAN		A single Bundle security CSR MAY contain a mixed set of SAN
	identifiers, including combinations of IP-ID [RFC9525], DNS-ID		identifiers, including combinations of IP-ID [RFC9525], DNS-ID
	[RFC9525], and NODE-ID [RFC9174] types. These correspond with ACME		[RFC9525], and NODE-ID [RFC9174] types. These correspond with ACME
	identifier types "ip", "dns", and "bundleEID", respectively.		identifier type "ip", "dns", and "bundleEID", respectively.
	There is no restriction on how a certificate combines these claims,		There is no restriction on how a certificate combines these claims,
	but each identifier SHALL be validated by an ACME server to issue		but each identifier SHALL be validated by an ACME server to issue
	such a certificate as part of an associated ACME order. This is no		such a certificate as part of an associated ACME order. This is no
	different than the existing behavior of ACME [RFC8555] but is		different than the existing behavior of ACME [RFC8555] but is
	mentioned here to make sure that CA policy handles such situations,		mentioned here to make sure that CA policy handles such situations,
	especially related to validation failure of an identifier in the		especially related to validation failure of an identifier in the
	presence of multiple identifiers. Existing validation mechanisms are		presence of multiple identifiers. Existing validation mechanisms are
	defined for identifier types "ip" [RFC8738] and "dns" [RFC8555] among		defined for identifier type "ip" [RFC8738] and "dns" [RFC8555] among
	others [IANA-ACME].		others [IANA-ACME].
	The specific use case of TLS-based security for BPv7 CL transport in		The specific use case of TLS-based security for the TCP CL in
	Section 4.4 of [RFC9174] allows, and for some network policies		Section 4.4 of [RFC9174] allows, and for some network policies
	requires, that a certificate authenticate both the DNS name of an		requires, that a certificate authenticate both the DNS name of an
	entity as well as the Node ID of the entity. These authentications		entity as well as the Node ID of the entity. These authentications
	apply to each identifier type, used for different network layers, at		apply to each identifier type, used for different network layers, at
	different points during secure session establishment.		different points during secure session establishment.
	5.2. Generating Encryption-Only or Signing-Only Bundle Security		5.2. Generating Encryption-Only or Signing-Only Bundle Security
	Certificates		Certificates
	ACME extensions specified in this document can be used to request		ACME extensions specified in this document can be used to request
End of changes. 6 change blocks.
	13 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.48.