<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lamps-cert-binding-for-multi-auth-06" number="9763" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" consensus="true">

  <front>

   <title abbrev="Related Certificates">Related Certificates for Protocol Authentications">Related Certificates for Use in
   Multiple Authentications within a Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-06"/> name="RFC" value="9763"/>

    <author fullname="Alison Becker" initials="A." surname="Becker">
      <organization abbrev="NSA">National Security Agency</organization>
      <address>
        <email>aebecke@uwe.nsa.gov</email>
      </address>
    </author>

    <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
      <organization abbrev="NSA">National Security Agency</organization>
      <address>
        <email>rmguthr@uwe.nsa.gov</email>
      </address>
	</author>

    <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
      <organization abbrev="NSA">National Security Agency</organization>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>

    <date year="2024"/> 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>
      <t>This document defines a new CSR 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 additional assurance that two certificates each belong to the same end entity.  This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms.
	  </t>
    </abstract>
  </front>

  <middle>

    <section numbered="true" toc="default">
      <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>
      <t>When using non-composite hybrid public key mechanisms, the party relying 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 extension, RelatedCertificate, that signals that the certificate containing the extension is able to be used in combination with the other specified certificate.
      </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 will use) that is asked to issue a certificate with such an extension may want assurance from a registration authority (RA) that the private keys (for (corresponding to, for example, corresponding to two public keys: one in an extant certificate, certificate and one in a current request) belong to the same entity.  To facilitate this, a CSR attribute is defined, attribute, called relatedCertRequest, that permits is defined to permit an RA to make such an assertion.
      </t>

    <section numbered="true" toc="default">
      <name>Overview</name>
      <t> The general roadmap of this design is best illustrated via an entity (device, (e.g., a device, service, user token, etc.) token) that has an existing certificate (Cert A) and requests a new certificate (Cert B), perhaps as part of an organization's transition strategy to migrate their PKI from traditional cryptography to PQC. post-quantum cryptography (PQC).
	  </t>
	  <ul spacing="normal">
		  <!-- [rmg] Making several clarifications throughout text (as seen in the bullet below) with the use of 'validation' for certificates and 'verification' for signatures.
		  -->
		  <li> For protocols where authentication is not negotiated, and rather negotiated but instead is limited by what the signer offers, such as in CMS Cryptographic 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 which validators verifiers the signer anticipates.
		  </li>
		  <li> For protocols where authentication is negotiated in-protocol, such as TLS and IKEv2, Internet Key Exchange Protocol Version 2 (IKEv2), either Cert A or Cert B's signing key may be invoked, according to the preference of the validator. verifier.  If the protocol is enabled to do so, peers may request that both Cert A and Cert B are used for authentication.
		  </li>
		</ul>
	  <t> A validator verifier that prefers multiple authentication types may be assisted by the inclusion of relevant information in one of the signer's certificate, 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.  This document describes a certificate request attribute and certificate extension that provide such assurance.</t>
	  <t>
	  To support this concept, this document defines a new CSR attribute, relatedCertRequest, which contains information on how to locate a previously-issued 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 information to locate Cert A, A and then verifies ownership before generating the new certificate, Cert B.
	  </t>
	</section>
	</section>

    <section numbered="true" toc="default">
      <name>Requirements Language</name>
      <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119" format="default"/>. target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>

    <section numbered="true" toc="default">
      <name>CSR and Related Certificates</name>

      <section numbered="true" toc="default"> toc="default" anchor="related-cert-request">
	<name>The relatedCertRequest Attribute</name>
	<t>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
	public key associated with the end-entity certificate identified in
	this attribute.  The relatedCertRequest attribute indicates the
	location of a previously issued certificate that the end-entity end entity owns
	and wants identified in the new certificate requested through the CSR.
		</t>
	CSR.</t>
	<t>The relatedCertRequest attribute has the following syntax:
        </t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
relatedCertRequest syntax:</t>

		<sourcecode type="asn.1"><![CDATA[
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }

aa-relatedCertRequest ATTRIBUTE ::= {
    WITH SYNTAX
    TYPE RequesterCertificate
    ID { TBD1 }
}
    IDENTIFIED BY id-aa-relatedCertRequest}

RequesterCertificate ::= SEQUENCE {
   certID        IssuerAndSerialNumber,
   requestTime   BinaryTime,
   locationInfo  UniformResourceIdentifier,
   signature     BIT STRING }

]]></artwork>
]]></sourcecode>

