Status of This Memo

This is an Internet Standards Track document.¶

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.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9763.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.¶

Table of Contents

4. Related Certificate

--  Object Identifiers for certificate extension
  id-relatedCert OBJECT IDENTIFIER ::= { 36 }

--  X.509 Certificate extension
  RelatedCertificate ::= OCTET STRING
                -- hash of entire related certificate }

5. Use Case

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.¶

In the following scenario, an entity currently has a traditional certificate and is requesting a new, PQ certificate be issued with the RelatedCertificate extension included that references the entity's traditional certificate.¶

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 certID and a timestamp, using the private key of the certificate identified by the certID.¶

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.¶

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.¶

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.¶

6. CA Organization Considerations

The relatedCertRequest CSR attribute provides assertion to the CA organization issuing Cert B of end entity control of the private key of a related certificate, Cert A. Scenarios may arise where 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 CA 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.¶

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.¶

7. Security Considerations

This document inherits security considerations identified in [RFC5280].¶

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.¶

Authentication, unlike key establishment, is necessarily a one-way arrangement. That is, authentication is an assertion made by a claimant to a verifier. The means and strength of mechanism for 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., 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 it got what it needed - is important.¶

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 physical entity and that the 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).¶

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.¶

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.¶

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.¶

8. IANA Considerations

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):¶

The registration procedure is Specification Required [RFC8126].¶

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:¶

This document defines an ASN.1 module in 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):¶

Appendix A. ASN.1 Module

The following RelatedCertificate ASN.1 module describes the RequesterCertificate type found in the relatedCertAttribute. It pulls definitions from modules defined in [RFC5912], and [RFC6268], and [RFC6019] for the IssuerAndSerialNumber type, and BinaryTime type, respectively.¶

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
          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) attributes(2) }


-- relatedCertificate Extension

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

RelatedCertificate ::= 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  UniformResourceIdentifier,
   signature     BIT STRING }

UniformResourceIdentifier ::= IA5String

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

END

Authors' Addresses