| Internet-Draft | Related Certificates | December 2024 |
| Becker, et al. | Expires 13 June 2025 | [Page] |
This document defines a new 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 June 2025.¶
Copyright (c) 2024 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.¶
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 [RFC5280] and to current PKI best practices.¶
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.¶
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 example, corresponding to 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 is defined, called relatedCertRequest, that permits an RA to make such an assertion.¶
The general roadmap of this design is best illustrated via an entity (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 to PQC.¶
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.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
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.¶
The relatedCertRequest attribute has the following syntax:¶
relatedCertRequest ATTRIBUTE ::= {
WITH SYNTAX RequesterCertificate
ID { TBD1 }
}
RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber,
requestTime BinaryTime,
locationInfo UniformResourceIdentifier,
signature BIT STRING }
¶
The RequesterCertificate type has four fields:¶
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER
¶
BinaryTime ::= INTEGER (0..MAX)¶
UniformResourceIdentifier ::= IA5String¶
The UniformResourceIdentifier is a pointer to a location via HTTP/HTTPS, or a dataURI. This field can contain one of two acceptable values:¶
- If the request for (new) Cert B is to the same CA organization as issued (existing) Cert A, then the UniformResourceIdentifier value SHOULD be a URL that points to a file containing a certificate or certificate chain that the requesting entity owns, as detailed in [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 X.509 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.¶
- 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 value SHOULD be a dataURI [RFC2397] containing inline degenerate PKCS#7 (see Sections 3.2.1, and 3.8 of [RFC8551]) 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 Section 5.¶
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 of DER 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.¶
- 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 Section 8.1.5.1.1.2)¶
The validation of this signature by the CA ensures that the owner of the CSR also owns the certificate indicated in the relatedCertRequest attribute.¶
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.¶
If a CA receives a CSR that includes the relatedCertRequest attribute and that CA supports the attribute, the CA:¶
The RA MUST 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.¶
The RA MAY send the CA a CSR containing a relatedCertRequest attribute that includes the IssuerAndSerialNumber of a certificate that was issued by a different CA.¶
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.¶
The RelatedCertificate extension is an octet string that contains the hash of a single end-entity certificate.¶
The RelatedCertificate extension has the following syntax:¶
-- Object Identifiers for certificate extension
id-relatedCert OBJECT IDENTIFIER ::= { TBD2 }
-- X.509 Certificate extension
RelatedCertificate ::= OCTET STRING
-- hash of entire related certificate }
¶
The extension is comprised of an octet string, which is the digest value obtained from hashing the entire related certificate identified in the CSR attribute defined above, relatedCertRequest. The algorithm used to hash the certificate in the RelatedCertificate extension MUST match the hash algorithm used to sign the certificate that contains the extension.¶
This extension SHOULD NOT be marked critical. Marking this extension critical would severely impact interoperability.¶
For certificate chains, this extension MUST only be included in the end-entity certificate.¶
For the RelatedCertificate extension to be meaningful, a CA that issues a certificate with this extension:¶
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).¶
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:¶
It is outside the scope of this document how to proceed with authentication based on the outcome of this verification process. Different determinations may be made depending on each peer's policy regarding whether both or at least one authentication needs to succeed.¶
The general design of this method is best illustrated through specific use within a migration strategy to PQ cryptography via a non-composite hybrid authentication mechanism. The intent is for a CA issuing a new, 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.¶
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. There may arise scenarios 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 private key may be necessary in order for the whole assurance level from the other CA organization to be accepted.¶
In a similar vein, if the CA organization issuing the PQ certificate can recognize the relatedCertRequest attribute in the CSR and wishes to issue the certificate 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 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.¶
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 that 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.¶
This document defines an extension for use with X.509 certificates. IANA is requested to register the following OID in the SMI Security for PKIX Certificate Extension registry:¶
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 }
¶
with this document as the Required Specification.¶
This document defines a CSR attribute. IANA is requested to register the following OID in the SMI Security for S/MIME Attributes registry:¶
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 }
¶
This document defines an ASN.1 Module in Appendix A. IANA is requested to register an OID for the module identifier in the SMI Security for PKIX Module Identifier registry:¶
id-mod-related-cert(TBD0)¶
The RFC Editor is requested to replace the TBDs in the text with the assigned OIDs.¶
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(TBD0)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ATTRIBUTE, EXTENSION
FROM PKIX-CommonTypes-2009 -- in [RFC5912]
{ 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]
{ 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]
{ 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 TBD2 }
RelatedCertificate ::= OCTET STRING
ext-relatedCertificate EXTENSION ::= {
SYNTAX RelatedCertificate
IDENTIFIED BY id-pe-relatedCert }
-- relatedCertRequest Attribute
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 }
RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber,
requestTime BinaryTime,
locationInfo UniformResourceIdentifier,
signature BIT STRING }
UniformResourceIdentifier ::= IA5String
aa-relatedCertRequest ATTRIBUTE ::= {
TYPE RequesterCertificate
IDENTIFIED BY id-aa-relatedCertRequest }
END
¶