<!-- [rmg] Russ Housley identified an inconsistency with how the ASN.1 was written here vs. in the module. Updated for consistency.-->

	<t>The RequesterCertificate type has four fields:
		</t> fields:</t>
	<ul spacing="normal">
		  <li>The  <!--Level 1 -->
	  <li><t>The certID field uses the IssuerAndSerialNumber type <xref
	  target="RFC5652" format="default"/> to identify a previously issued
	  end-entity certificate that the requesting entity also
	  owns.  IssuerAndSerialNumber is repeated here for convenience: </li>
		</ul>

<artwork name="" type="" align="left" alt=""><![CDATA[ convenience:</t>

<sourcecode type="asn.1"><![CDATA[
IssuerAndSerialNumber ::= SEQUENCE {
        issuer       Name,
        serialNumber CertificateSerialNumber }

CertificateSerialNumber ::= INTEGER
]]></artwork>

		<ul spacing="normal">
		  <li>The
]]></sourcecode>
	  </li>
	  <li><t>The requestTime field uses the BinaryTime type <xref
	  target="RFC6019" format="default"/> in order 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 synchronize time is
	  outside the scope of this document.  BinaryTime is repeated here for
	  convenience: </li>
        </ul>

<artwork name="" type="" align="left" alt=""><![CDATA[ </t>

<sourcecode type="asn.1"><![CDATA[
BinaryTime ::= INTEGER (0..MAX)
]]></artwork>

		  <ul spacing="normal">
		  <li>The
]]></sourcecode>

	  </li>
	  <li><t>The locationInfo field uses UniformResourceIdentifier to
	  provide information on the location of the other certificate the
	  requesting entity owns. We define  UniformResourceIdentifier as: </li>
		  </ul>

<artwork name="" type="" align="left" alt=""><![CDATA[ is defined as:</t>

<sourcecode type="asn.1"><![CDATA[
UniformResourceIdentifier ::= IA5String
]]></artwork>

		   <t> The
]]></sourcecode>

	    <t>The UniformResourceIdentifier is a pointer to a location via HTTP/HTTPS,
	    HTTP(S) or a dataURI.  This field can contain one of two
	    acceptable values:</t>
	    <ul spacing="normal">
		  <li>

			<t> - If  <!-- Nest 1 -->
	      <li>If the request for (new) Cert B is to the same CA
	      organization as that also issued (existing) Cert A, then the
	      UniformResourceIdentifier value SHOULD <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 X.509 certificate, end-entity
	      certificate or the entire certificate chain. In this case, preference for a URL keeps the  This option uses less data limit smaller than using a dataURI.  All certificates contained must be DER encoded. </t>

			<t> - If encoded.</li>

	      <li>If the request for (new) Cert B is to a CA organization
	      different to than the CA organization that issued the certificate
	      (existing) Cert A referenced in the CSR, then the
	      UniformResourceIdentifier value SHOULD <bcp14>SHOULD</bcp14> be a
	      dataURI <xref target="RFC2397" format="default"/> containing
	      inline degenerate PKCS#7 (see Sections 3.2.1, <xref target="RFC8551" section="3.2.1" sectionFormat="bare"/> and 3.8 <xref target="RFC8551" section="3.8" sectionFormat="bare"/> of <xref
	      target="RFC8551" format="default"/>) consisting of all the
	      certificates and CRLs required to validate Cert A.  This allows validation without
	      the CA to perform validation (as described in <xref target="CSR-proc"/>) 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 -->

