rfc9763.original.xml		rfc9763.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<rfc		<!DOCTYPE rfc [
	xmlns:xi="http://www.w3.org/2001/XInclude"		<!ENTITY nbsp "&#160;">
	category="std"		<!ENTITY zwsp "&#8203;">
	docName="draft-ietf-lamps-cert-binding-for-multi-auth-06"		<!ENTITY nbhy "&#8209;">
	ipr="trust200902"		<!ENTITY wj "&#8288;">
	obsoletes=""		]>
	updates=""
	submissionType="IETF"
	xml:lang="en"
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true"
	version="3"
	consensus="true">
	<front>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-lamps-cert-binding-for-multi-auth-06" number="9763" ipr="trust200902" obsolet es="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth= "4" symRefs="true" sortRefs="true" version="3" consensus="true">
	<title abbrev="Related Certificates">Related Certificates for Use in Multiple		<front>
	Authentications within a Protocol</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-m		<title abbrev="Related Certificates for Protocol Authentications">Related Cer
	ulti-auth-06"/>		tificates for Use in
			Multiple Authentications within a Protocol</title>
			<seriesInfo name="RFC" value="9763"/>
	<author fullname="Alison Becker" initials="A." surname="Becker">		<author fullname="Alison Becker" initials="A." surname="Becker">
	<organization abbrev="NSA">National Security Agency</organization>		<organization abbrev="NSA">National Security Agency</organization>
	<address>		<address>
	<email>aebecke@uwe.nsa.gov</email>		<email>aebecke@uwe.nsa.gov</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">		<author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
	<organization abbrev="NSA">National Security Agency</organization>		<organization abbrev="NSA">National Security Agency</organization>
	skipping to change at line 45 ¶		skipping to change at line 39 ¶
	</address>		</address>
	</author>		</author>
	<author fullname="Michael Jenkins" initials="M." surname="Jenkins">		<author fullname="Michael Jenkins" initials="M." surname="Jenkins">
	<organization abbrev="NSA">National Security Agency</organization>		<organization abbrev="NSA">National Security Agency</organization>
	<address>		<address>
	<email>mjjenki@cyber.nsa.gov</email>		<email>mjjenki@cyber.nsa.gov</email>
	</address>		</address>
	</author>		</author>
	<date year="2024"/>		<date year="2025" month="April"/>
			<area>SEC</area>
			<workgroup>lamps</workgroup>
			<keyword>certificate</keyword>
			<keyword>certificate request</keyword>
			<keyword>hybrid</keyword>
			<keyword>authentication</keyword>
			<keyword>post-quantum</keyword>
			<keyword>X.509</keyword>
			<keyword>digital signture</keyword>
			<keyword>quantum resistant</keyword>
	<abstract>		<abstract>
	<t>This document defines a new CSR attribute, relatedCertRequest, and a ne w X.509 certificate extension, RelatedCertificate. The use of the relatedCertReq uest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certif icates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to e mploy the same certificates in hybrid authentication as in authentication done w ith only traditional or post-quantum algorithms.		<t>This document defines a new Certificate Signing Request (CSR) attribute , relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide addit ional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authenti cation, which enables users to employ the same certificates in hybrid authentica tion as in authentication done with only traditional or post-quantum algorithms.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The goal of this document is to define a method for providing assurance that two X.509 (aka PKIX) end-entity certificates are owned by the same entity, in order to perform multiple authentications where each certificate corresponds to a distinct digital signature. This method aims to facilitate the use of two certificates for authentication in a secure protocol while minimizing changes to the certificate format <xref target="RFC5280" format="default"/> and to current PKI best practices.		<t>The goal of this document is to define a method for providing assurance that two X.509 (aka PKIX) end-entity certificates are owned by the same entity, in order to perform multiple authentications where each certificate corresponds to a distinct digital signature. This method aims to facilitate the use of two certificates for authentication in a secure protocol while minimizing changes t o the certificate format <xref target="RFC5280" format="default"/> and to curren t PKI best practices.
	</t>		</t>
	<t>When using non-composite hybrid public key mechanisms, the party relyin g on a certificate (an authentication verifier or a key-establishment initiator) will want assurance that the private keys associated with each certificate are under the control of the same entity. This document defines a certificate exten sion, RelatedCertificate, that signals that the certificate containing the exten sion is able to be used in combination with the other specified certificate.		<t>When using non-composite hybrid public key mechanisms, the party relyin g on a certificate (an authentication verifier or a key-establishment initiator) will want assurance that the private keys associated with each certificate are under the control of the same entity. This document defines a certificate exten sion, RelatedCertificate, that signals that the certificate containing the exten sion is able to be used in combination with the other specified certificate.
	</t>		</t>
	<t>A certification authority (CA) organization (defined here as the entity
	or organization that runs a CA and determines the policies and tools the CA wil		<t>A certification authority (CA) organization (defined here as the entity
	l use) that is asked to issue a certificate with such an extension may want assu		or organization that runs a CA and determines the policies and tools the CA wil
	rance from a registration authority (RA) that the private keys (for example, cor		l use) that is asked to issue a certificate with such an extension may want assu
	responding to two public keys: one in an extant certificate, and one in a curren		rance from a registration authority (RA) that the private keys (corresponding to
	t request) belong to the same entity. To facilitate this, a CSR attribute is def		, for example, two public keys: one in an extant certificate and one in a curren
	ined, called relatedCertRequest, that permits an RA to make such an assertion.		t request) belong to the same entity. To facilitate this, a CSR attribute, call
			ed relatedCertRequest, is defined to permit an RA to make such an assertion.
	</t>		</t>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Overview</name>		<name>Overview</name>
	<t> The general roadmap of this design is best illustrated via an entity ( device, service, user token, etc.) that has an existing certificate (Cert A) and requests a new certificate (Cert B), perhaps as part of an organization's trans ition strategy to migrate their PKI from traditional cryptography to PQC.		<t> The general roadmap of this design is best illustrated via an entity ( e.g., a device, service, user token) that has an existing certificate (Cert A) a nd requests a new certificate (Cert B), perhaps as part of an organization's tra nsition strategy to migrate their PKI from traditional cryptography to post-quan tum cryptography (PQC).
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li> For protocols where authentication is not negotiated, and		<!-- [rmg] Making several clarifications throughout text (as se
	rather is limited by what the signer offers, such as in CMS and S/MIME, either C		en in the bullet below) with the use of 'validation' for certificates and 'verif
	ert A's signing key, Cert B's signing key, or both signing keys may be invoked,		ication' for signatures.
	according to which validators the signer anticipates.		-->
			<li> For protocols where authentication is not negotiated but i
			nstead is limited by what the signer offers, such as in Cryptographic Message Sy
			ntax (CMS) and S/MIME, either Cert A's signing key, Cert B's signing key, or bot
			h signing keys may be invoked, according to which verifiers the signer anticipat
			es.
	</li>		</li>
	<li> For protocols where authentication is negotiated in-protoc ol, such as TLS and IKEv2, 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 so, peers may request that both Cert A and Cert B are used for authentication.		<li> For protocols where authentication is negotiated in-protoc ol, such as TLS and Internet Key Exchange Protocol Version 2 (IKEv2), either Cer t A or Cert B's signing key may be invoked, according to the preference of the v erifier. If the protocol is enabled to do so, peers may request that both Cert A and Cert B are used for authentication.
	</li>		</li>
	</ul>		</ul>
	<t> A validator that prefers multiple authentication types may be assis ted by the inclusion of relevant information in the signer's certificate, that i s, information that indicates the existence of a related certificate, and some a ssurance that those certificates have been issued to the same entity. This docum ent describes a certificate request attribute and certificate extension that pro vide such assurance.</t>		<t> A verifier that prefers multiple authentication types may be assist ed by the inclusion of relevant information in one of the signer's certificates; that is, information that indicates the existence of a related certificate, and some assurance that those certificates have been issued to the same entity. Th is document describes a certificate request attribute and certificate extension that provide such assurance.</t>
	<t>		<t>
	To support this concept, this document defines a new CSR attribute, rel atedCertRequest, which contains information on how to locate a previously-issued certificate (Cert A) and provides evidence that the requesting entity owns that certificate. When the RA makes the request to the CA, the CA uses the given inf ormation to locate Cert A, and then verifies ownership before generating the new certificate, Cert B.		To support this concept, this document defines a new CSR attribute, rel atedCertRequest, which contains information on how to locate a previously issued certificate (Cert A) and provides evidence that the requesting entity owns that certificate. When the RA makes the request to the CA, the CA uses the given in formation to locate Cert A and then verifies ownership before generating the new certificate, Cert B.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Requirements Language</name>		<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH		<t>
	OULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are t		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	o be interpreted as described in <xref target="RFC2119" format="default"/>.		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	</t>		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
			RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>CSR and Related Certificates</name>		<name>CSR and Related Certificates</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default" anchor="related-cert-request">
	<name>The relatedCertRequest Attribute</name>		<name>The relatedCertRequest Attribute</name>
	<t>This section defines a new CSR attribute designed to allow the		<t>This section defines a new CSR attribute designed to allow the RA
	RA to attest that the owner of the public key in the CSR also owns the public k		to attest that the owner of the public key in the CSR also owns the
	ey associated with the end-entity certificate identified in this attribute. The		public key associated with the end-entity certificate identified in
	relatedCertRequest attribute indicates the location of a previously issued certi		this attribute. The relatedCertRequest attribute indicates the
	ficate that the end-entity owns and wants identified in the new certificate requ		location of a previously issued certificate that the end entity owns
	ested through the CSR.		and wants identified in the new certificate requested through the
	</t>		CSR.</t>
	<t>The relatedCertRequest attribute has the following syntax:		<t>The relatedCertRequest attribute has the following syntax:</t>
	</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	relatedCertRequest ATTRIBUTE ::= {		id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
	WITH SYNTAX RequesterCertificate
	ID { TBD1 }		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 }
			]]></sourcecode>
	]]></artwork>		<!-- [rmg] Russ Housley identified an inconsistency with how the ASN.1 was writt en here vs. in the module. Updated for consistency.-->
	<t>The RequesterCertificate type has four fields:		<t>The RequesterCertificate type has four fields:</t>
	</t>		<ul spacing="normal"> <!--Level 1 -->
	<ul spacing="normal">		<li><t>The certID field uses the IssuerAndSerialNumber type <xref
	<li>The certID field uses the IssuerAndSerialNumber type <xref		target="RFC5652" format="default"/> to identify a previously issued
	target="RFC5652" format="default"/> to identify a previously issued end-entity c		end-entity certificate that the requesting entity also
	ertificate that the requesting entity also owns. IssuerAndSerialNumber is repeat		owns. IssuerAndSerialNumber is repeated here for convenience:</t>
	ed here for convenience: </li>
	</ul>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	IssuerAndSerialNumber ::= SEQUENCE {		IssuerAndSerialNumber ::= SEQUENCE {
	issuer Name,		issuer Name,
	serialNumber CertificateSerialNumber }		serialNumber CertificateSerialNumber }
	CertificateSerialNumber ::= INTEGER		CertificateSerialNumber ::= INTEGER
	]]></artwork>		]]></sourcecode>
			</li>
	<ul spacing="normal">		<li><t>The requestTime field uses the BinaryTime type <xref
	<li>The requestTime field uses the BinaryTime type <xref target		target="RFC6019" format="default"/> in order to ensure freshness,
	="RFC6019" format="default"/> in order to ensure freshness, such that the signed		such that the signed data can only be used at the time of the
	data can only be used at the time of the initial CSR. The means by which the CA		initial CSR. The means by which the CA and RA synchronize time is
	and RA synchronize time is outside the scope of this document. BinaryTime is re		outside the scope of this document. BinaryTime is repeated here for
	peated here for convenience: </li>		convenience: </t>
	</ul>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	BinaryTime ::= INTEGER (0..MAX)		BinaryTime ::= INTEGER (0..MAX)
	]]></artwork>		]]></sourcecode>
	<ul spacing="normal">		</li>
	<li>The locationInfo field uses UniformResourceIdentifier to pr		<li><t>The locationInfo field uses UniformResourceIdentifier to
	ovide information on the location of the other certificate the requesting entity		provide information on the location of the other certificate the
	owns. We define UniformResourceIdentifier as: </li>		requesting entity owns. UniformResourceIdentifier is defined as:</t>
	</ul>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	UniformResourceIdentifier ::= IA5String		UniformResourceIdentifier ::= IA5String
	]]></artwork>		]]></sourcecode>
	<t> The UniformResourceIdentifier is a pointer to a location v		<t>The UniformResourceIdentifier is a pointer to a location via
	ia HTTP/HTTPS, or a dataURI. This field can contain one of two acceptable values		HTTP(S) or a dataURI. This field can contain one of two
	:</t>		acceptable values:</t>
	<ul spacing="normal">		<ul spacing="normal"> <!-- Nest 1 -->
	<li>		<li>If the request for (new) Cert B is to the CA
			organization that also issued (existing) Cert A, then the
			UniformResourceIdentifier value <bcp14>SHOULD</bcp14> be a URL
			that points to a file containing a certificate or certificate
			chain that the requesting entity owns, as detailed in <xref
			target="RFC5280" format="default"/>; the URL is made available
			via HTTP or HTTPS. The file must permit access to a CMS
			'certs-only' message containing the end-entity
			certificate or the entire certificate chain. This option uses less
			data than a dataURI. All certificates contained must be DER encoded.</li>
	<t> - If the request for (new) Cert B is to the same CA o		<li>If the request for (new) Cert B is to a CA organization
	rganization as issued (existing) Cert A, then the UniformResourceIdentifier valu		different than the CA organization that issued the certificate
	e SHOULD be a URL that points to a file containing a certificate or certificate		(existing) Cert A referenced in the CSR, then the
	chain that the requesting entity owns, as detailed in <xref target="RFC5280" for		UniformResourceIdentifier value <bcp14>SHOULD</bcp14> be a
	mat="default"/>; the URL is made available via HTTP or HTTPS. The file must perm		dataURI <xref target="RFC2397" format="default"/> containing
	it access to a CMS 'certs-only' message containing the end entity X.509 certific		inline degenerate PKCS#7 (see Sections <xref target="RFC8551" secti
	ate, or the entire certificate chain. In this case, preference for a URL keeps t		on="3.2.1" sectionFormat="bare"/> and <xref target="RFC8551" section="3.8" secti
	he data limit smaller than using a dataURI. All certificates contained must be D		onFormat="bare"/> of <xref
	ER encoded. </t>		target="RFC8551" format="default"/>) consisting of all the
			certificates and CRLs required to validate Cert A. This allows
			the CA to perform validation (as described in <xref target="CSR-pro
			c"/>) without
			having to retrieve certificates/CRLs from another CA. Further
			discussion of requirements for this scenario is in <xref target
			="use-case"/>.</li></ul> <!-- End Nest 1 -->
	<t> - If the request for (new) Cert B is to a CA organiza		</li>
	tion different to the CA organization that issued the certificate (existing) Cer
	t A referenced in the CSR, then the UniformResourceIdentifier value SHOULD be a
	dataURI <xref target="RFC2397" format="default"/> containing inline degenerate P
	KCS#7 (see Sections 3.2.1, and 3.8 of <xref target="RFC8551" format="default"/>)
	consisting of all the certificates and CRLs required to validate Cert A. This a
	llows validation without the CA having to retrieve certificates/CRLs from anothe
	r CA. Further discussion of requirements for this scenario is in Section 5. </t
	>
	</li>
	</ul>
	<ul spacing="normal">
	<li>
	<t>The signature field provides evidence that the request
	ing entity owns the certificate indicated by the certID. Specifically, the sign
	ature field contains a digital signature over the concatenation of DER encoded r
	equestTime and IssuerAndSerialNumber. The concatenated value is signed using the
	signature algorithm and private key associated with the certificate identified
	by the certID field. </t>
	<t>- If the related certificate is a key establishment ce		<!-- [mjj] The following contained the original text "request time and IssuerAnd
	rtificate (e.g., using RSA key transport or ECC key agreement), use the private		SerialNumber". This has been changed to "IssuerandSerialNumber and BinaryTime".
	key to sign one time for POP (as detailed in NIST SP 800-57 Part 1 Rev 5 Section		This was done to agree with the type names and order of the fields in the attrib
	8.1.5.1.1.2) </t>		ute, and to agree with the concatenation order from the third paragraph of Secti
	</li>		on 5. There is no security implication to the order, it simply must be consisten
	</ul>		t.-->
	<t>The validation of this signature by the CA ensures that the
	owner of the CSR also owns the certificate indicated in the relatedCertRequest a
	ttribute. </t>
			<li><t>The signature field provides evidence that the requesting
			entity owns the certificate indicated by the certID field.
			Specifically, the signature field contains a digital signature
			over the concatenation of DER-encoded IssuerAndSerialNumber and Binar
			yTime. The concatenated value is signed using the
			signature algorithm and private key associated with the
			certificate identified by the certID field.</t>
			<ul spacing="normal"> <!-- Nest 2 -->
			<li>If the related certificate is a key establishment
			certificate (e.g., using RSA key transport or Elliptic Curve
			Cryptography (ECC) key
			agreement), the private key is used to sign one time for proof of
			possession (POP) (as
			detailed in Section 8.1.5.1.1.2 of <xref target="NIST-SP-800-57"/>)
			.
			</li>
			</ul> <!-- End Nest 2 -->
			<t>The verification of this signature by the CA ensures that the
			owner of the CSR also owns the certificate indicated in the
			relatedCertRequest attribute.</t>
			</li>
			</ul> <!-- End Level 1 -->
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default" anchor="CSR-proc">
	<name>CSR Processing</name>		<name>CSR Processing</name>
	<t>The information provided in the relatedCertRequest attribute a		<t>The information provided in the relatedCertRequest attribute
	llows the CA to locate a previously issued certificate that the requesting entit		allows the CA to locate a previously issued certificate that the
	y owns, and verify ownership by using the public key in that certificate to vali		requesting entity owns, and confirm ownership by using the public
	date the signature in the relatedCertRequest attribute.		key in that certificate to verify the signature in the
	</t>		relatedCertRequest attribute.
	<t> If a CA receives a CSR that includes the relatedCertRequest a		</t>
	ttribute and that CA supports the attribute, the CA:		<t> If a CA receives a CSR that includes the relatedCertRequest attri
			bute and that CA supports the attribute, the CA:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li> MUST retrieve the certificate identified in the relatedCer		<li> <bcp14>MUST</bcp14> retrieve the certificate identified in
	tRequest attribute using the information provided in UniformResourceIdentifier,		the relatedCertRequest attribute using the information provided in UniformResou
	and validate it using certificate path validation rules defined in <xref target=		rceIdentifier, and validate it using certificate path validation rules defined i
	"RFC5280" format="default"/>. The CA then extracts the IssuerAndSerialNumber fro		n <xref target="RFC5280" format="default"/>. The CA then extracts the IssuerAnd
	m the indicated certificate and compares this value against the IssuerAndSerialN		SerialNumber from the indicated certificate and compares this value against the
	umber provided in the certID field of relatedCertRequest. </li>		IssuerAndSerialNumber provided in the certID field of relatedCertRequest.</li>
	<li>MUST check that the BinaryTime indicated in the requestTime		<li><bcp14>MUST</bcp14> check that the BinaryTime indicated in
	field is sufficiently fresh. Note sufficient freshness is defined by local poli		the requestTime field is sufficiently fresh. Note that sufficient freshness is
	cy out of scope of this document. </li>		defined by local policy and is out of the scope of this document.</li>
	<li>MUST verify the signature field of the relatedCertRequest a		<li><bcp14>MUST</bcp14> verify the signature field of the relat
	ttribute. The CA validates the signature using the public key associated with th		edCertRequest attribute. The CA verifies the signature using the public key ass
	e certificate it located via the info provided in the UniformResourceIdentifier		ociated with the certificate identified by the relatedCertRequest attribute. Th
	field. The details of the validation process are outside the scope of this docum		e details of the verification process are outside the scope of this document.</l
	ent. </li>		i>
	<li>SHOULD issue the new certificate containing the RelatedCert		<li><bcp14>SHOULD</bcp14> issue the new certificate containing
	ificate extension as specified in Section 4, which references the certificate in		the RelatedCertificate extension as specified in <xref target="related-certifica
	dicated in the attribute's IssuerAndSerialNumber field. The CA may apply local p		te"/>, which references the certificate indicated in the attribute's IssuerAndSe
	olicy regarding the suitability of the related certificate, such as validity per		rialNumber field. The CA may also apply local policy regarding the suitability
	iod remaining.</li>		of the related certificate, such as validity period remaining.</li>
	</ul>		</ul>
	<t>The RA MUST only allow a previously-issued certificate to be i ndicated in the relatedCertRequest attribute in order to enable the CA to perfor m the required signature verification.		<t>The RA <bcp14>MUST</bcp14> only allow a previously issued cert ificate to be indicated in the relatedCertRequest attribute in order to enable t he CA to perform the required signature verification.
	</t>		</t>
	<t>The RA MAY send the CA a CSR containing a relatedCertRequest attribut e that includes the IssuerAndSerialNumber of a certificate that was issued by a different CA.		<t>The RA <bcp14>MAY</bcp14> send the CA a CSR containing a relatedCertR equest attribute that includes the IssuerAndSerialNumber of a certificate that w as issued by a different CA.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default" anchor="related-certificate">
	<name>Related Certificate</name>		<name>Related Certificate</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>The RelatedCertificate Extension</name>		<name>The RelatedCertificate Extension</name>
	<t>This section profiles a new X.509v3 certificate extension, Rel		<t>This section specifies a new X.509 certificate extension,
	atedCertificate. RelatedCertificate creates an association between the certific		RelatedCertificate. RelatedCertificate creates an association
	ate containing the RelatedCertificate extension (Cert B) and the certificate ref		between the certificate containing the RelatedCertificate
	erenced within the extension (Cert A). When two end-entity certificates are use		extension (Cert B) and the certificate referenced within the
	d in a protocol, where one of the certificates contains a RelatedCertificate ext		extension (Cert A). When two end-entity certificates are used in
	ension that references another certificate, the authenticating entity is provide		a protocol, where one of the certificates contains a
	d with additional assurance that all certificates belong to the same entity.		RelatedCertificate extension that references the other certificate,
	</t>		the authenticating entity is provided with additional assurance
	<t>The RelatedCertificate extension is an octet string that contains the		that both <!-- [rmg] "all" changed to "both" (accidental artifact fro
	hash of a single end-entity certificate.		m earlier version of draft)-->certificates belong to the same entity.
	</t>		</t>
	<t>The RelatedCertificate extension has the following syntax:		<t>The RelatedCertificate extension contains the hash of a single en
	</t>		d-entity certificate.<!-- [rmg] This line was also updated in alignment with the
	<artwork name="" type="" align="left" alt=""><![CDATA[		update described below. -->
			</t>
			<t>The RelatedCertificate extension has the following syntax:
			</t>
	id-relatedCert OBJECT IDENTIFIER ::= { TBD2 }		<!-- [mjj] The following revision (up to "End revision." is to this current text
			:
			- X.509 Certificate extension
			RelatedCertificate ::= OCTET STRING
			- hash of entire related certificate }
			The extension is comprised of an octet string, which is the digest
			value obtained from hashing the entire related certificate identified
			in the CSR attribute defined above, relatedCertRequest. The
			algorithm used to hash the certificate in the RelatedCertificate
			extension MUST match the hash algorithm used to sign the certificate
			that contains the extension.
			and is based on a clarification requested after WGLC. The original text aligned
			closely with the revised text below. A suggestion was made to modify the origina
			l text to reduce bandwidth [1], without consideration for the issue that was ide
			ntified later. Subsequent consideration of the issue resulted in a reversion bac
			k to the original concept [2]. Since the change is not security related and is a
			reversion to the first version of the draft, we held it for now.
			[1] https://mailarchive.ietf.org/arch/msg/spasm/5YEMl-qHAmSeMdhlStb-Ch4URnU/, pa
			ragraph 5
			[2] https://mailarchive.ietf.org/arch/msg/spasm/svteav5feg-q0xGP9yvm_LvsM68/ - t
			he thread goes beyond this email but the outcome was confirmed and did not chang
			e.
			[rmg] Also made a change to the ASN.1 module in the Appendix to RelatedCertifica
			te.
			-->
			<sourcecode type="asn.1"><![CDATA[
			-- Object Identifier for certificate extension
			id-relatedCert OBJECT IDENTIFIER ::= { 36 }
	-- X.509 Certificate extension		-- X.509 Certificate extension
	RelatedCertificate ::= OCTET STRING		RelatedCertificate ::= SEQUENCE {
	-- hash of entire related certificate }		hashAlgorithm AlgorithmIdentifier,
			hashValue OCTET STRING }
			]]></sourcecode>
	]]></artwork>		<t>The extension is a SEQUENCE of two fields. The hashAlgorithm
	<t>The extension is comprised of an octet string, which is the di		field identifies the hash algorithm used to compute hashValue, which is the dige
	gest value obtained from hashing the entire related certificate identified in th		st value obtained from hashing the entire related certificate identified in the
	e CSR attribute defined above, relatedCertRequest. The algorithm used to hash t		relatedCertRequest CSR attribute defined above. If there is a hash algorithm ex
	he certificate in the RelatedCertificate extension MUST match the hash algorithm		plicitly indicated by the related certificate's signature OID (e.g., ecdsa-with-
	used to sign the certificate that contains the extension.		SHA512), that hash algorithm SHOULD be also used for this extension.</t>
	</t>
	<t>This extension SHOULD NOT be marked critical. Marking this extension		<!-- [mjj] End revision.
	critical would severely impact interoperability.		-->
			<t>This extension <bcp14>SHOULD NOT</bcp14> be marked critical. Marking
			this extension critical would severely impact interoperability.
	</t>		</t>
	<t>For certificate chains, this extension MUST only be included in the e nd-entity certificate.		<t>For certificate chains, this extension <bcp14>MUST</bcp14> only be in cluded in the end-entity certificate.
	</t>		</t>
	<t>For the RelatedCertificate extension to be meaningful, a CA that issu es a certificate with this extension:		<t>For the RelatedCertificate extension to be meaningful, a CA that issu es a certificate with this extension:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>MUST only include a certificate in the extension that is li		<li><bcp14>MUST</bcp14> only include a certificate in the exten
	sted and validated in the relatedCertRequest attribute of the CSR submitted by t		sion that is listed in the relatedCertRequest attribute of the CSR submitted by
	he requesting entity.</li>		the requesting entity.</li>
	<li>MUST ensure that the related certificate at least contains		<!-- [rmg] "and validated" was removed from the above sentence
	the KU bits and EKU OIDs <xref target="RFC5280" format="default"/> being asserte		because it is redundant and imprecise in the context of the sentence. It has alr
	d in the certificate being issued. </li>		eady been required to have been validated, and the inclusion of "and validated"
	<li>SHOULD determine that all certificates are valid at the tim		in the above sentence made it sound like the relatedCertRequest attribute itself
	e of issuance.  The usable overlap of validity periods is a Subscriber concern.<		validates it, which is inaccurate. -->
	/li>		<li><bcp14>MUST</bcp14> ensure that the related certificate con
			tains the key usage (KU) bits and extended key usage (EKU) OIDs <xref target="RF
			C5280" format="default"/> being asserted in the certificate being issued.</li>
			<li><bcp14>SHOULD</bcp14> determine that the related certificat
			e is valid at the time of issuance. The usable overlap with the validity period
			of the newly issued certificate is a Subscriber concern.</li>
	</ul>		</ul>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Endpoint Protocol Multiple Authentication Processing</name>		<name>Endpoint Protocol Multiple Authentication Processing</name>
	<t>		<t>
	When the preference to use a non-composite hybrid authentication mode is expressed by an endpoint through the protocol itself (e.g., during negot iation), the use of the RelatedCertificate extension and its enforcement are lef t to the protocol's native authorization mechanism (along with other decisions e ndpoints make about whether to complete or drop a connection).		When the preference to use a non-composite hybrid authentication mode is expressed by an endpoint through the protocol itself (e.g., during negot iation), the use of the RelatedCertificate extension and its enforcement are lef t to the protocol's existing authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection).
	</t>		</t>
	<t>If an endpoint has indicated that it is willing to do non-composite h ybrid authentication and receives the appropriate authentication data, it should check end-entity certificates (Cert A and Cert B) for the RelatedCertificate ex tension. If present in one certificate, for example Cert B, it should:		<t>If an endpoint has indicated that it supports non-composite hybrid au thentication and receives the appropriate authentication data, it should check e nd-entity certificates (Cert A and Cert B) for the RelatedCertificate extension. If present in one certificate (e.g., Cert B), it should:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Compute the appropriate hash of Cert A, the other end-entit		<li>Compute the appropriate hash of Cert A, the other end-entit
	y certificate received. The hash algorithm is the same as the one used to sign t		y certificate received.</li>
	he certificate containing the extension. </li>		<!--[rmg] Deleted the second sentence of the above bullet since
	<li>Verify that the hash value matches the hash entry in the Re		it is addressed in the modification made to RelatedCertificate in Section 4.1.
	latedCertificate extension of Cert B. </li>		-->
			<li>Confirm that the hash value matches the hash entry in the R
			elatedCertificate extension of Cert B.</li>
	</ul>		</ul>
	<t>It is outside the scope of this document how to proceed with a uthentication based on the outcome of this verification process. Different deter minations may be made depending on each peer's policy regarding whether both or at least one authentication needs to succeed.		<t>How to proceed with authentication based on the outcome of thi s process is outside the scope of this document. Different determinations may b e made depending on each peer's policy regarding whether both or at least one au thentication needs to succeed.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default" anchor="use-case">
	<name> Use Case </name>		<name> Use Case </name>
	<t>		<t>
	The general design of this method is best illustrated through specific u se within a migration strategy to PQ cryptography via a non-composite hybrid aut hentication mechanism. The intent is for a CA issuing a new, PQ certificate to a dd an X.509 extension that provides information about a previously-issued, tradi tional certificate in which the private key is controlled by the same end entity as the PQ certificate.		The general design of this method is best illustrated through specific u se within a migration strategy to PQC via a non-composite hybrid authentication mechanism. The intent is for a CA issuing a new, post-quantum (PQ) certificate to add an X.509 extension that provides information about a previously issued, t raditional certificate in which the private key is controlled by the same end en tity as the PQ certificate.
	</t>		</t>
	<t>		<t>
	In the following scenario, an entity currently has a traditional certificate, and is requesting a new, PQ certificate be issued with the RelatedC ertificate extension included that references the entity's traditional certifica te.		In the following scenario, an entity currently has a traditional certificate and requests that a new, PQ certificate be issued containing a Relat edCertificate extension, which references the entity's traditional certificate.
	</t>		</t>
	<t>		<t>
	The RA receives a CSR for a PQ certificate, where the CSR include s the relatedCertRequest attribute detailed in this document. The relatedCertReq uest attribute includes a certID field that identifies the entity's previously-i ssued traditional certificate, and a signature field in which the requesting ent ity produces a digital signature over the certID and a timestamp, using the priv ate key of the certificate identified by the certID.		The RA receives a CSR for a PQ certificate, where the CSR include s the relatedCertRequest attribute detailed in this document. The relatedCertRe quest attribute includes a certID field that identifies the entity's previously issued traditional certificate and a signature field in which the requesting ent ity produces a digital signature over the concatenation of the IssuerAndSerialNu mber and BinaryTime, using the private key of the certificate identified by the IssuerAndSerialNumber.
	</t>		</t>
	<t>		<t>
	The purpose of the relatedCertRequest attribute is to serve as a tool for the RA to provide assurance to the CA organization that the entity that controls the private key of the PQ certificate being requested also controls th e private key of the referenced, previously-issued traditional certificate.		The purpose of the relatedCertRequest attribute is to serve as a tool for the RA to provide assurance to the CA organization that the entity that controls the private key of the PQ certificate being requested also controls th e private key of the referenced, previously issued traditional certificate.
	</t>		</t>
	<t>		<t>
	Upon receipt of the CSR, the CA issues a PQ certificate to the re questing entity that includes the RelatedCertificate extension detailed in this document; the extension includes a hash of the entire traditional certificate id entified in the CSR. The X.509 extension creates an association between the PQ c ertificate and the traditional certificate via end-entity ownership.		Upon receipt and validation of the CSR, the CA issues a PQ certif icate to the requesting entity that includes the RelatedCertificate extension de tailed in this document; the extension includes a hash of the entire traditional certificate identified in the CSR. The X.509 extension creates an association between the PQ certificate and the traditional certificate via an assertion of e nd-entity ownership.
	</t>		</t>
	<t>		<t>
	The attribute and subsequent extension together provide assurance from the CA organization that the same end-entity controls the private keys of both certificates.  It is neither a requirement nor a mandate that either certif icate be used with the other; it is simply an assurance that they can be used to gether, as they are under the control of the same entity.		The attribute and subsequent extension together provide assurance from the CA organization that the same end entity controls the private keys of both certificates. It is neither a requirement nor a mandate that either certif icate be used with the other; it is simply an assurance that they can be used to gether, as they are under the control of the same entity.
	</t>		</t>
	</section>		</section>
	<section anchor="CAconsiderations" numbered="true" toc="default">		<section anchor="CAconsiderations" numbered="true" toc="default">
	<name>CA Organization Considerations</name>		<name>CA Organization Considerations</name>
	<t>		<t>
	The relatedCertRequest CSR attribute provides assertion to the CA organ		The relatedCertRequest CSR attribute asserts end-entity control of the
	ization issuing Cert B, of end entity control of the private key of a related ce		private key associated with a related certificate (Cert A) to the CA organizatio
	rtificate, Cert A. There may arise scenarios where a public-facing CA organizati		n issuing a new certificate (Cert B). A public-facing CA organization may not b
	on is not configured to validate signatures associated with certificates that ha		e configured to validate certificates that have been issued by different CA orga
	ve been issued by a different CA organization. In this case, recognition of the		nizations. In this case, recognition of the contents in the relatedCertRequest
	contents in the relatedCertRequest attribute may be contingent upon a pre-arrang		attribute may necessitate pre-arrangement, e.g., a contract with pre-configured
	ed contract with pre-configured trust anchors from the other CA organization, an		trust anchors from another CA organization and agreements regarding policies con
	d include agreements on certificate policy with regards to certificate applicati		cerning certificate application, issuance, and acceptance.
	on, issuance, and acceptance. Further, matching policies between CA organization		</t>
	s on protection of private key may be necessary in order for the whole assurance
	level from the other CA organization to be accepted.
	</t>
	<t>		<t>
	In a similar vein, if the CA organization issuing the PQ certificate ca n recognize the relatedCertRequest attribute in the CSR and wishes to issue the certificate with the RelatedCerts extension, it may be the case that a different CA organization issued the related certificate referenced in the CSR. In order to ensure that the certificates have been issued under homogeneous sets of secur ity parameters, the certificate policies should be the same with regard to commo n security requirements. The issuing CA, as part of related certificate public k ey validation, determines what policies are acceptable for the certification pat h of the related certificate. The issuing CA determines what is acceptable to th em in terms of certificate policy, to ensure that the policies for protection of private key are sufficient. The relatedCertRequest attribute and subsequent Rel atedCertificate certificate extension are solely intended to provide assurance t hat both private keys are controlled by the same end entity.		Continuing with this scenario, in order for the CA organization to ensu re that Cert B is issued under security parameters comparable to Cert A, the iss uing CA organization should match the issued certification policies to the relat ed ones. The issuing CA organization, as part of its validation of Cert A, asce rtains what policies are asserted in Cert A’s certification path and determines which of their own certification policies will best ensure that the protection o f the private key associated with Cert B is comparable to that of Cert A. The r elatedCertRequest attribute and subsequent RelatedCertificate certificate extens ion are solely intended to provide assurance that both private keys are controll ed by the same end entity.
	</t>		</t>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document inherits security considerations identified in <xref targ et="RFC5280" format="default"/>.		This document inherits security considerations identified in <xref targ et="RFC5280" format="default"/>.
	</t>		</t>
	<t>The mechanisms described in this document provide only a means to expre ss that multiple certificates are related. They are intended for the interpretat ion of the recipient of the data in which they are embedded (i.e. a CSR or certi ficate). They do not by themselves effect any security function.		<t>The mechanisms described in this document provide only a means to expre ss that multiple certificates are related. They are intended for the interpreta tion of the recipient of the data in which they are embedded (i.e., a CSR or cer tificate). They do not by themselves effect any security function.
	</t>		</t>
	<t>Authentication, unlike key establishment, is necessarily a one-way arra		<t>Authentication, unlike key establishment, is necessarily a one-way arra
	ngement. That is, authentication is an assertion made by a claimant to a verifie		ngement. That is, authentication is an assertion made by a claimant to a verifi
	r. The means and strength of mechanism for authentication have to be to the sati		er.
	sfaction of the verifier. A system security designer needs to be aware of what a
	uthentication assurances are needed in various parts of the system and how to ac		The means and strength of the authentication mechanism have to be satisfac
	hieve that assurance. In a closed system (e.g. Company X distributing firmware t		tory to the verifier. A system security designer needs to be aware of what auth
	o its own devices) the approach may be implicit. In an online protocol like IPse		entication assurances are needed in various parts of the system and how to achie
	c where the peers are generally known, any mechanism selected from a pre-establi		ve that assurance. In a closed system (e.g., Company X distributing firmware to
	shed set may be sufficient. For more promiscuous online protocols, like TLS, the		its own devices), the approach may be implicit. In an online protocol like IPs
	ability for the verifier to express what is possible and what is preferred - an		ec where the peers are generally known, any mechanism selected from a pre-establ
	d to assess that it got what it needed - is important.		ished set may be sufficient.
			For more promiscuous online protocols like TLS, the ability for the verifi
			er to express what is possible and what is preferred -- and to assess that its r
			equirements were met -- is important.
	</t>		</t>
	<t>A certificate is an assertion of binding between an identity and a publ ic key. However, that assertion is based on several other assurances, specifical ly, that the identity belongs to a particular physical entity, and that that phy sical entity has control over the private key corresponding to the public. For a ny hybrid approach, it is important that there be evidence that the same entity controls all private keys at time of use (to the verifier) and at time of regist ration (to the CA).		<t>A certificate is an assertion of binding between an identity and a publ ic key. However, that assertion is based on several other assurances, especiall y that the identity belongs to a particular physical entity and that the physica l entity has control over the private key corresponding to the public key. For any hybrid approach, it is important that there be evidence that the same entity controls all private keys at time of use (to the verifier) and at time of regis tration (to the CA).
	</t>		</t>
	<t>All hybrid implementations are vulnerable to a downgrade attack in whic h a malicious peer does not express support for the stronger algorithm, resultin g in an exchange that can only rely upon a weaker algorithm for security.		<t>All hybrid implementations are vulnerable to a downgrade attack in whic h a malicious peer does not express support for the stronger algorithm, resultin g in an exchange that can only rely upon a weaker algorithm for security.
	</t>		</t>
	<t>		<t>
	Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedC ertRequest CSR attribute, if the URI points to malicious code. Implementors shou ld ensure the data is properly formed and validate the retrieved data fully.		Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedC ertRequest CSR attribute, as a URL can point to malicious code. Implementors sh ould ensure the data is properly formed and validate the retrieved data fully.
	</t>		</t>
	<t>		<t>
	CAs should be aware that retrieval of existing certificates may be subj
	ect to observation; if this is a concern, it may be advisable to use the dataURI		CAs should be aware that retrieval of existing certificates may be subj
	option described in Section 3.1.		ect to observation; if this is a concern, it is advisable to use the dataURI opt
			ion described in <xref target="related-cert-request"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="IANA" numbered="true" toc="default">		<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document defines an extension for use with X.509 certificates. IAN
	A is requested to register the following OID in the SMI Security for PKIX Certif		<t>This document defines an extension for use with X.509 certificates. IA
	icate Extension registry:		NA has registered the following OID in the "SMI Security for PKIX Certificate Ex
			tension" registry (1.3.6.1.5.5.7.1):
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 }
	]]></artwork>
	<t>with this document as the Required Specification.		<table align="center">
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Decimal</th>
			<th align="left" colspan="1" rowspan="1">Description</th>
			<th align="left" colspan="1" rowspan="1">References</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">36</td>
			<td align="left" colspan="1" rowspan="1">id-pe-relatedCert</td>
			<td align="left" colspan="1" rowspan="1">RFC 9763</td>
			</tr>
			</tbody>
			</table>
			<t>The registration procedure is Specification Required <xref target="RFC8
			126"/>.
	</t>		</t>
	<t>This document defines a CSR attribute. IANA is requested to register the following OID in the SMI Security for S/MIME Attributes registry:		<t>This document defines a CSR attribute. IANA has registered the foll owing OID in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 }		<table align="center">
	]]></artwork>		<thead>
	<t> This document defines an ASN.1 Module in Appendix A. IANA is		<tr>
	requested to register an OID for the module identifier in the SMI Security for P		<th align="left" colspan="1" rowspan="1">Decimal</th>
	KIX Module Identifier registry:		<th align="left" colspan="1" rowspan="1">Description</th>
			<th align="left" colspan="1" rowspan="1">References</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">60</td>
			<td align="left" colspan="1" rowspan="1">id-aa-relatedCertRequest</t
			d>
			<td align="left" colspan="1" rowspan="1">RFC 9763</td>
			</tr>
			</tbody>
			</table>
			<t> This document defines an ASN.1 module in <xref target="app-ad
			ditional"/>. IANA has registered the following OID for the module identifier i
			n the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	id-mod-related-cert(TBD0)		<table align="center">
	]]></artwork>
	<t> The RFC Editor is requested to replace the TBDs in the text with the ass		<thead>
	igned OIDs.</t>		<tr>
			<th align="left" colspan="1" rowspan="1">Decimal</th>
			<th align="left" colspan="1" rowspan="1">Description</th>
			<th align="left" colspan="1" rowspan="1">References</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">115</td>
			<td align="left" colspan="1" rowspan="1">id-mod-related-cert-2023</t
			d>
			<td align="left" colspan="1" rowspan="1">RFC 9763</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.5280.xml"/>		e.RFC.5280.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.2119.xml"/>		e.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.5652.xml"/>		e.RFC.8174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.6019.xml"/>		e.RFC.5652.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.2397.xml"/>		e.RFC.6019.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
			e.RFC.2397.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.5912.xml"/>		e.RFC.5912.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.6268.xml"/>		e.RFC.6268.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	l/reference.RFC.8551.xml"/>		e.RFC.8551.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
			e.RFC.8126.xml"/>
			<reference anchor="NIST-SP-800-57" target="https://nvlpubs.nist.gov/nistpubs/Spe
			cialPublications/NIST.SP.800-57pt1r5.pdf">
			<front>
			<title>Recommendation for Key Management: Part 1 - General</title>
			<author fullname="Elaine Barker" surname="Barker">
			<organization>Information Technology Laboratory</organization>
			</author>
			<date month="May" year="2020"/>
			</front>
			<refcontent>National Institute of Standards and Technology</refcontent>
			<seriesInfo name="NIST SP" value="800-57pt1r5"/>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
			</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="app-additional" numbered="true" toc="default">		<section anchor="app-additional" numbered="true" toc="default">
	<name>ASN.1 Module</name>		<name>ASN.1 Module</name>
	<t>The following RelatedCertificate ASN.1 module describes the Re questerCertificate type found in the relatedCertAttribute. It pulls definitions from modules defined in <xref target="RFC5912" format="default"/>, and <xref tar get="RFC6268" format="default"/>, and <xref target="RFC6019" format="default"/> for the IssuerAndSerialNumber type, and BinaryTime type, respectively. </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<t>The following RelatedCertificate ASN.1 module describes the
			RequesterCertificate type found in the relatedCertAttribute. It pulls
			definitions from modules defined in <xref target="RFC5912"
			format="default"/> and <xref target="RFC6268" format="default"/> for the I
			ssuerAndSerialNumber type and in <xref target="RFC6019" format="default"/> for t
			he BinaryTime type.</t>
			<sourcecode type="asn.1"><![CDATA[
	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(TBD0)}		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 [RFC5912]		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
	FROM CryptographicMessageSyntax-2010 -- in [RFC6268]		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 [RFC6019]		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) attributes(2) }
	-- relatedCertificate Extension		-- relatedCertificate Extension
	id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 }		id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 }
	RelatedCertificate ::= OCTET STRING		RelatedCertificate ::= SEQUENCE {
			hashAlgorithm AlgorithmIdentifier,
			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 TBD1 }		id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
	RequesterCertificate ::= SEQUENCE {		RequesterCertificate ::= SEQUENCE {
	certID IssuerAndSerialNumber,		certID IssuerAndSerialNumber,
	requestTime BinaryTime,		requestTime BinaryTime,
	locationInfo UniformResourceIdentifier,		locationInfo UniformResourceIdentifier,
	signature BIT STRING }		signature BIT STRING }
	UniformResourceIdentifier ::= IA5String		UniformResourceIdentifier ::= IA5String
	aa-relatedCertRequest ATTRIBUTE ::= {		aa-relatedCertRequest ATTRIBUTE ::= {
	TYPE RequesterCertificate		TYPE RequesterCertificate
	IDENTIFIED BY id-aa-relatedCertRequest }		IDENTIFIED BY id-aa-relatedCertRequest }
	END		END
	]]></artwork>		]]></sourcecode>
	</section>		</section>
			<!-- [rfced] We updated artwork to sourcecode in Sections 3.1 and 4.1 and in
			Appendix A. Please confirm that this is correct.
			In addition, please consider whether the "type" attribute of any sourcecode
			element should be set and/or has been set correctly.
			The current list of preferred values for "type" is available at
			<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
			If the current list does not contain an applicable type, feel free to
			suggest additions for consideration. Note that it is also acceptable
			to leave the "type" attribute not set.
			[rfceditor]: need author response.
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			For example, please consider whether "native" should be updated.
			In addition, please consider whether "traditional" should be updated for clarity
			.
			While the NIST website
			<https://web.archive.org/web/20250214092458/https://www.nist.gov/
			nist-research-library/nist-technical-series-publications-author-instructions#tab
			le1>
			indicates that this term is potentially biased, it is also ambiguous.
			"Tradition" is a subjective term, as it is not the same for everyone.
			-->
			<!-- [mjj] Replaced "native" with "existing". "Traditional" has become something
			of a term-of-art when describing algorithms, to distinguish from "post-quantum"
			.
			-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 81 change blocks.
	297 lines changed or deleted		491 lines changed or added
This html diff was produced by rfcdiff 1.48.