<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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="RelatedCertificates">RelatedCertificates for Protocol Authentications">Related Certificates for Use in Multiple Authentications within a Protocol</title> <seriesInfoname="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> <dateyear="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 newCSRCertificate 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 totwo public keys: one in an extantcertificate,certificate and one in a current request) belong to the same entity. To facilitate this, a CSRattribute is defined,attribute, called relatedCertRequest,that permitsis 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, usertoken, 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 toPQC.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 notnegotiated, and rathernegotiated but instead is limited by what the signer offers, such as inCMSCryptographic 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 whichvalidatorsverifiers the signer anticipates. </li> <li> For protocols where authentication is negotiated in-protocol, such as TLS andIKEv2,Internet Key Exchange Protocol Version 2 (IKEv2), either Cert A or Cert B's signing key may be invoked, according to the preference of thevalidator.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> Avalidatorverifier that prefers multiple authentication types may be assisted by the inclusion of relevant information in one of the signer'scertificate,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 apreviously-issuedpreviously 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 CertA,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 14 <xreftarget="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 theend-entityend entity owns and wants identified in the new certificate requested through theCSR. </t>CSR.</t> <t>The relatedCertRequest attribute has the followingsyntax: </t> <artwork name="" type="" align="left" alt=""><![CDATA[ relatedCertRequestsyntax:</t> <sourcecode type="asn.1"><![CDATA[ id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } aa-relatedCertRequest ATTRIBUTE ::= {WITH SYNTAXTYPE RequesterCertificateID { 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 fourfields: </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 forconvenience: </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 defineUniformResourceIdentifieras: </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 viaHTTP/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 thesameCA organizationasthat also issued (existing) Cert A, then the UniformResourceIdentifier valueSHOULD<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 theend entity X.509 certificate,end-entity certificate or the entire certificate chain.In this case, preference for a URL keeps theThis option uses less datalimit smallerthanusinga dataURI. All certificates contained must be DERencoded. </t> <t> - Ifencoded.</li> <li>If the request for (new) Cert B is to a CA organization differenttothan the CA organization that issued the certificate (existing) Cert A referenced in the CSR, then the UniformResourceIdentifier valueSHOULD<bcp14>SHOULD</bcp14> be a dataURI <xref target="RFC2397" format="default"/> containing inline degenerate PKCS#7 (see Sections3.2.1,<xref target="RFC8551" section="3.2.1" sectionFormat="bare"/> and3.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 allowsvalidation withoutthe 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>TheThere 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 thecertID.certID field. Specifically, the signature field contains a digital signature over the concatenation ofDER encoded requestTimeDER-encoded IssuerAndSerialNumber andIssuerAndSerialNumber.BinaryTime. The concatenated value is signed using the signature algorithm and private key associated with the certificate identified by the certIDfield. </t> <t>- Iffield.</t> <ul spacing="normal"> <!-- Nest 2 --> <li>If the related certificate is a key establishment certificate (e.g., using RSA key transport orECCElliptic Curve Cryptography (ECC) key agreement),usethe private key is used to sign one time forPOPproof of possession (POP) (as detailed inNIST SP 800-57 Part 1 Rev 5Section8.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>Thevalidationverification of this signature by the CA ensures that the owner of the CSR also owns the certificate indicated in the relatedCertRequestattribute. </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, andverifyconfirm ownership by using the public key in that certificate tovalidateverify 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 ofrelatedCertRequest. </li> <li>MUSTrelatedCertRequest.</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 thisdocument. </li> <li>MUSTdocument.</li> <li><bcp14>MUST</bcp14> verify the signature field of the relatedCertRequest attribute. The CAvalidatesverifies the signature using the public key associated with the certificateit located via the info provided inidentified by theUniformResourceIdentifier field.relatedCertRequest attribute. The details of thevalidationverification process are outside the scope of thisdocument. </li> <li>SHOULDdocument.</li> <li><bcp14>SHOULD</bcp14> issue the new certificate containing the RelatedCertificate extension as specified inSection 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 RAMUST<bcp14>MUST</bcp14> only allow apreviously-issuedpreviously issued certificate to be indicated in the relatedCertRequest attribute in order to enable the CA to perform the required signature verification. </t> <t>The RAMAY<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 sectionprofilesspecifies a newX.509v3X.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 referencesanotherthe other certificate, the authenticating entity is provided with additional assurance thatall certificatesboth <!-- [rmg] "all" changed to "both" (accidental artifact from earlier version of draft)-->certificates belong to the same entity. </t> <t>The RelatedCertificate extensionis an octet string thatcontains the hash of a single end-entitycertificate.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>TheThe 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>Thisand 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. --> <sourcecode type="asn.1"><![CDATA[ -- Object Identifier for certificate extension id-relatedCert OBJECT IDENTIFIER ::= { 36 } -- X.509 Certificate extension RelatedCertificate ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, 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 SHOULDNOTbe 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 extensionMUST<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 listedand validatedin 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 certificateat leastcontains theKUkey usage (KU) bits andEKUextended key usage (EKU) OIDs <xref target="RFC5280" format="default"/> being asserted in the certificate beingissued. </li> <li>SHOULDissued.</li> <li><bcp14>SHOULD</bcp14> determine thatall certificates arethe related certificate is valid at the time ofissuance.issuance. The usable overlapofwith the validityperiodsperiod 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'snativeexisting authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection). </t> <t>If an endpoint has indicated that itis willing to dosupports 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 onecertificate, for examplecertificate (e.g., CertB,B), it should: </t> <ul spacing="normal"> <li>Compute the appropriate hash of Cert A, the other end-entity certificatereceived. The hash algorithm is the same asreceived.</li> <!--[rmg] Deleted theone used to signsecond sentence of thecertificate containingabove bullet since it is addressed in theextension. </li> <li>Verifymodification made to RelatedCertificate in Section 4.1. --> <li>Confirm that the hash value matches the hash entry in the RelatedCertificate extension of CertB. </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 thisverification 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 toPQ cryptographyPQC via a non-composite hybrid authentication mechanism. The intent is for a CA issuing a new,PQpost-quantum (PQ) certificate to add an X.509 extension that provides information about apreviously-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 traditionalcertificate,certificate andis requestingrequests that a new, PQ certificate be issuedwith thecontaining a RelatedCertificateextension included thatextension, 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'spreviously-issuedpreviously issued traditionalcertificate,certificate and a signature field in which the requesting entity produces a digital signature over thecertIDconcatenation of the IssuerAndSerialNumber anda timestamp,BinaryTime, using the private key of the certificate identified by thecertID.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-issuedpreviously 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 sameend-entityend entity controls the private keys of bothcertificates.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 attributeprovides assertion to the CA organization issuing Cert B, of end entityasserts end-entity control of the private keyofassociated with a relatedcertificate, Cert A. There may arise scenarios wherecertificate (Cert A) to the CA organization issuing a new certificate (Cert B). A public-facing CA organizationismay not be configured to validatesignatures associated withcertificates that have been issued byadifferent CAorganization.organizations. In this case, recognition of the contents in the relatedCertRequest attribute maybe contingent uponnecessitate pre-arrangement, e.g., apre-arrangedcontract with pre-configured trust anchors fromthe otheranother CAorganization,organization andincludeagreementson certificate policy with regards toregarding policies concerning certificate application, issuance, and acceptance.Further, matching policies between CA organizations on protection of private key may be necessary</t> <t> Continuing with this scenario, in order for thewhole assurance level from the other CA organization to be accepted. </t> <t> In a similar vein, if theCA organizationissuing the PQ certificate can recognize the relatedCertRequest attribute in the CSR and wishes to issue the certificate with the RelatedCerts extension, it may be the case that a different CA organization issued the related certificate referenced in the CSR. In orderto ensure thatthe certificates have beenCert B is issued underhomogeneous sets ofsecurityparameters,parameters comparable to Cert A, thecertificate policiesissuing CA organization shouldbematch thesame with regardissued certification policies tocommon security requirements.the related ones. The issuingCA,CA organization, as part ofrelated certificate public key validation, determinesits validation of Cert A, ascertains what policies areacceptable for theasserted in Cert A’s certification pathof the related certificate. The issuing CAand determineswhat is acceptable to them in termswhich ofcertificate policy, totheir own certification policies will best ensure that thepolicies forprotection of the private keyare 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 ofmechanism forthe authentication mechanism have to be satisfactory to thesatisfaction of theverifier. 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 owndevices)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 onlineprotocols,protocols like TLS, the ability for the verifier to express what is possible and what is preferred--- and to assess thatit 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 physicalentity,entity and thatthatthe physical entity has control over the private key corresponding to thepublic.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 pointsas 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, itmay beis advisable to use the dataURI option described inSection 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. IANAis requested to registerhas registered the following OID in theSMI"SMI Security for PKIX CertificateExtension 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 thecolspan="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 RequiredSpecification.<xref target="RFC8126"/>. </t> <t>This document defines a CSR attribute. IANAis requested to registerhas registered the following OID in theSMI"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.1Modulemodule inAppendix A.<xref target="app-additional"/>. IANAis requested to register anhas registered the following OID for the module identifier in theSMI"SMI Security for PKIX ModuleIdentifier 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:includehref="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://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2397.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2397.xml"/> </references> <references> <name>Informative References</name> <xi:includehref="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:includehref="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:includehref="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 theIssuerAndSerialNumber type, andBinaryTimetype, respectively. </t> <artwork name="" type="" align="left" alt=""><![CDATA[type.</t> <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 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) } -- relatedCertificate Extension id-pe-relatedCert OBJECT IDENTIFIER ::= { id-peTBD236 } RelatedCertificate ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OCTET STRING } ext-relatedCertificate EXTENSION ::= { SYNTAX RelatedCertificate IDENTIFIED BY id-pe-relatedCert } -- relatedCertRequest Attribute id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aaTBD160 } RequesterCertificate ::= SEQUENCE { certID IssuerAndSerialNumber, requestTime BinaryTime, locationInfo UniformResourceIdentifier, signature BIT STRING } UniformResourceIdentifier ::= IA5String aa-relatedCertRequest ATTRIBUTE ::= { TYPE RequesterCertificate IDENTIFIED BY id-aa-relatedCertRequest } END]]></artwork>]]></sourcecode> </section> <!-- [rfced] We updated artwork to sourcecode in Sections 3.1 and 4.1 and in Appendix A. Please confirm that this is correct. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. [rfceditor]: need author response. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "native" should be updated. In addition, please consider whether "traditional" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/ nist-research-library/nist-technical-series-publications-author-instructions#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>