</li>

<!-- [mjj] The following contained the original text "request time and IssuerAndSerialNumber". This has been changed to "IssuerandSerialNumber and BinaryTime". This was done to agree with the type names and order of the fields in the attribute, and to agree with the concatenation order from the third paragraph of Section 5.  </t>
		  </li>
		  </ul>
		  <ul spacing="normal">
		  <li>
			<t>The There is no security implication to the order, it simply must be consistent.-->

	  <li><t>The signature field provides evidence that the requesting
	    entity owns the certificate indicated by the certID. certID field.
	    Specifically, the signature field contains a digital signature
	    over the concatenation of DER encoded requestTime DER-encoded IssuerAndSerialNumber and IssuerAndSerialNumber. BinaryTime.  The concatenated value is signed using the
	    signature algorithm and private key associated with the
	    certificate identified by the certID field. </t>

			<t>- If field.</t>
	    <ul spacing="normal">  <!-- Nest 2 -->
	      <li>If the related certificate is a key establishment
	      certificate (e.g., using RSA key transport or ECC Elliptic Curve
	      Cryptography (ECC) key
	      agreement), use the private key is used to sign one time for POP proof of
	      possession (POP) (as
	      detailed in NIST SP 800-57 Part 1 Rev 5 Section 8.1.5.1.1.2) </t> 8.1.5.1.1.2 of <xref target="NIST-SP-800-57"/>).
	      </li>
	    </ul>  <!-- End Nest 2 -->
	    <t>The validation verification of this signature by the CA ensures that the
	    owner of the CSR also owns the certificate indicated in the
	    relatedCertRequest attribute. </t> attribute.</t>
      </li>
     </ul>  <!-- End Level 1 -->
	  </section>

	  <section numbered="true" toc="default"> toc="default" anchor="CSR-proc">
	    <name>CSR Processing</name>
	    <t>The information provided in the relatedCertRequest attribute
	    allows the CA to locate a previously issued certificate that the
	    requesting entity owns, and verify confirm ownership by using the public
	    key in that certificate to validate verify the signature in the
	    relatedCertRequest attribute.
	    </t>
	    <t> If a CA receives a CSR that includes the relatedCertRequest attribute and that CA supports the attribute, the CA:
		</t>
		<ul spacing="normal">
		  <li> MUST <bcp14>MUST</bcp14> retrieve the certificate identified in the relatedCertRequest attribute using the information provided in UniformResourceIdentifier, and validate it using certificate path validation rules defined in <xref target="RFC5280" format="default"/>.  The CA then extracts the IssuerAndSerialNumber from the indicated certificate and compares this value against the IssuerAndSerialNumber provided in the certID field of relatedCertRequest.  </li>
		  <li>MUST relatedCertRequest.</li>
		  <li><bcp14>MUST</bcp14> check that the BinaryTime indicated in the requestTime field is sufficiently fresh.  Note that sufficient freshness is defined by local policy and is out of the scope of this document. </li>
		  <li>MUST document.</li>
		  <li><bcp14>MUST</bcp14> verify the signature field of the relatedCertRequest attribute.  The CA validates verifies the signature using the public key associated with the certificate it located via the info provided in identified by the UniformResourceIdentifier field. relatedCertRequest attribute.  The details of the validation verification process are outside the scope of this document. </li>
		  <li>SHOULD document.</li>
		  <li><bcp14>SHOULD</bcp14> issue the new certificate containing the RelatedCertificate extension as specified in Section 4, <xref target="related-certificate"/>, which references the certificate indicated in the attribute's IssuerAndSerialNumber field.  The CA may also apply local policy regarding the suitability of the related certificate, such as validity period remaining.</li>
		</ul>

		<t>The RA MUST <bcp14>MUST</bcp14> only allow a previously-issued previously issued certificate to be indicated in the relatedCertRequest attribute in order to enable the CA to perform the required signature verification.
        </t>
        <t>The RA MAY <bcp14>MAY</bcp14> send the CA a CSR containing a relatedCertRequest attribute that includes the IssuerAndSerialNumber of a certificate that was issued by a different CA.
		</t>

	  </section>

	</section>

	<section numbered="true" toc="default"> toc="default" anchor="related-certificate">
	  <name>Related Certificate</name>

	  <section numbered="true" toc="default">
	    <name>The RelatedCertificate Extension</name>
	    <t>This section profiles specifies a new X.509v3 X.509 certificate extension,
	    RelatedCertificate.  RelatedCertificate creates an association
	    between the certificate containing the RelatedCertificate
	    extension (Cert B) and the certificate referenced within the
	    extension (Cert A).  When two end-entity certificates are used in
	    a protocol, where one of the certificates contains a
	    RelatedCertificate extension that references another the other certificate,
	    the authenticating entity is provided with additional assurance
	    that all certificates both <!-- [rmg] "all" changed to "both" (accidental artifact from earlier version of draft)-->certificates belong to the same entity.
            </t>
            <t>The RelatedCertificate extension is an octet string that contains the hash of a single end-entity certificate. certificate.<!-- [rmg] This line was also updated in alignment with the update described below. -->
            </t>
            <t>The RelatedCertificate extension has the following syntax:
	    </t>
	    <artwork name="" type="" align="left" alt=""><![CDATA[

--  Object Identifiers for certificate extension
  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 }

	  ]]></artwork>
		<t>The

      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.
		</t>
        <t>This

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 original text to reduce bandwidth [1], without consideration for the issue that was identified later. Subsequent consideration of the issue resulted in a reversion back 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/, paragraph 5
[2] https://mailarchive.ietf.org/arch/msg/spasm/svteav5feg-q0xGP9yvm_LvsM68/ - the thread goes beyond this email but the outcome was confirmed and did not change.

