<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" consensus="true" prepTime="2025-06-13T16:23:03" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-cert-binding-for-multi-auth-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9763" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Related Certificates for Protocol Authentications">Related Certificates for Use in Multiple Authentications within a Protocol</title>
    <seriesInfo name="RFC" value="9763" stream="IETF"/>
    <author fullname="Alison Becker" initials="A." surname="Becker">
      <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
      <address>
        <email>aebecke@uwe.nsa.gov</email>
      </address>
    </author>
    <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
      <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
      <address>
        <email>rmguthr@uwe.nsa.gov</email>
      </address>
    </author>
    <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
      <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9763" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-and-related-certificate">CSR and Related Certificates</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-relatedcertrequest-attr">The relatedCertRequest Attribute</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-processing">CSR Processing</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-related-certificate">Related Certificate</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-relatedcertificate-exte">The RelatedCertificate Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endpoint-protocol-multiple-">Endpoint Protocol Multiple Authentication Processing</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case"> Use Case </xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ca-organization-considerati">CA Organization Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-module">ASN.1 Module</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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" sectionFormat="of" derivedContent="RFC5280"/> and to current PKI best practices.
      </t>
      <t indent="0" pn="section-1-2">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 indent="0" pn="section-1-3">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 (corresponding to, for example, two public keys: one in an extant certificate and one in a current request) belong to the same entity.  To facilitate this, a CSR attribute, called relatedCertRequest, is defined to permit an RA to make such an assertion.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-overview">Overview</name>
        <t indent="0" pn="section-1.1-1"> 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) and requests a new certificate (Cert B), perhaps as part of an organization's transition strategy to migrate their PKI from traditional cryptography to post-quantum cryptography (PQC).
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2">
          <li pn="section-1.1-2.1"> For protocols where authentication is not negotiated but instead is limited by what the signer offers, such as in 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 verifiers the signer anticipates.
		  </li>
          <li pn="section-1.1-2.2"> For protocols where authentication is negotiated in-protocol, such as TLS and 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 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 indent="0" pn="section-1.1-3"> A verifier that prefers multiple authentication types may be assisted 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.  This document describes a certificate request attribute and certificate extension that provide such assurance.</t>
        <t indent="0" pn="section-1.1-4">
	  To support this concept, this document defines a new CSR attribute, relatedCertRequest, 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 information to locate Cert A and then verifies ownership before generating the new certificate, Cert B.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-csr-and-related-certificate">CSR and Related Certificates</name>
      <section numbered="true" toc="include" anchor="related-cert-request" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-the-relatedcertrequest-attr">The relatedCertRequest Attribute</name>
        <t indent="0" pn="section-3.1-1">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 owns
	and wants identified in the new certificate requested through the
	CSR.</t>
        <t indent="0" pn="section-3.1-2">The relatedCertRequest attribute has the following syntax:</t>
        <sourcecode type="asn.1" markers="false" pn="section-3.1-3">
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }

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

RequesterCertificate ::= SEQUENCE {
   certID        IssuerAndSerialNumber,
   requestTime   BinaryTime,
   locationInfo  UniformResourceIdentifier,
   signature     BIT STRING }
</sourcecode>
        <t indent="0" pn="section-3.1-4">The RequesterCertificate type has four fields:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-5">
          <li pn="section-3.1-5.1">
            <t indent="0" pn="section-3.1-5.1.1">The certID field uses the IssuerAndSerialNumber type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> to identify a previously issued
	  end-entity certificate that the requesting entity also
	  owns.  IssuerAndSerialNumber is repeated here for convenience:</t>
            <sourcecode type="asn.1" markers="false" pn="section-3.1-5.1.2">
IssuerAndSerialNumber ::= SEQUENCE {
        issuer       Name,
        serialNumber CertificateSerialNumber }

CertificateSerialNumber ::= INTEGER
</sourcecode>
          </li>
          <li pn="section-3.1-5.2">
            <t indent="0" pn="section-3.1-5.2.1">The requestTime field uses the BinaryTime type <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/> 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: </t>
            <sourcecode type="asn.1" markers="false" pn="section-3.1-5.2.2">
