rfc9763v1.txt		rfc9763.txt
	Internet Engineering Task Force (IETF) A. Becker		Internet Engineering Task Force (IETF) A. Becker
	Request for Comments: 9763 R. Guthrie		Request for Comments: 9763 R. Guthrie
	Category: Standards Track M. Jenkins		Category: Standards Track M. Jenkins
	ISSN: 2070-1721 NSA		ISSN: 2070-1721 NSA
	March 2025		April 2025
	Related Certificates for Use in Multiple Authentications within a		Related Certificates for Use in Multiple Authentications within a
	Protocol		Protocol
	Abstract		Abstract
	This document defines a new Certificate Signing Request (CSR)		This document defines a new Certificate Signing Request (CSR)
	attribute, relatedCertRequest, and a new X.509 certificate extension,		attribute, relatedCertRequest, and a new X.509 certificate extension,
	RelatedCertificate. The use of the relatedCertRequest attribute in a		RelatedCertificate. The use of the relatedCertRequest attribute in a
	CSR and the inclusion of the RelatedCertificate extension in the		CSR and the inclusion of the RelatedCertificate extension in the
	skipping to change at line 106 ¶		skipping to change at line 106 ¶
	an extension may want assurance from a registration authority (RA)		an extension may want assurance from a registration authority (RA)
	that the private keys (corresponding to, for example, two public		that the private keys (corresponding to, for example, two public
	keys: one in an extant certificate and one in a current request)		keys: one in an extant certificate and one in a current request)
	belong to the same entity. To facilitate this, a CSR attribute,		belong to the same entity. To facilitate this, a CSR attribute,
	called relatedCertRequest, is defined to permit an RA to make such an		called relatedCertRequest, is defined to permit an RA to make such an
	assertion.		assertion.
	1.1. Overview		1.1. Overview
	The general roadmap of this design is best illustrated via an entity		The general roadmap of this design is best illustrated via an entity
	(a device, service, user token, etc.) that has an existing		(e.g., a device, service, user token) that has an existing
	certificate (Cert A) and requests a new certificate (Cert B), perhaps		certificate (Cert A) and requests a new certificate (Cert B), perhaps
	as part of an organization's transition strategy to migrate their PKI		as part of an organization's transition strategy to migrate their PKI
	from traditional cryptography to post-quantum cryptography (PQC).		from traditional cryptography to post-quantum cryptography (PQC).
	* For protocols where authentication is not negotiated and is rather		* For protocols where authentication is not negotiated but instead
	limited by what the signer offers, such as in Cryptographic		is limited by what the signer offers, such as in Cryptographic
	Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert		Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert
	B's signing key, or both signing keys may be invoked, according to		B's signing key, or both signing keys may be invoked, according to
	which validators the signer anticipates.		which verifiers the signer anticipates.
	* For protocols where authentication is negotiated in-protocol, such		* For protocols where authentication is negotiated in-protocol, such
	as TLS and Internet Key Exchange Protocol Version 2 (IKEv2),		as TLS and Internet Key Exchange Protocol Version 2 (IKEv2),
	either Cert A or Cert B's signing key may be invoked, according to		either Cert A or Cert B's signing key may be invoked, according to
	the preference of the validator. If the protocol is enabled to do		the preference of the verifier. If the protocol is enabled to do
	so, peers may request that both Cert A and Cert B are used for		so, peers may request that both Cert A and Cert B are used for
	authentication.		authentication.
	A validator that prefers multiple authentication types may be		A verifier that prefers multiple authentication types may be assisted
	assisted by the inclusion of relevant information in the signer's		by the inclusion of relevant information in one of the signer's
	certificate, that is, information that indicates the existence of a		certificates; that is, information that indicates the existence of a
	related certificate, and some assurance that those certificates have		related certificate, and some assurance that those certificates have
	been issued to the same entity. This document describes a		been issued to the same entity. This document describes a
	certificate request attribute and certificate extension that provide		certificate request attribute and certificate extension that provide
	such assurance.		such assurance.
	To support this concept, this document defines a new CSR attribute,		To support this concept, this document defines a new CSR attribute,
	relatedCertRequest, which contains information on how to locate a		relatedCertRequest, which contains information on how to locate a
	previously issued certificate (Cert A) and provides evidence that the		previously issued certificate (Cert A) and provides evidence that the
	requesting entity owns that certificate. When the RA makes the		requesting entity owns that certificate. When the RA makes the
	request to the CA, the CA uses the given information to locate Cert A		request to the CA, the CA uses the given information to locate Cert A
	skipping to change at line 162 ¶		skipping to change at line 162 ¶
	This section defines a new CSR attribute designed to allow the RA to		This section defines a new CSR attribute designed to allow the RA to
	attest that the owner of the public key in the CSR also owns the		attest that the owner of the public key in the CSR also owns the
	public key associated with the end-entity certificate identified in		public key associated with the end-entity certificate identified in
	this attribute. The relatedCertRequest attribute indicates the		this attribute. The relatedCertRequest attribute indicates the
	location of a previously issued certificate that the end entity owns		location of a previously issued certificate that the end entity owns
	and wants identified in the new certificate requested through the		and wants identified in the new certificate requested through the
	CSR.		CSR.
	The relatedCertRequest attribute has the following syntax:		The relatedCertRequest attribute has the following syntax:
	relatedCertRequest ATTRIBUTE ::= {		id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
	WITH SYNTAX RequesterCertificate
	ID { 60 }		aa-relatedCertRequest ATTRIBUTE ::= {
	}		TYPE RequesterCertificate
			IDENTIFIED BY id-aa-relatedCertRequest}
	RequesterCertificate ::= SEQUENCE {		RequesterCertificate ::= SEQUENCE {
	certID IssuerAndSerialNumber,		certID IssuerAndSerialNumber,
	requestTime BinaryTime,		requestTime BinaryTime,
	locationInfo UniformResourceIdentifier,		locationInfo UniformResourceIdentifier,
	signature BIT STRING }		signature BIT STRING }
	The RequesterCertificate type has four fields:		The RequesterCertificate type has four fields:
	* The certID field uses the IssuerAndSerialNumber type [RFC5652] to		* The certID field uses the IssuerAndSerialNumber type [RFC5652] to
	skipping to change at line 196 ¶		skipping to change at line 197 ¶
	* The requestTime field uses the BinaryTime type [RFC6019] in order		* The requestTime field uses the BinaryTime type [RFC6019] in order
	to ensure freshness, such that the signed data can only be used at		to ensure freshness, such that the signed data can only be used at
	the time of the initial CSR. The means by which the CA and RA		the time of the initial CSR. The means by which the CA and RA
	synchronize time is outside the scope of this document.		synchronize time is outside the scope of this document.
	BinaryTime is repeated here for convenience:		BinaryTime is repeated here for convenience:
	BinaryTime ::= INTEGER (0..MAX)		BinaryTime ::= INTEGER (0..MAX)
	* The locationInfo field uses UniformResourceIdentifier to provide		* The locationInfo field uses UniformResourceIdentifier to provide
	information on the location of the other certificate the		information on the location of the other certificate the
	requesting entity owns. We define UniformResourceIdentifier as:		requesting entity owns. UniformResourceIdentifier is defined as:
	UniformResourceIdentifier ::= IA5String		UniformResourceIdentifier ::= IA5String
	The UniformResourceIdentifier is a pointer to a location via HTTP/		The UniformResourceIdentifier is a pointer to a location via
	HTTPS or a dataURI. This field can contain one of two acceptable		HTTP(S) or a dataURI. This field can contain one of two
	values:		acceptable values:
	- If the request for (new) Cert B is to the same CA		- If the request for (new) Cert B is to the CA organization that
	organization as issued (existing) Cert A, then the		also issued (existing) Cert A, then the
	UniformResourceIdentifier value SHOULD be a URL that points to		UniformResourceIdentifier value SHOULD be a URL that points to
	a file containing a certificate or certificate chain that the		a file containing a certificate or certificate chain that the
	requesting entity owns, as detailed in [RFC5280]; the URL is		requesting entity owns, as detailed in [RFC5280]; the URL is
	made available via HTTP or HTTPS. The file must permit access		made available via HTTP or HTTPS. The file must permit access
	to a CMS 'certs-only' message containing the end-entity X.509		to a CMS 'certs-only' message containing the end-entity
	certificate or the entire certificate chain. In this case,		certificate or the entire certificate chain. This option uses
	preference for a URL keeps the data limit smaller than using a		less data than a dataURI. All certificates contained must be
	dataURI. All certificates contained must be DER encoded.		DER encoded.
	- If the request for (new) Cert B is to a CA organization		- If the request for (new) Cert B is to a CA organization
	different to the CA organization that issued the certificate		different than the CA organization that issued the certificate
	(existing) Cert A referenced in the CSR, then the		(existing) Cert A referenced in the CSR, then the
	UniformResourceIdentifier value SHOULD be a dataURI [RFC2397]		UniformResourceIdentifier value SHOULD be a dataURI [RFC2397]
	containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8		containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8
	of [RFC8551]) consisting of all the certificates and CRLs		of [RFC8551]) consisting of all the certificates and CRLs
	required to validate Cert A. This allows validation without		required to validate Cert A. This allows the CA to perform
	the CA having to retrieve certificates/CRLs from another CA.		validation (as described in Section 3.2) without having to
	Further discussion of requirements for this scenario is in		retrieve certificates/CRLs from another CA. Further discussion
	Section 5.		of requirements for this scenario is in Section 5.
	* The signature field provides evidence that the requesting entity		* The signature field provides evidence that the requesting entity
	owns the certificate indicated by the certID. Specifically, the		owns the certificate indicated by the certID field. Specifically,
	signature field contains a digital signature over the		the signature field contains a digital signature over the
	concatenation of DER-encoded requestTime and		concatenation of DER-encoded IssuerAndSerialNumber and BinaryTime.
	IssuerAndSerialNumber. The concatenated value is signed using the		The concatenated value is signed using the signature algorithm and
	signature algorithm and private key associated with the		private key associated with the certificate identified by the
	certificate identified by the certID field.		certID field.
	- If the related certificate is a key establishment certificate		- If the related certificate is a key establishment certificate
	(e.g., using RSA key transport or Elliptic Curve Cryptography		(e.g., using RSA key transport or Elliptic Curve Cryptography
	(ECC) key agreement), use the private key to sign one time for		(ECC) key agreement), the private key is used to sign one time
	proof of possession (POP) (as detailed in Section 8.1.5.1.1.2 of		for proof of possession (POP) (as detailed in
	[NIST-SP-800-57]).		Section 8.1.5.1.1.2 of [NIST-SP-800-57]).
	The validation of this signature by the CA ensures that the owner of		The verification of this signature by the CA ensures that the
	the CSR also owns the certificate indicated in the relatedCertRequest		owner of the CSR also owns the certificate indicated in the
	attribute.		relatedCertRequest attribute.
	3.2. CSR Processing		3.2. CSR Processing
	The information provided in the relatedCertRequest attribute allows		The information provided in the relatedCertRequest attribute allows
	the CA to locate a previously issued certificate that the requesting		the CA to locate a previously issued certificate that the requesting
	entity owns, and verify ownership by using the public key in that		entity owns, and confirm ownership by using the public key in that
	certificate to validate the signature in the relatedCertRequest		certificate to verify the signature in the relatedCertRequest
	attribute.		attribute.
	If a CA receives a CSR that includes the relatedCertRequest attribute		If a CA receives a CSR that includes the relatedCertRequest attribute
	and that CA supports the attribute, the CA:		and that CA supports the attribute, the CA:
	* MUST retrieve the certificate identified in the relatedCertRequest		* MUST retrieve the certificate identified in the relatedCertRequest
	attribute using the information provided in		attribute using the information provided in
	UniformResourceIdentifier, and validate it using certificate path		UniformResourceIdentifier, and validate it using certificate path
	validation rules defined in [RFC5280]. The CA then extracts the		validation rules defined in [RFC5280]. The CA then extracts the
	IssuerAndSerialNumber from the indicated certificate and compares		IssuerAndSerialNumber from the indicated certificate and compares
	this value against the IssuerAndSerialNumber provided in the		this value against the IssuerAndSerialNumber provided in the
	certID field of relatedCertRequest.		certID field of relatedCertRequest.
	* MUST check that the BinaryTime indicated in the requestTime field		* MUST check that the BinaryTime indicated in the requestTime field
	is sufficiently fresh. Note that sufficient freshness is defined		is sufficiently fresh. Note that sufficient freshness is defined
	by local policy and is out of the scope of this document.		by local policy and is out of the scope of this document.
	* MUST verify the signature field of the relatedCertRequest		* MUST verify the signature field of the relatedCertRequest
	attribute. The CA validates the signature using the public key		attribute. The CA verifies the signature using the public key
	associated with the certificate it located via the info provided		associated with the certificate identified by the
	in the UniformResourceIdentifier field. The details of the		relatedCertRequest attribute. The details of the verification
	validation process are outside the scope of this document.		process are outside the scope of this document.
	* SHOULD issue the new certificate containing the RelatedCertificate		* SHOULD issue the new certificate containing the RelatedCertificate
	extension as specified in Section 4, which references the		extension as specified in Section 4, which references the
	certificate indicated in the attribute's IssuerAndSerialNumber		certificate indicated in the attribute's IssuerAndSerialNumber
	field. The CA may apply local policy regarding the suitability of		field. The CA may also apply local policy regarding the
	the related certificate, such as validity period remaining.		suitability of the related certificate, such as validity period
			remaining.
	The RA MUST only allow a previously issued certificate to be		The RA MUST only allow a previously issued certificate to be
	indicated in the relatedCertRequest attribute in order to enable the		indicated in the relatedCertRequest attribute in order to enable the
	CA to perform the required signature verification.		CA to perform the required signature verification.
	The RA MAY send the CA a CSR containing a relatedCertRequest		The RA MAY send the CA a CSR containing a relatedCertRequest
	attribute that includes the IssuerAndSerialNumber of a certificate		attribute that includes the IssuerAndSerialNumber of a certificate
	that was issued by a different CA.		that was issued by a different CA.
	4. Related Certificate		4. Related Certificate
	4.1. The RelatedCertificate Extension		4.1. The RelatedCertificate Extension
	This section profiles a new X.509v3 certificate extension,		This section specifies a new X.509 certificate extension,
	RelatedCertificate. RelatedCertificate creates an association		RelatedCertificate. RelatedCertificate creates an association
	between the certificate containing the RelatedCertificate extension		between the certificate containing the RelatedCertificate extension
	(Cert B) and the certificate referenced within the extension (Cert		(Cert B) and the certificate referenced within the extension (Cert
	A). When two end-entity certificates are used in a protocol, where		A). When two end-entity certificates are used in a protocol, where
	one of the certificates contains a RelatedCertificate extension that		one of the certificates contains a RelatedCertificate extension that
	references another certificate, the authenticating entity is provided		references the other certificate, the authenticating entity is
	with additional assurance that all certificates belong to the same		provided with additional assurance that both certificates belong to
	entity.		the same entity.
	The RelatedCertificate extension is an octet string that contains the		The RelatedCertificate extension contains the hash of a single end-
	hash of a single end-entity certificate.		entity certificate.
	The RelatedCertificate extension has the following syntax:		The RelatedCertificate extension has the following syntax:
	-- Object Identifiers for certificate extension		-- Object Identifier for certificate extension
	id-relatedCert OBJECT IDENTIFIER ::= { 36 }		id-relatedCert OBJECT IDENTIFIER ::= { 36 }
	-- X.509 Certificate extension		-- X.509 Certificate extension
	RelatedCertificate ::= OCTET STRING		RelatedCertificate ::= SEQUENCE {
	-- hash of entire related certificate }		hashAlgorithm DigestAlgorithmIdentifier,
			hashValue OCTET STRING }
	The extension is comprised of an octet string, which is the digest		The extension is a SEQUENCE of two fields. The hashAlgorithm field
	value obtained from hashing the entire related certificate identified		identifies the hash algorithm used to compute hashValue, which is the
	in the relatedCertRequest CSR attribute defined above. The algorithm		digest value obtained from hashing the entire related certificate
	used to hash the certificate in the RelatedCertificate extension MUST		identified in the relatedCertRequest CSR attribute defined above. If
	match the hash algorithm used to sign the certificate that contains		there is a hash algorithm explicitly indicated by the related
	the extension.		certificate's signature OID (e.g., ecdsa-with-SHA512), that hash
			algorithm SHOULD be also used for this extension.
	This extension SHOULD NOT be marked critical. Marking this extension		This extension SHOULD NOT be marked critical. Marking this extension
	critical would severely impact interoperability.		critical would severely impact interoperability.
	For certificate chains, this extension MUST only be included in the		For certificate chains, this extension MUST only be included in the
	end-entity certificate.		end-entity certificate.
	For the RelatedCertificate extension to be meaningful, a CA that		For the RelatedCertificate extension to be meaningful, a CA that
	issues a certificate with this extension:		issues a certificate with this extension:
	* MUST only include a certificate in the extension that is listed		* MUST only include a certificate in the extension that is listed in
	and validated in the relatedCertRequest attribute of the CSR		the relatedCertRequest attribute of the CSR submitted by the
	submitted by the requesting entity.		requesting entity.
	* MUST ensure that the related certificate at least contains the key		* MUST ensure that the related certificate contains the key usage
	usage (KU) bits and extended key usage (EKU) OIDs [RFC5280] being		(KU) bits and extended key usage (EKU) OIDs [RFC5280] being
	asserted in the certificate being issued.		asserted in the certificate being issued.
	* SHOULD determine that all certificates are valid at the time of		* SHOULD determine that the related certificate is valid at the time
	issuance. The usable overlap of validity periods is a Subscriber		of issuance. The usable overlap with the validity period of the
	concern.		newly issued certificate is a Subscriber concern.
	4.2. Endpoint Protocol Multiple Authentication Processing		4.2. Endpoint Protocol Multiple Authentication Processing
	When the preference to use a non-composite hybrid authentication mode		When the preference to use a non-composite hybrid authentication mode
	is expressed by an endpoint through the protocol itself (e.g., during		is expressed by an endpoint through the protocol itself (e.g., during
	negotiation), the use of the RelatedCertificate extension and its		negotiation), the use of the RelatedCertificate extension and its
	enforcement are left to the protocol's native authorization mechanism		enforcement are left to the protocol's existing authorization
	(along with other decisions endpoints make about whether to complete		mechanism (along with other decisions endpoints make about whether to
	or drop a connection).		complete or drop a connection).
	If an endpoint has indicated that it is willing to do non-composite		If an endpoint has indicated that it supports non-composite hybrid
	hybrid authentication and receives the appropriate authentication		authentication and receives the appropriate authentication data, it
	data, it should check end-entity certificates (Cert A and Cert B) for		should check end-entity certificates (Cert A and Cert B) for the
	the RelatedCertificate extension. If present in one certificate, for		RelatedCertificate extension. If present in one certificate (e.g.,
	example Cert B, it should:		Cert B), it should:
	* Compute the appropriate hash of Cert A, the other end-entity		* Compute the appropriate hash of Cert A, the other end-entity
	certificate received. The hash algorithm is the same as the one		certificate received.
	used to sign the certificate containing the extension.
	* Verify that the hash value matches the hash entry in the		* Confirm that the hash value matches the hash entry in the
	RelatedCertificate extension of Cert B.		RelatedCertificate extension of Cert B.
	How to proceed with authentication based on the outcome of this		How to proceed with authentication based on the outcome of this
	verification process is outside the scope of this document.		process is outside the scope of this document. Different
	Different determinations may be made depending on each peer's policy		determinations may be made depending on each peer's policy regarding
	regarding whether both or at least one authentication needs to		whether both or at least one authentication needs to succeed.
	succeed.
	5. Use Case		5. Use Case
	The general design of this method is best illustrated through		The general design of this method is best illustrated through
	specific use within a migration strategy to PQC via a non-composite		specific use within a migration strategy to PQC via a non-composite
	hybrid authentication mechanism. The intent is for a CA issuing a		hybrid authentication mechanism. The intent is for a CA issuing a
	new, post-quantum (PQ) certificate to add an X.509 extension that		new, post-quantum (PQ) certificate to add an X.509 extension that
	provides information about a previously issued, traditional		provides information about a previously issued, traditional
	certificate in which the private key is controlled by the same end		certificate in which the private key is controlled by the same end
	entity as the PQ certificate.		entity as the PQ certificate.
	In the following scenario, an entity currently has a traditional		In the following scenario, an entity currently has a traditional
	certificate and is requesting a new, PQ certificate be issued with		certificate and requests that a new, PQ certificate be issued
	the RelatedCertificate extension included that references the		containing a RelatedCertificate extension, which references the
	entity's traditional certificate.		entity's traditional certificate.
	The RA receives a CSR for a PQ certificate, where the CSR includes		The RA receives a CSR for a PQ certificate, where the CSR includes
	the relatedCertRequest attribute detailed in this document. The		the relatedCertRequest attribute detailed in this document. The
	relatedCertRequest attribute includes a certID field that identifies		relatedCertRequest attribute includes a certID field that identifies
	the entity's previously issued traditional certificate and a		the entity's previously issued traditional certificate and a
	signature field in which the requesting entity produces a digital		signature field in which the requesting entity produces a digital
	signature over the certID and a timestamp, using the private key of		signature over the concatenation of the IssuerAndSerialNumber and
	the certificate identified by the certID.		BinaryTime, using the private key of the certificate identified by
			the IssuerAndSerialNumber.
	The purpose of the relatedCertRequest attribute is to serve as a tool		The purpose of the relatedCertRequest attribute is to serve as a tool
	for the RA to provide assurance to the CA organization that the		for the RA to provide assurance to the CA organization that the
	entity that controls the private key of the PQ certificate being		entity that controls the private key of the PQ certificate being
	requested also controls the private key of the referenced, previously		requested also controls the private key of the referenced, previously
	issued traditional certificate.		issued traditional certificate.
	Upon receipt of the CSR, the CA issues a PQ certificate to the		Upon receipt and validation of the CSR, the CA issues a PQ
	requesting entity that includes the RelatedCertificate extension		certificate to the requesting entity that includes the
	detailed in this document; the extension includes a hash of the		RelatedCertificate extension detailed in this document; the extension
	entire traditional certificate identified in the CSR. The X.509		includes a hash of the entire traditional certificate identified in
	extension creates an association between the PQ certificate and the		the CSR. The X.509 extension creates an association between the PQ
	traditional certificate via end-entity ownership.		certificate and the traditional certificate via an assertion of end-
			entity ownership.
	The attribute and subsequent extension together provide assurance		The attribute and subsequent extension together provide assurance
	from the CA organization that the same end entity controls the		from the CA organization that the same end entity controls the
	private keys of both certificates. It is neither a requirement nor a		private keys of both certificates. It is neither a requirement nor a
	mandate that either certificate be used with the other; it is simply		mandate that either certificate be used with the other; it is simply
	an assurance that they can be used together, as they are under the		an assurance that they can be used together, as they are under the
	control of the same entity.		control of the same entity.
	6. CA Organization Considerations		6. CA Organization Considerations
	The relatedCertRequest CSR attribute provides assertion to the CA		The relatedCertRequest CSR attribute asserts end-entity control of
	organization issuing Cert B of end entity control of the private key		the private key associated with a related certificate (Cert A) to the
	of a related certificate, Cert A. Scenarios may arise where a		CA organization issuing a new certificate (Cert B). A public-facing
	public-facing CA organization is not configured to validate		CA organization may not be configured to validate certificates that
	signatures associated with certificates that have been issued by a		have been issued by different CA organizations. In this case,
	different CA organization. In this case, recognition of the contents		recognition of the contents in the relatedCertRequest attribute may
	in the relatedCertRequest attribute may be contingent upon a pre-		necessitate pre-arrangement, e.g., a contract with pre-configured
	arranged contract with pre-configured trust anchors from the other CA		trust anchors from another CA organization and agreements regarding
	organization and include agreements on certificate policy with		policies concerning certificate application, issuance, and
	regards to certificate application, issuance, and acceptance.		acceptance.
	Further, matching policies between CA organizations on protection of
	the private key may be necessary in order for the whole assurance
	level from the other CA organization to be accepted.
	Similarly, if the CA organization issuing the PQ certificate can		Continuing with this scenario, in order for the CA organization to
	recognize the relatedCertRequest attribute in the CSR and wishes to		ensure that Cert B is issued under security parameters comparable to
	issue the certificate with the RelatedCerts extension, it may be the		Cert A, the issuing CA organization should match the issued
	case that a different CA organization issued the related certificate		certification policies to the related ones. The issuing CA
	referenced in the CSR. In order to ensure that the certificates have		organization, as part of its validation of Cert A, ascertains what
	been issued under homogeneous sets of security parameters, the		policies are asserted in Cert A’s certification path and determines
	certificate policies should be the same with regard to common		which of their own certification policies will best ensure that the
	security requirements. The issuing CA, as part of related		protection of the private key associated with Cert B is comparable to
	certificate public key validation, determines what policies are		that of Cert A. The relatedCertRequest attribute and subsequent
	acceptable for the certification path of the related certificate.		RelatedCertificate certificate extension are solely intended to
	The issuing CA determines what is acceptable to them in terms of		provide assurance that both private keys are controlled by the same
	certificate policy, to ensure that the policies for protection of the		end entity.
	private key are sufficient. The relatedCertRequest attribute and
	subsequent RelatedCertificate certificate extension are solely
	intended to provide assurance that both private keys are controlled
	by the same end entity.
	7. Security Considerations		7. Security Considerations
	This document inherits security considerations identified in		This document inherits security considerations identified in
	[RFC5280].		[RFC5280].
	The mechanisms described in this document provide only a means to		The mechanisms described in this document provide only a means to
	express that multiple certificates are related. They are intended		express that multiple certificates are related. They are intended
	for the interpretation of the recipient of the data in which they are		for the interpretation of the recipient of the data in which they are
	embedded (i.e., a CSR or certificate). They do not by themselves		embedded (i.e., a CSR or certificate). They do not by themselves
	effect any security function.		effect any security function.
	Authentication, unlike key establishment, is necessarily a one-way		Authentication, unlike key establishment, is necessarily a one-way
	arrangement. That is, authentication is an assertion made by a		arrangement. That is, authentication is an assertion made by a
	claimant to a verifier. The means and strength of mechanism for		claimant to a verifier. The means and strength of the authentication
	authentication have to be to the satisfaction of the verifier. A		mechanism have to be satisfactory to the verifier. A system security
	system security designer needs to be aware of what authentication		designer needs to be aware of what authentication assurances are
	assurances are needed in various parts of the system and how to		needed in various parts of the system and how to achieve that
	achieve that assurance. In a closed system (e.g., Company X		assurance. In a closed system (e.g., Company X distributing firmware
	distributing firmware to its own devices), the approach may be		to its own devices), the approach may be implicit. In an online
	implicit. In an online protocol like IPsec where the peers are		protocol like IPsec where the peers are generally known, any
	generally known, any mechanism selected from a pre-established set		mechanism selected from a pre-established set may be sufficient. For
	may be sufficient. For more promiscuous online protocols, like TLS,		more promiscuous online protocols like TLS, the ability for the
	the ability for the verifier to express what is possible and what is		verifier to express what is possible and what is preferred -- and to
	preferred - and to assess that it got what it needed - is important.		assess that its requirements were met -- is important.
	A certificate is an assertion of binding between an identity and a		A certificate is an assertion of binding between an identity and a
	public key. However, that assertion is based on several other		public key. However, that assertion is based on several other
	assurances, specifically, that the identity belongs to a particular		assurances, especially that the identity belongs to a particular
	physical entity and that the physical entity has control over the		physical entity and that the physical entity has control over the
	private key corresponding to the public. For any hybrid approach, it		private key corresponding to the public key. For any hybrid
	is important that there be evidence that the same entity controls all		approach, it is important that there be evidence that the same entity
	private keys at time of use (to the verifier) and at time of		controls all private keys at time of use (to the verifier) and at
	registration (to the CA).		time of registration (to the CA).
	All hybrid implementations are vulnerable to a downgrade attack in		All hybrid implementations are vulnerable to a downgrade attack in
	which a malicious peer does not express support for the stronger		which a malicious peer does not express support for the stronger
	algorithm, resulting in an exchange that can only rely upon a weaker		algorithm, resulting in an exchange that can only rely upon a weaker
	algorithm for security.		algorithm for security.
	Implementors should be aware of risks that arise from the retrieval		Implementors should be aware of risks that arise from the retrieval
	of a related certificate via the UniformResourceIdentifier provided		of a related certificate via the UniformResourceIdentifier provided
	in the relatedCertRequest CSR attribute, if the URI points to		in the relatedCertRequest CSR attribute, as a URL can point to
	malicious code. Implementors should ensure the data is properly		malicious code. Implementors should ensure the data is properly
	formed and validate the retrieved data fully.		formed and validate the retrieved data fully.
	CAs should be aware that retrieval of existing certificates may be		CAs should be aware that retrieval of existing certificates may be
	subject to observation; if this is a concern, it may be advisable to		subject to observation; if this is a concern, it is advisable to use
	use the dataURI option described in Section 3.1.		the dataURI option described in Section 3.1.
	8. IANA Considerations		8. IANA Considerations
	This document defines an extension for use with X.509 certificates.		This document defines an extension for use with X.509 certificates.
	IANA has registered the following OID in the "SMI Security for PKIX		IANA has registered the following OID in the "SMI Security for PKIX
	Certificate Extension" registry (1.3.6.1.5.5.7.1):		Certificate Extension" registry (1.3.6.1.5.5.7.1):
	+=========+===================+============+		+=========+===================+============+
	| Decimal | Description | References |		| Decimal | Description | References |
	+=========+===================+============+		+=========+===================+============+
	skipping to change at line 601 ¶		skipping to change at line 598 ¶
	[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/		[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", RFC 8551, DOI 10.17487/RFC8551,		Message Specification", RFC 8551, DOI 10.17487/RFC8551,
	April 2019, <https://www.rfc-editor.org/info/rfc8551>.		April 2019, <https://www.rfc-editor.org/info/rfc8551>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	The following RelatedCertificate ASN.1 module describes the		The following RelatedCertificate ASN.1 module describes the
	RequesterCertificate type found in the relatedCertAttribute. It		RequesterCertificate type found in the relatedCertAttribute. It
	pulls definitions from modules defined in [RFC5912], and [RFC6268],		pulls definitions from modules defined in [RFC5912] and [RFC6268] for
	and [RFC6019] for the IssuerAndSerialNumber type, and BinaryTime		the IssuerAndSerialNumber type and in [RFC6019] for the BinaryTime
	type, respectively.		type.
	RelatedCertificate { iso(1) identified-organization(3) dod(6)		RelatedCertificate { iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-related-cert-2023(115)}		id-mod-related-cert-2023(115)}
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	IMPORTS		IMPORTS
	ATTRIBUTE, EXTENSION		ATTRIBUTE, EXTENSION
	FROM PKIX-CommonTypes-2009 -- in RFC 5912		FROM PKIX-CommonTypes-2009 -- in RFC 5912
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) }		id-mod-pkixCommon-02(57) }
	IssuerAndSerialNumber		IssuerAndSerialNumber, DigestAlgorithmIdentifier
	FROM CryptographicMessageSyntax-2010 -- in RFC 6268		FROM CryptographicMessageSyntax-2010 -- in RFC 6268
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0)		pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-cms-2009(58) }		id-mod-cms-2009(58) }
	BinaryTime		BinaryTime
	FROM BinarySigningTimeModule -- in RFC 6019		FROM BinarySigningTimeModule -- in RFC 6019
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0)		pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-binarySigningTime(27) } ;		id-mod-binarySigningTime(27) } ;
	-- Object identifier arcs		-- Object identifier arcs
	id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)		id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }		dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }
	id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)		id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
	rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) }		rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2 }
	-- relatedCertificate Extension		-- relatedCertificate Extension
	id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 }		id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 }
	RelatedCertificate ::= OCTET STRING		RelatedCertificate ::= SEQUENCE {
			hashAlgorithm DigestAlgorithmIdentifier,
			hashValue OCTET STRING }
	ext-relatedCertificate EXTENSION ::= {		ext-relatedCertificate EXTENSION ::= {
	SYNTAX RelatedCertificate		SYNTAX RelatedCertificate
	IDENTIFIED BY id-pe-relatedCert }		IDENTIFIED BY id-pe-relatedCert }
	-- relatedCertRequest Attribute		-- relatedCertRequest Attribute
	id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }		id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
	RequesterCertificate ::= SEQUENCE {		RequesterCertificate ::= SEQUENCE {
	certID IssuerAndSerialNumber,		certID IssuerAndSerialNumber,
	requestTime BinaryTime,		requestTime BinaryTime,
	locationInfo UniformResourceIdentifier,		locationInfo UniformResourceIdentifiers,
	signature BIT STRING }		signature BIT STRING }
	UniformResourceIdentifier ::= IA5String		UniformResourceIdentifiers ::= SEQUENCE SIZE (1..MAX) OF URI
			URI ::= IA5String
	aa-relatedCertRequest ATTRIBUTE ::= {		aa-relatedCertRequest ATTRIBUTE ::= {
	TYPE RequesterCertificate		TYPE RequesterCertificate
	IDENTIFIED BY id-aa-relatedCertRequest }		IDENTIFIED BY id-aa-relatedCertRequest }
	END		END
	Authors' Addresses		Authors' Addresses
	Alison Becker		Alison Becker
	National Security Agency		National Security Agency
	Email: aebecke@uwe.nsa.gov		Email: aebecke@uwe.nsa.gov
	Rebecca Guthrie		Rebecca Guthrie
End of changes. 55 change blocks.
	179 lines changed or deleted		180 lines changed or added
This html diff was produced by rfcdiff 1.48.