[rmg] Also made a change to the ASN.1 module in the Appendix to RelatedCertificate.
-->

<!--[rfced note] Per author request, updated the RelatedCertificate
extension syntax (Section 4.1) - 4/9/25
-->

	    <sourcecode type="asn.1"><![CDATA[
--  Object Identifier for certificate extension
  id-relatedCert OBJECT IDENTIFIER ::= { 36 }

--  X.509 Certificate extension
  RelatedCertificate ::= SEQUENCE {
       hashAlgorithm DigestAlgorithmIdentifier,
       hashValue     OCTET STRING }
]]></sourcecode>

		<t>The extension is a SEQUENCE of two fields.  The hashAlgorithm field identifies the hash algorithm used to compute hashValue, which is the digest value obtained from hashing the entire related certificate identified in the relatedCertRequest CSR attribute defined above.  If there is a hash algorithm explicitly indicated by the related certificate's signature OID (e.g., ecdsa-with-SHA512), that hash algorithm SHOULD NOT be also used for this extension.</t>

<!-- [mjj] End revision.
-->

        <t>This extension <bcp14>SHOULD NOT</bcp14> be marked critical.  Marking this extension critical would severely impact interoperability.
        </t>
        <t>For certificate chains, this extension MUST <bcp14>MUST</bcp14> only be included in the end-entity certificate.
        </t>
        <t>For the RelatedCertificate extension to be meaningful, a CA that issues a certificate with this extension:
		</t>
        <ul spacing="normal">
		  <li>MUST
		  <li><bcp14>MUST</bcp14> only include a certificate in the extension that is listed and validated in the relatedCertRequest attribute of the CSR submitted by the requesting entity.</li>
		  <li>MUST
		  <!-- [rmg] "and validated" was removed from the above sentence because it is redundant and imprecise in the context of the sentence. It has already been required to have been validated, and the inclusion of "and validated" in the above sentence made it sound like the relatedCertRequest attribute itself validates it, which is inaccurate. -->
		  <li><bcp14>MUST</bcp14> ensure that the related certificate at least contains the KU key usage (KU) bits and EKU extended key usage (EKU) OIDs <xref target="RFC5280" format="default"/> being asserted in the certificate being issued.  </li>
		  <li>SHOULD issued.</li>
		  <li><bcp14>SHOULD</bcp14> determine that all certificates are the related certificate is valid at the time of issuance.  issuance.  The usable overlap of with the validity periods period of the newly issued certificate is a Subscriber concern.</li>
        </ul>
	  </section>

	  <section numbered="true" toc="default">
	    <name>Endpoint Protocol Multiple Authentication Processing</name>
		<t>
		When the preference to use a non-composite hybrid authentication mode is expressed by an endpoint through the protocol itself (e.g., during negotiation), the use of the RelatedCertificate extension and its enforcement are left to the protocol's native existing authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection).
        </t>
        <t>If an endpoint has indicated that it is willing to do supports non-composite hybrid authentication and receives the appropriate authentication data, it should check end-entity certificates (Cert A and Cert B) for the RelatedCertificate extension.  If present in one certificate, for example certificate (e.g., Cert B, B), it should:
		</t>
		<ul spacing="normal">
		  <li>Compute the appropriate hash of Cert A, the other end-entity certificate received. The hash algorithm is received.</li>
		  <!--[rmg] Deleted the same as the one used to sign second sentence of the certificate containing above bullet since it is addressed in the extension.  </li>
		  <li>Verify modification made to RelatedCertificate in Section 4.1.
		  -->
		  <li>Confirm that the hash value matches the hash entry in the RelatedCertificate extension of Cert B. </li> B.</li>
		</ul>
		<t>It is outside the scope of this document how
		<t>How to proceed with authentication based on the outcome of this verification process. process is outside the scope of this document.  Different determinations may be made depending on each peer's policy regarding whether both or at least one authentication needs to succeed.
		</t>

	  </section>

	</section>
 	<section numbered="true" toc="default"> toc="default" anchor="use-case">
		<name> Use Case </name>
		<t>
        The general design of this method is best illustrated through specific use within a migration strategy to PQ cryptography PQC via a non-composite hybrid authentication mechanism.  The intent is for a CA issuing a new, PQ post-quantum (PQ) certificate to add an X.509 extension that provides information about a previously-issued, previously issued, traditional certificate in which the private key is controlled by the same end entity as the PQ certificate.
		</t>
		<t>
		In the following scenario, an entity currently has a traditional certificate, certificate and is requesting requests that a new, PQ certificate be issued with the containing a RelatedCertificate extension included that extension, which references the entity's traditional certificate.
        </t>
		<t>
		The RA receives a CSR for a PQ certificate, where the CSR includes the relatedCertRequest attribute detailed in this document.  The relatedCertRequest attribute includes a certID field that identifies the entity's previously-issued previously issued traditional certificate, certificate and a signature field in which the requesting entity produces a digital signature over the certID concatenation of the IssuerAndSerialNumber and a timestamp, BinaryTime, using the private key of the certificate identified by the certID. IssuerAndSerialNumber.
		</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 the private key of the referenced, previously-issued previously issued traditional certificate.
		</t>
		<t>
		Upon receipt and validation of the CSR, the CA issues a PQ certificate to the requesting entity that includes the RelatedCertificate extension detailed 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 end-entity ownership.
		</t>
		<t>
		The attribute and subsequent extension together provide assurance from the CA organization that the same end-entity end entity controls the private keys of both certificates.  certificates.  It is neither a requirement nor a 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 control of the same entity.
		</t>
	</section>
	<section anchor="CAconsiderations" numbered="true" toc="default">
	  <name>CA Organization Considerations</name>
	  <t>
	  The relatedCertRequest CSR attribute provides assertion to the CA organization issuing Cert B, of end entity asserts end-entity control of the private key of associated with a related certificate, Cert A. There may arise scenarios where certificate (Cert A) to the CA organization issuing a new certificate (Cert B).  A public-facing CA organization is may not be configured to validate signatures associated with certificates that have been issued by a different CA organization. organizations.  In this case, recognition of the contents in the relatedCertRequest attribute may be contingent upon necessitate pre-arrangement, e.g., a pre-arranged contract with pre-configured trust anchors from the other another CA organization, organization and include agreements on certificate policy with regards to regarding policies concerning certificate application, issuance, and acceptance. Further, matching policies between CA organizations 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>
	  In a similar vein, if the CA organization issuing the PQ certificate can recognize the relatedCertRequest attribute in the CSR and wishes to issue the certificate
	  Continuing with this scenario, in order for 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 Cert B is issued under homogeneous sets of security parameters, parameters comparable to Cert A, the certificate policies issuing CA organization should be match the same with regard issued certification policies to common security requirements. the related ones.  The issuing CA, CA organization, as part of related certificate public key validation, determines its validation of Cert A, ascertains what policies are acceptable for the asserted in Cert A’s certification path of the related certificate. The issuing CA and determines what is acceptable to them in terms which of certificate policy, to their own certification policies will best ensure that the policies for protection of the private key are sufficient. associated with Cert B is comparable to that of Cert A.  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.
      </t>

	</section>

	<section anchor="Security" numbered="true" toc="default">
	  <name>Security Considerations</name>
	  <t>
	  This document inherits security considerations identified in <xref target="RFC5280" format="default"/>.
      </t>
      <t>The mechanisms described in this document provide only a means to express that multiple certificates are related.  They are intended for the interpretation of the recipient of the data in which they are embedded (i.e. (i.e., a CSR or certificate).  They do not by themselves effect any security function.
      </t>
      <t>Authentication, unlike key establishment, is necessarily a one-way arrangement.  That is, authentication is an assertion made by a claimant to a verifier.

      The means and strength of mechanism for the authentication mechanism have to be satisfactory to the satisfaction of the verifier.  A system security designer needs to be aware of what authentication assurances are needed in various parts of the system and how to achieve that assurance.  In a closed system (e.g. (e.g., Company X distributing firmware to its own devices) devices), the approach may be implicit.  In an online protocol like IPsec where the peers are generally known, any mechanism selected from a pre-established set may be sufficient.

      For more promiscuous online protocols, protocols like TLS, the ability for the verifier to express what is possible and what is preferred - -- and to assess that it got what it needed - its requirements were met -- is important.
      </t>
      <t>A certificate is an assertion of binding between an identity and a public key.  However, that assertion is based on several other assurances, specifically, especially that the identity belongs to a particular physical entity, entity and that that the physical entity has control over the private key corresponding to the public. 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 registration (to the CA).
      </t>
      <t>All hybrid implementations are vulnerable to a downgrade attack in which a malicious peer does not express support for the stronger algorithm, resulting in an exchange that can only rely upon a weaker algorithm for security.
	  </t>
	  <t>
	  Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedCertRequest CSR attribute, if the URI points as a URL can point to malicious code.  Implementors should ensure the data is properly formed and validate the retrieved data fully.
	  </t>
	  <t>

	  CAs should be aware that retrieval of existing certificates may be subject to observation; if this is a concern, it may be is advisable to use the dataURI option described in Section 3.1. <xref target="related-cert-request"/>.
	  </t>
	</section>

    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This document defines an extension for use with X.509 certificates.  IANA is requested to register has registered the following OID in the SMI "SMI Security for PKIX Certificate Extension registry:
      </t>
<artwork name="" type="" Extension" registry (1.3.6.1.5.5.7.1):
      </t>

      <table align="center">
        <thead>
          <tr>
            <th align="left" alt=""><![CDATA[
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 }
]]></artwork>

      <t>with this document as the 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 Specification. <xref target="RFC8126"/>.
      </t>
	  <t>This document defines a CSR attribute.  IANA is requested to register has registered the following OID in the SMI "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry:
      </t>
