<?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> <!--[rfced] May we update the short title that spans the header of the PDF file to more closely match the document title as shown below? Original: Related Certificates Perhaps: Related Certificates for Protocol Authentications --> <title abbrev="Related Certificates">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="March"/> <area>SEC</area> <workgroup>lamps</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <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,(a device, service, user token, etc.) that has an existing certificate (Cert A) and requests a new certificate (Cert B), perhaps as part of an organization's transition strategy to migrate their PKI from traditional cryptography toPQC.post-quantum cryptography (PQC). </t> <ul spacing="normal"> <li> For protocols where authentication is notnegotiated,negotiated andratheris rather 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 which validators 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 the validator. If the protocol is enabled to do so, peers may request that both Cert A and Cert B are used for authentication. </li> </ul> <t> A validator that prefers multiple authentication types may be assisted by the inclusion of relevant information in the signer's certificate, 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[syntax:</t> <sourcecode type=""><![CDATA[ relatedCertRequest ATTRIBUTE ::= { WITH SYNTAX RequesterCertificate ID {TBD160 } } RequesterCertificate ::= SEQUENCE { certID IssuerAndSerialNumber, requestTime BinaryTime, locationInfo UniformResourceIdentifier, signature BIT STRING }]]></artwork>]]></sourcecode> <t>The RequesterCertificate type has fourfields: </t>fields:</t> <ul spacing="normal"><li>The<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=""><![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=""><![CDATA[ BinaryTime ::= INTEGER (0..MAX)]]></artwork> <ul spacing="normal"> <li>The]]></sourcecode> </li> <li><t>The locationInfo field uses UniformResourceIdentifier to provide information on the location of the other certificate the requesting entity owns. We define UniformResourceIdentifieras: </li> </ul> <artwork name="" type="" align="left" alt=""><![CDATA[as:</t> <sourcecode type=""><![CDATA[ UniformResourceIdentifier ::= IA5String]]></artwork> <t> The]]></sourcecode> <t>The UniformResourceIdentifier is a pointer to a location viaHTTP/HTTPS,HTTP/HTTPS or a dataURI. This field can contain one of two acceptable values:</t> <ulspacing="normal"> <li> <t> -spacing="normal" empty="true"> <li>- If the request for (new) Cert B is to the same CA organization as 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 entityend-entity X.509certificate,certificate or the entire certificate chain. In this case, preference for a URL keeps the data limit smaller than using a dataURI. All certificates contained must be DER encoded.</t> <t> -</li> <!--[rfced] Please clarify "different to" in the following sentence. Is the intended meaning perhaps "different than"? Original: If the request for (new) Cert B is to a CA organization different to the CA organization that issued the certificate (existing) Cert A referenced in the CSR... Perhaps: If the request for (new) Cert B is to a CA organization that is different than the CA organization that issued the certificate (existing) Cert A referenced in the CSR... --> <li>- If the request for (new) Cert B is to a CA organization different to 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 allows validation without the CA having to retrieve certificates/CRLs from another CA. Further discussion of requirements for this scenario is in <xref target="use-case"/>.</li></ul></li></ul> <!-- [rfced] FYI: We have added a citation for the NIST SP mentioned in this sentence, with a corresponding reference entry in the informative reference section. Original: If the related certificate is a key establishment certificate (e.g., using RSA key transport or ECC key agreement), use the private key to sign one time for POP (as detailed in NIST SP 800-57 Part 1 Rev 5 Section5. </t> </li> </ul>8.1.5.1.1.2) Current: If the related certificate is a key establishment certificate (e.g., using RSA key transport or Elliptic Curve Cryptography (ECC) key agreement), use the private key to sign one time for proof of possession (POP) (as detailed in Section 8.1.5.1.1.2 of [NIST-SP-800-57]). --> <ul spacing="normal"><li> <t>The<li><t>The signature field provides evidence that the requesting entity owns the certificate indicated by the certID. Specifically, the signature field contains a digital signature over the concatenation ofDER encodedDER-encoded requestTime and IssuerAndSerialNumber. The concatenated value is signed using the signature algorithm and private key associated with the certificate identified by the certID field.</t> <t>-</t></li></ul> <ul spacing="normal" empty="true"> <li>- If the related certificate is a key establishment certificate (e.g., using RSA key transport orECCElliptic Curve Cryptography (ECC) key agreement), use the private key 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> <t>The validation of this signature by the CA ensures that the owner of the CSR also owns the certificate indicated in the relatedCertRequest attribute. </t> </section> <section numbered="true" toc="default"> <name>CSR Processing</name> <t>The information provided in the relatedCertRequest attribute allows the CA to locate a previously issued certificate that the requesting entity owns, and verify ownership by using the public key in that certificate to validate the signature in the relatedCertRequest attribute. </t> <t> If a CA receives a CSR that includes the relatedCertRequest attribute and that CA supports the attribute, the CA: </t> <ul spacing="normal"> <li>MUST<bcp14>MUST</bcp14> retrieve the certificate identified in the relatedCertRequest attribute using the information provided in UniformResourceIdentifier, and validate it using certificate path validation rules defined in <xref target="RFC5280" format="default"/>. The CA then extracts the IssuerAndSerialNumber from the indicated certificate and compares this value against the IssuerAndSerialNumber provided in the certID field of relatedCertRequest. </li><li>MUST<li><bcp14>MUST</bcp14> check that the BinaryTime indicated in the requestTime field is sufficiently fresh. Note that sufficient freshness is defined by local policy and is out of the scope of this document. </li><li>MUST<li><bcp14>MUST</bcp14> verify the signature field of the relatedCertRequest attribute. The CA validates the signature using the public key associated with the certificate it located via the info provided in the UniformResourceIdentifier field. The details of the validation process are outside the scope of this document. </li><li>SHOULD<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 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 section profiles a new X.509v3 certificate extension, RelatedCertificate. RelatedCertificate creates an association between the certificate containing the RelatedCertificate extension (Cert B) and the certificate referenced within the extension (Cert A). When two end-entity certificates are used in a protocol, where one of the certificates contains a RelatedCertificate extension that references another certificate, the authenticating entity is provided with additional assurance that all certificates belong to the same entity. </t> <t>The RelatedCertificate extension is an octet string that contains the hash of a single end-entity certificate. </t> <t>The RelatedCertificate extension has the following syntax: </t><artwork name="" type="" align="left" alt=""><![CDATA[<sourcecode type=""><![CDATA[ -- Object Identifiers for certificate extension id-relatedCert OBJECT IDENTIFIER ::= {TBD236 } -- X.509 Certificate extension RelatedCertificate ::= OCTET STRING -- hash of entire related certificate }]]></artwork>]]></sourcecode> <t>The extension is comprised of an octet string, which is the digest value obtained from hashing the entire related certificate identified in the relatedCertRequest CSR attribute definedabove, relatedCertRequest.above. The algorithm used to hash the certificate in the RelatedCertificate extensionMUST<bcp14>MUST</bcp14> match the hash algorithm used to sign the certificate that contains the extension. </t> <t>This extensionSHOULD NOT<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 listed and validated in the relatedCertRequest attribute of the CSR submitted by the requesting entity.</li><li>MUST<li><bcp14>MUST</bcp14> ensure that the related certificate at least contains theKUkey usage (KU) bits andEKUextended key usage (EKU) OIDs <xref target="RFC5280" format="default"/> being asserted in the certificate being issued. </li><li>SHOULD<li><bcp14>SHOULD</bcp14> determine that all certificates are valid at the time ofissuance.issuance. The usable overlap of validity periods is a Subscriber concern.</li> </ul> </section> <section numbered="true" toc="default"> <name>Endpoint Protocol Multiple Authentication Processing</name> <t> When the preference to use a non-composite hybrid authentication mode is expressed by an endpoint through the protocol itself (e.g., during negotiation), the use of the RelatedCertificate extension and its enforcement are left to the protocol's native authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection). </t> <t>If an endpoint has indicated that it is willing to do non-composite hybrid authentication and receives the appropriate authentication data, it should check end-entity certificates (Cert A and Cert B) for the RelatedCertificate extension. If present in one certificate, for example Cert B, it should: </t> <ul spacing="normal"> <li>Compute the appropriate hash of Cert A, the other end-entity certificate received. The hash algorithm is the same as the one used to sign the certificate containing the extension. </li> <li>Verify that the hash value matches the hash entry in the RelatedCertificate extension of Cert B. </li> </ul><t>It is outside the scope of this document how<t>How to proceed with authentication based on the outcome of this verificationprocess.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 and is requesting a new, PQ certificate be issued with the RelatedCertificate extension included that 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 the certID and a timestamp, using the private key of the certificate identified by the certID. </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 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 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 attribute provides assertion to the CA organization issuing CertB,B of end entity control of the private key of a related certificate, Cert A.ThereScenarios may arisescenarioswhere a public-facing CA organization is not configured to validate signatures associated with certificates that have been issued by a different CA organization. In this case, recognition of the contents in the relatedCertRequest attribute may be contingent upon a pre-arranged contract with pre-configured trust anchors from the other CAorganization,organization and include agreements on certificate policy with regards to certificate application, issuance, and acceptance. Further, matching policies between CA organizations on protection of the private key may be necessary in order for the whole assurance level from the other CA organization to be accepted. </t> <t>In a similar vein,Similarly, if the CA organization issuing 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 order to ensure that the certificates have been issued under homogeneous sets of security parameters, the certificate policies should be the same with regard to common security requirements. The issuing CA, as part of related certificate public key validation, determines what policies are acceptable for the certification path of the related certificate. The issuing CA determines what is acceptable to them in terms of certificate policy, to ensure that the policies for protection of the private key are sufficient. The relatedCertRequest attribute and subsequent RelatedCertificate certificate extension are solely intended to provide assurance that both private keys are controlled by the same end entity. </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. <!--[rfced] Is "mechanism" intended to be singular (perhaps A) or plural (perhaps B) in this sentence? And may we rephrase "have to be to the satisfaction of the verifier" to "have to be satisfactory to the verifier"? Original: The means and strength of mechanism for authentication have to be to the satisfaction of the verifier. Perhaps A: The means and strength of an authentication mechanism have to be to satisfactory to the verifier. Perhaps B: The means and strength of mechanisms for authentication have to be satisfactory to the verifier. --> The means and strength of mechanism for authentication have to be to the satisfaction of the verifier. A system security designer needs to be aware of what authentication assurances are needed in various parts of the system and how to achieve that assurance. In a closed system(e.g.(e.g., Company X distributing firmware to its 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. <!--[rfced] Can "and to assess that it got what it needed" be rephrased for clarity? Please let us know if the suggested text is agreeable or if you prefer otherwise. Original: 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 it got what it needed - is important. Perhaps: 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. --> 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 it got what it needed - 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, that the identity belongs to a particular physicalentity,entity and thatthatthe physical entity has control over the private key corresponding to the public. For any hybrid approach, it is important that there be evidence that the same entity controls all private keys at time of use (to the verifier) and at time of registration (to the CA). </t> <t>All hybrid implementations are vulnerable to a downgrade attack in which a malicious peer does not express support for the stronger algorithm, resulting in an exchange that can only rely upon a weaker algorithm for security. </t> <t> Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedCertRequest CSR attribute, if the URI points to malicious code. Implementors should ensure the data is properly formed and validate the retrieved data fully. </t> <t> <!--[rfced] We updated "it may be advisable" to "it is advisable". If that is incorrect, please let us know. Original: CAs should be aware that retrieval of existing certificates may be subject to observation; if this is a concern, it may be advisable to use the dataURI option described in Section 3.1. Current: 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 dataURI option described in Section 3.1. --> CAs should be aware that retrieval of existing certificates may be subject to observation; if this is a concern, it may be advisable to use the dataURI option described in <xref target="related-cert-request"/>. </t> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name> <!--[rfced] We have included a clarification about the IANA text below. In addition to responding to that question, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) FYI: For all three registrations, we replaced the OIDs enclosed in <artwork> with entries that exactly match the IANA registries at <https://www.iana.org/assignments/smi-numbers/>. One example Original: id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 } Current: | Decimal | Description | References | +=========+===================+============+ | 36 | id-pe-relatedCert | RFC 9763 | --> <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>Extension" registry (1.3.6.1.5.5.7.1): </t> <table align="center"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Decimal</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">References</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">36</td> <td align="left" colspan="1" rowspan="1">id-pe-relatedCert</td> <td align="left" colspan="1" rowspan="1">RFC 9763</td> </tr> </tbody> </table> <!-- <artwork name="" type="" align="left" alt=""><![CDATA[ id-pe-relatedCert OBJECT IDENTIFIER ::= { id-peTBD236 } ]]></artwork><t>with this document as the--> <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> <table align="center"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Decimal</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">References</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">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> <!-- <artwork name="" type="" align="left" alt=""><![CDATA[ id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aaTBD160 } ]]></artwork> --> <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>Identifier" registry (1.3.6.1.5.5.7.0): </t> <table align="center"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Decimal</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">References</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">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> <!-- <artwork name="" type="" align="left" alt=""><![CDATA[id-mod-related-cert(TBD0)id-mod-related-cert-2023(115) ]]></artwork><t> The RFC Editor is requested to replace the TBDs in the text with the assigned OIDs.</t>--> </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:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.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.8551.xml"/> <xi:include 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> <!-- [rfced] We note that the "IssuerAndSerialNumber type" is mentioned in [RFC5912] and [RFC6268, and the "BinaryTime type" is mentioned in [RFC6019]. Considering that, may we update the following sentence for clarity as shown below? Original: It pulls definitions from modules defined in [RFC5912], and [RFC6268], and [RFC6019] for the IssuerAndSerialNumber type, and BinaryTime type, respectively. Perhaps: It pulls definitions from modules defined in [RFC5912] and [RFC6268] for the IssuerAndSerialNumber type and in [RFC6019] for the BinaryTime type. --> <t>The following RelatedCertificate ASN.1 module describes the RequesterCertificate type found in the relatedCertAttribute. It pulls definitions from modules defined in <xref target="RFC5912" format="default"/>, and <xref target="RFC6268" format="default"/>, and <xref target="RFC6019" format="default"/> for the IssuerAndSerialNumber type, and BinaryTime type, respectively. </t><artwork name="" type="" align="left" alt=""><![CDATA[<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 ::= 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. --> <!-- [rfced] FYI: We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Cryptographic Message Syntax (CMS) Certificate Signing Request (CSR) Elliptic Curve Cryptography (ECC) extended key usage (EKU) Internet Key Exchange Protocol Version 2 (IKEv2) key usage (KU) proof of possession (POP) (per NIST-SP-800-57) post-quantum (PQ) post-quantum cryptography (PQC) --> <!-- [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. --> </back> </rfc>