BinaryTime ::= INTEGER (0..MAX)
</sourcecode>
          </li>
          <li pn="section-3.1-5.3">
            <t indent="0" pn="section-3.1-5.3.1">The locationInfo field uses UniformResourceIdentifier to
	  provide information on the location of the other certificate the
	  requesting entity owns.  UniformResourceIdentifier is defined as:</t>
            <sourcecode type="asn.1" markers="false" pn="section-3.1-5.3.2">
UniformResourceIdentifier ::= IA5String
</sourcecode>
            <t indent="0" pn="section-3.1-5.3.3">The UniformResourceIdentifier is a pointer to a location via
	    HTTP(S) or a data URL.  This field can contain one of two
	    acceptable values:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-5.3.4">
              <li pn="section-3.1-5.3.4.1">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" sectionFormat="of" derivedContent="RFC5280"/>; 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 data URL.  All certificates contained must be DER encoded.</li>
              <li pn="section-3.1-5.3.4.2">If the request for (new) Cert B is to a CA organization
	      different than the CA organization that issued the certificate
	      (existing) Cert A referenced in the CSR, then the
	      UniformResourceIdentifier value <bcp14>SHOULD</bcp14> be a
	      data URL <xref target="RFC2397" format="default" sectionFormat="of" derivedContent="RFC2397"/> containing
	      inline degenerate PKCS#7 (see Sections <xref target="RFC8551" section="3.2.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8551#section-3.2.1" derivedContent="RFC8551"/> and <xref target="RFC8551" section="3.8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8551#section-3.8" derivedContent="RFC8551"/> of <xref target="RFC8551" format="default" sectionFormat="of" derivedContent="RFC8551"/>) 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-proc" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) without
		  having to retrieve certificates/CRLs from another CA.  Further
		  discussion of requirements for this scenario is in <xref target="use-case" format="default" sectionFormat="of" derivedContent="Section 5"/>.</li>
            </ul>
          </li>
          <li pn="section-3.1-5.4">
            <t indent="0" pn="section-3.1-5.4.1">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 BinaryTime.  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" bare="false" empty="false" indent="3" pn="section-3.1-5.4.2">
              <li pn="section-3.1-5.4.2.1">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" format="default" sectionFormat="of" derivedContent="NIST-SP-800-57"/>).
	      </li>
            </ul>
            <t indent="0" pn="section-3.1-5.4.3">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>
      </section>
      <section numbered="true" toc="include" anchor="CSR-proc" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-csr-processing">CSR Processing</name>
        <t indent="0" pn="section-3.2-1">The information provided in the relatedCertRequest attribute
	    allows the CA to locate a previously issued certificate that the
	    requesting entity owns, and confirm ownership by using the public
	    key in that certificate to verify the signature in the
	    relatedCertRequest attribute.
        </t>
        <t indent="0" pn="section-3.2-2"> If a CA receives a CSR that includes the relatedCertRequest attribute and that CA supports the attribute, the CA: 
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-3">
          <li pn="section-3.2-3.1">
            <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" sectionFormat="of" derivedContent="RFC5280"/>.  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 pn="section-3.2-3.2">
            <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 pn="section-3.2-3.3">
            <bcp14>MUST</bcp14> verify the signature field of the relatedCertRequest attribute.  The CA verifies the signature using the public key associated with the certificate identified by the relatedCertRequest attribute.  The details of the verification process are outside the scope of this document.</li>
          <li pn="section-3.2-3.4">
            <bcp14>SHOULD</bcp14> issue the new certificate containing the RelatedCertificate extension as specified in <xref target="related-certificate" format="default" sectionFormat="of" derivedContent="Section 4"/>, 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 indent="0" pn="section-3.2-4">The RA <bcp14>MUST</bcp14> only allow a previously issued certificate to be indicated in the relatedCertRequest attribute in order to enable the CA to perform the required signature verification.
        </t>
        <t indent="0" pn="section-3.2-5">The RA <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="include" anchor="related-certificate" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-related-certificate">Related Certificate</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-the-relatedcertificate-exte">The RelatedCertificate Extension</name>
        <t indent="0" pn="section-4.1-1">This section specifies a new 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 the other certificate,
	    the authenticating entity is provided with additional assurance
	    that both certificates belong to the same entity.
        </t>
        <t indent="0" pn="section-4.1-2">The RelatedCertificate extension contains the hash of a single end-entity certificate.
        </t>
        <t indent="0" pn="section-4.1-3">The RelatedCertificate extension has the following syntax:
        </t>
        <sourcecode type="asn.1" markers="false" pn="section-4.1-4">