<artwork name="" type=""

      <table align="center">
        <thead>
          <tr>
            <th align="left" alt=""><![CDATA[
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 }
]]></artwork> 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">60</td>
            <td align="left" colspan="1" rowspan="1">id-aa-relatedCertRequest</td>
	    <td align="left" colspan="1" rowspan="1">RFC 9763</td>
          </tr>
        </tbody>
      </table>

		<t> This document defines an ASN.1 Module module in Appendix A. <xref target="app-additional"/>.  IANA is requested to register an has registered the following  OID for the module identifier in the SMI "SMI Security for PKIX Module Identifier registry:
		</t>
<artwork name="" type="" Identifier" registry (1.3.6.1.5.5.7.0):
		</t>

		<table align="center">

        <thead>
          <tr>
            <th align="left" alt=""><![CDATA[
id-mod-related-cert(TBD0)
]]></artwork>
    <t> The RFC Editor is requested to replace the TBDs in the text with the assigned OIDs.</t> 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</td>
	    <td align="left" colspan="1" rowspan="1">RFC 9763</td>
          </tr>
        </tbody>
      </table>

	</section>

  </middle>

 <back>

   <references>
      <name>References</name>
	  <references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2397.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2397.xml"/>

	  </references>
	  <references>
	    <name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

<reference anchor="NIST-SP-800-57" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/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>

    <section anchor="app-additional" numbered="true" toc="default">
      <name>ASN.1 Module</name>

      <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"/>,
      format="default"/> and <xref target="RFC6268" format="default"/>, format="default"/> for the IssuerAndSerialNumber type and in <xref target="RFC6019" format="default"/> for the IssuerAndSerialNumber type, and BinaryTime type, respectively. </t>