--  Object Identifier for certificate extension
  id-relatedCert OBJECT IDENTIFIER ::= { 36 }

--  X.509 Certificate extension
  RelatedCertificate ::= SEQUENCE {
       hashAlgorithm DigestAlgorithmIdentifier,
       hashValue     OCTET STRING }
</sourcecode>
        <t indent="0" pn="section-4.1-5">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 <bcp14>SHOULD</bcp14> also be used for this extension.</t>
        <t indent="0" pn="section-4.1-6">This extension <bcp14>SHOULD NOT</bcp14> be marked critical.  Marking this extension critical would severely impact interoperability.
        </t>
        <t indent="0" pn="section-4.1-7">For certificate chains, this extension <bcp14>MUST</bcp14> only be included in the end-entity certificate.
        </t>
        <t indent="0" pn="section-4.1-8">For the RelatedCertificate extension to be meaningful, a CA that issues a certificate with this extension:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-9">
          <li pn="section-4.1-9.1">
            <bcp14>MUST</bcp14> only include a certificate in the extension that is listed in the relatedCertRequest attribute of the CSR submitted by the requesting entity.</li>
          <li pn="section-4.1-9.2">
            <bcp14>MUST</bcp14> ensure that the related certificate contains the key usage (KU) bits and extended key usage (EKU) OIDs <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> being asserted in the certificate being issued.</li>
          <li pn="section-4.1-9.3">
            <bcp14>SHOULD</bcp14> determine that the related certificate 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>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-endpoint-protocol-multiple-">Endpoint Protocol Multiple Authentication Processing</name>
        <t indent="0" pn="section-4.2-1">
		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 existing authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection).
        </t>
        <t indent="0" pn="section-4.2-2">If an endpoint has indicated that it 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 (e.g., Cert B), it should:  
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-3">
          <li pn="section-4.2-3.1">Compute the appropriate hash of Cert A, the other end-entity certificate received.</li>
          <li pn="section-4.2-3.2">Confirm that the hash value matches the hash entry in the RelatedCertificate extension of Cert B.</li>
        </ul>
        <t indent="0" pn="section-4.2-4">How to proceed with authentication based on the outcome of this 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="include" anchor="use-case" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-use-case"> Use Case </name>
      <t indent="0" pn="section-5-1"> 
        The general design of this method is best illustrated through specific use 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, traditional certificate in which the private key is controlled by the same end entity as the PQ certificate.
      </t>
      <t indent="0" pn="section-5-2"> 
		In the following scenario, an entity currently has a traditional certificate and requests that a new, PQ certificate be issued containing a RelatedCertificate extension, which references the entity's traditional certificate.
      </t>
      <t indent="0" pn="section-5-3">
		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 traditional certificate and a signature field in which the requesting entity produces a digital signature over the concatenation of the IssuerAndSerialNumber and BinaryTime, using the private key of the certificate identified by the IssuerAndSerialNumber.
      </t>
      <t indent="0" pn="section-5-4"> 
		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 traditional certificate.
      </t>
      <t indent="0" pn="section-5-5">
		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 indent="0" pn="section-5-6">
		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 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="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-ca-organization-considerati">CA Organization Considerations</name>
      <t indent="0" pn="section-6-1">
	  The relatedCertRequest CSR attribute asserts end-entity control of the private key associated with a related certificate (Cert A) to the CA organization issuing a new certificate (Cert B).  A public-facing CA organization may not be configured to validate certificates that have been issued by different CA organizations.  In this case, recognition of the contents in the relatedCertRequest attribute may necessitate pre-arrangement, e.g., a contract with pre-configured trust anchors from another CA organization and agreements regarding policies concerning certificate application, issuance, and acceptance.
      </t>
      <t indent="0" pn="section-6-2">
	  Continuing with this scenario, in order for the CA organization to ensure that Cert B is issued under security parameters comparable to Cert A, the issuing CA organization should match the issued certification policies to the related ones.  The issuing CA organization, as part of its validation of Cert A, ascertains what policies are asserted in Cert A's certification path and determines which of their own certification policies will best ensure that the protection of the private key 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="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">
	  This document inherits security considerations identified in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.
      </t>
      <t indent="0" pn="section-7-2">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., a CSR or certificate).  They do not by themselves effect any security function.
      </t>
      <t indent="0" pn="section-7-3">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 the authentication mechanism have to be satisfactory to 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., Company X distributing firmware to its own 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 like TLS, the ability for the verifier to express what is possible and what is preferred -- and to assess that its requirements were met -- is important.
      </t>
      <t indent="0" pn="section-7-4">A certificate is an assertion of binding between an identity and a public key.  However, that assertion is based on several other assurances, especially that the identity belongs to a particular physical entity and that the physical 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 registration (to the CA).
      </t>
      <t indent="0" pn="section-7-5">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 indent="0" pn="section-7-6">
	  Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedCertRequest CSR attribute, as a URL can point to malicious code.  Implementors should ensure the data is properly formed and validate the retrieved data fully.
      </t>
      <t indent="0" pn="section-7-7">
	    
	  CAs should be aware that retrieval of existing certificates may be subject to observation; if this is a concern, it is advisable to use the data URL option described in <xref target="related-cert-request" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document defines an extension for use with X.509 certificates.  IANA has registered the following OID in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1): 
      </t>
      <table align="center" pn="table-1">
        <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 indent="0" pn="section-8-3">The registration procedure is Specification Required <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
      </t>
      <t indent="0" pn="section-8-4">This document defines a CSR attribute.  IANA has registered the following OID in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry:
      </t>
      <table align="center" pn="table-2">
        <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">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 indent="0" pn="section-8-6"> This document defines an ASN.1 module in <xref target="app-additional" format="default" sectionFormat="of" derivedContent="Appendix A"/>.  IANA has registered the following  OID for the module identifier in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
      </t>
      <table align="center" pn="table-3">
        <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">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 pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2397" target="https://www.rfc-editor.org/info/rfc2397" quoteTitle="true" derivedAnchor="RFC2397">
          <front>
            <title>The "data" URL scheme</title>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="August" year="1998"/>
            <abstract>
              <t indent="0">A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2397"/>
          <seriesInfo name="DOI" value="10.17487/RFC2397"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC6019" target="https://www.rfc-editor.org/info/rfc6019" quoteTitle="true" derivedAnchor="RFC6019">
          <front>
            <title>BinaryTime: An Alternate Format for Representing Date and Time in ASN.1</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2010"/>
            <abstract>
              <t indent="0">This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6019"/>
          <seriesInfo name="DOI" value="10.17487/RFC6019"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="NIST-SP-800-57" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf" quoteTitle="true" derivedAnchor="NIST-SP-800-57">
          <front>
            <title>Recommendation for Key Management: Part 1 - General</title>
            <author fullname="Elaine Barker" surname="Barker">
              <organization showOnFrontPage="true">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>
        <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" quoteTitle="true" derivedAnchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6268" quoteTitle="true" derivedAnchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8551" target="https://www.rfc-editor.org/info/rfc8551" quoteTitle="true" derivedAnchor="RFC8551">
          <front>
            <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="B. Ramsdell" initials="B." surname="Ramsdell"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8551"/>
          <seriesInfo name="DOI" value="10.17487/RFC8551"/>
        </reference>
      </references>
    </references>
    <section anchor="app-additional" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-asn1-module">ASN.1 Module</name>
      <t indent="0" pn="section-appendix.a-1">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" sectionFormat="of" derivedContent="RFC5912"/> and <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/> for the IssuerAndSerialNumber type and in <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/> for the BinaryTime type.</t>
      <sourcecode type="asn.1" markers="false" pn="section-appendix.a-2">
RelatedCertificate { iso(1) identified-organization(3) dod(6)
  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-related-cert-2023(115)}

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

  ATTRIBUTE, EXTENSION
         FROM PKIX-CommonTypes-2009  -- in 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, DigestAlgorithmIdentifier
         FROM CryptographicMessageSyntax-2010 -- in 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 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) 2 }


-- relatedCertificate Extension

id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 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 60 }

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

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

URI ::= IA5String

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

END
</sourcecode>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Alison Becker" initials="A." surname="Becker">
        <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
        <address>
          <email>aebecke@uwe.nsa.gov</email>
        </address>
      </author>
      <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
        <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
        <address>
          <email>rmguthr@uwe.nsa.gov</email>
        </address>
      </author>
      <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
        <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
        <address>
          <email>mjjenki@cyber.nsa.gov</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