<artwork name="" type="" align="left" alt=""><![CDATA[ type.</t>

<!--[rfced note]: Updated ASN.1 module per authors on 4/9/25-->

<sourcecode type="asn.1"><![CDATA[
RelatedCertificate { iso(1) identified-organization(3) dod(6)
  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 ::=
BEGIN

IMPORTS

  ATTRIBUTE, EXTENSION
         FROM PKIX-CommonTypes-2009  -- in [RFC5912] RFC 5912
         { iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) pkix(7) id-mod(0)
               id-mod-pkixCommon-02(57) }

   IssuerAndSerialNumber

  IssuerAndSerialNumber, DigestAlgorithmIdentifier
         FROM CryptographicMessageSyntax-2010 -- in [RFC6268] RFC 6268
         { iso(1) member-body(2) us(840) rsadsi(113549)
               pkcs(1) pkcs-9(9) smime(16) modules(0)
               id-mod-cms-2009(58) }

  BinaryTime
         FROM BinarySigningTimeModule -- in [RFC6019] RFC 6019
         { iso(1) member-body(2) us(840) rsadsi(113549)
               pkcs(1) pkcs-9(9) smime(16) modules(0)
               id-mod-binarySigningTime(27) } ;

-- Object identifier arcs

id-pe OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }

id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) 2 }

-- relatedCertificate Extension

id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 36 }

RelatedCertificate ::= SEQUENCE {
  hashAlgorithm DigestAlgorithmIdentifier,
  hashValue     OCTET STRING }

ext-relatedCertificate EXTENSION ::= {
  SYNTAX RelatedCertificate
  IDENTIFIED BY id-pe-relatedCert }

-- relatedCertRequest Attribute

id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 60 }

RequesterCertificate ::= SEQUENCE {
  certID        IssuerAndSerialNumber,
  requestTime   BinaryTime,
  locationInfo  UniformResourceIdentifier,  UniformResourceIdentifiers,
  signature     BIT STRING }

UniformResourceIdentifier

UniformResourceIdentifiers ::= SEQUENCE SIZE (1..MAX) OF URI

URI ::= IA5String

aa-relatedCertRequest ATTRIBUTE ::= {
  TYPE RequesterCertificate
  IDENTIFIED BY id-aa-relatedCertRequest }

END
]]></artwork>
]]></sourcecode>

    </section>

<!-- [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#table1>
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>
</rfc>