rfc9763.original   rfc9763.txt 
Network Working Group A. Becker Internet Engineering Task Force (IETF) A. Becker
Internet-Draft R. Guthrie Request for Comments: 9763 R. Guthrie
Intended status: Standards Track M. Jenkins Category: Standards Track M. Jenkins
Expires: 13 June 2025 NSA ISSN: 2070-1721 NSA
10 December 2024 April 2025
Related Certificates for Use in Multiple Authentications within a Related Certificates for Use in Multiple Authentications within a
Protocol Protocol
draft-ietf-lamps-cert-binding-for-multi-auth-06
Abstract Abstract
This document defines a new CSR attribute, relatedCertRequest, and a This document defines a new Certificate Signing Request (CSR)
new X.509 certificate extension, RelatedCertificate. The use of the attribute, relatedCertRequest, and a new X.509 certificate extension,
relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate. The use of the relatedCertRequest attribute in a
RelatedCertificate extension in the resulting certificate together CSR and the inclusion of the RelatedCertificate extension in the
provide additional assurance that two certificates each belong to the resulting certificate together provide additional assurance that two
same end entity. This mechanism is particularly useful in the certificates each belong to the same end entity. This mechanism is
context of non-composite hybrid authentication, which enables users particularly useful in the context of non-composite hybrid
to employ the same certificates in hybrid authentication as in authentication, which enables users to employ the same certificates
authentication done with only traditional or post-quantum algorithms. in hybrid authentication as in authentication done with only
traditional or post-quantum algorithms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 13 June 2025. 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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. CSR and Related Certificates . . . . . . . . . . . . . . . . 4 3. CSR and Related Certificates
3.1. The relatedCertRequest Attribute . . . . . . . . . . . . 4 3.1. The relatedCertRequest Attribute
3.2. CSR Processing . . . . . . . . . . . . . . . . . . . . . 6 3.2. CSR Processing
4. Related Certificate . . . . . . . . . . . . . . . . . . . . . 7 4. Related Certificate
4.1. The RelatedCertificate Extension . . . . . . . . . . . . 7 4.1. The RelatedCertificate Extension
4.2. Endpoint Protocol Multiple Authentication Processing . . 8 4.2. Endpoint Protocol Multiple Authentication Processing
5. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Use Case
6. CA Organization Considerations . . . . . . . . . . . . . . . 9 6. CA Organization Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 Appendix A. ASN.1 Module
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
The goal of this document is to define a method for providing The goal of this document is to define a method for providing
assurance that two X.509 (aka PKIX) end-entity certificates are owned assurance that two X.509 (aka PKIX) end-entity certificates are owned
by the same entity, in order to perform multiple authentications by the same entity, in order to perform multiple authentications
where each certificate corresponds to a distinct digital signature. where each certificate corresponds to a distinct digital signature.
This method aims to facilitate the use of two certificates for This method aims to facilitate the use of two certificates for
authentication in a secure protocol while minimizing changes to the authentication in a secure protocol while minimizing changes to the
certificate format [RFC5280] and to current PKI best practices. certificate format [RFC5280] and to current PKI best practices.
skipping to change at page 3, line 9 skipping to change at line 97
associated with each certificate are under the control of the same associated with each certificate are under the control of the same
entity. This document defines a certificate extension, entity. This document defines a certificate extension,
RelatedCertificate, that signals that the certificate containing the RelatedCertificate, that signals that the certificate containing the
extension is able to be used in combination with the other specified extension is able to be used in combination with the other specified
certificate. certificate.
A certification authority (CA) organization (defined here as the A certification authority (CA) organization (defined here as the
entity or organization that runs a CA and determines the policies and 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 tools the CA will use) that is asked to issue a certificate with such
an extension may want assurance from a registration authority (RA) an extension may want assurance from a registration authority (RA)
that the private keys (for example, corresponding to two public keys: that the private keys (corresponding to, for example, two public
one in an extant certificate, and one in a current request) belong to keys: one in an extant certificate and one in a current request)
the same entity. To facilitate this, a CSR attribute is defined, belong to the same entity. To facilitate this, a CSR attribute,
called relatedCertRequest, that permits an RA to make such an called relatedCertRequest, is defined to permit an RA to make such an
assertion. assertion.
1.1. Overview 1.1. Overview
The general roadmap of this design is best illustrated via an entity The general roadmap of this design is best illustrated via an entity
(device, service, user token, etc.) that has an existing certificate (e.g., a device, service, user token) that has an existing
(Cert A) and requests a new certificate (Cert B), perhaps as part of certificate (Cert A) and requests a new certificate (Cert B), perhaps
an organization's transition strategy to migrate their PKI from as part of an organization's transition strategy to migrate their PKI
traditional cryptography to PQC. from traditional cryptography to post-quantum cryptography (PQC).
* For protocols where authentication is not negotiated, and rather * For protocols where authentication is not negotiated but instead
is limited by what the signer offers, such as in CMS and S/MIME, is limited by what the signer offers, such as in Cryptographic
either Cert A's signing key, Cert B's signing key, or both signing Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert
keys may be invoked, according to which validators the signer B's signing key, or both signing keys may be invoked, according to
anticipates. which verifiers the signer anticipates.
* For protocols where authentication is negotiated in-protocol, such * For protocols where authentication is negotiated in-protocol, such
as TLS and IKEv2, either Cert A or Cert B's signing key may be as TLS and Internet Key Exchange Protocol Version 2 (IKEv2),
invoked, according to the preference of the validator. If the either Cert A or Cert B's signing key may be invoked, according to
protocol is enabled to do so, peers may request that both Cert A the preference of the verifier. If the protocol is enabled to do
and Cert B are used for authentication. so, peers may request that both Cert A and Cert B are used for
authentication.
A validator that prefers multiple authentication types may be A verifier that prefers multiple authentication types may be assisted
assisted by the inclusion of relevant information in the signer's by the inclusion of relevant information in one of the signer's
certificate, that is, information that indicates the existence of a certificates; that is, information that indicates the existence of a
related certificate, and some assurance that those certificates have related certificate, and some assurance that those certificates have
been issued to the same entity. This document describes a been issued to the same entity. This document describes a
certificate request attribute and certificate extension that provide certificate request attribute and certificate extension that provide
such assurance. such assurance.
To support this concept, this document defines a new CSR attribute, To support this concept, this document defines a new CSR attribute,
relatedCertRequest, which contains information on how to locate a relatedCertRequest, which contains information on how to locate a
previously-issued certificate (Cert A) and provides evidence that the previously issued certificate (Cert A) and provides evidence that the
requesting entity owns that certificate. When the RA makes the requesting entity owns that certificate. When the RA makes the
request to the CA, the CA uses the given information to locate Cert request to the CA, the CA uses the given information to locate Cert A
A, and then verifies ownership before generating the new certificate, and then verifies ownership before generating the new certificate,
Cert B. Cert B.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. CSR and Related Certificates 3. CSR and Related Certificates
3.1. The relatedCertRequest Attribute 3.1. The relatedCertRequest Attribute
This section defines a new CSR attribute designed to allow the RA to 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 attest that the owner of the public key in the CSR also owns the
public key associated with the end-entity certificate identified in public key associated with the end-entity certificate identified in
this attribute. The relatedCertRequest attribute indicates the this attribute. The relatedCertRequest attribute indicates the
location of a previously issued certificate that the end-entity owns location of a previously issued certificate that the end entity owns
and wants identified in the new certificate requested through the and wants identified in the new certificate requested through the
CSR. CSR.
The relatedCertRequest attribute has the following syntax: The relatedCertRequest attribute has the following syntax:
relatedCertRequest ATTRIBUTE ::= { id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
WITH SYNTAX RequesterCertificate
ID { TBD1 } aa-relatedCertRequest ATTRIBUTE ::= {
} TYPE RequesterCertificate
IDENTIFIED BY id-aa-relatedCertRequest}
RequesterCertificate ::= SEQUENCE { RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber, certID IssuerAndSerialNumber,
requestTime BinaryTime, requestTime BinaryTime,
locationInfo UniformResourceIdentifier, locationInfo UniformResourceIdentifier,
signature BIT STRING } signature BIT STRING }
The RequesterCertificate type has four fields: The RequesterCertificate type has four fields:
* The certID field uses the IssuerAndSerialNumber type [RFC5652] to * The certID field uses the IssuerAndSerialNumber type [RFC5652] to
identify a previously issued end-entity certificate that the identify a previously issued end-entity certificate that the
requesting entity also owns. IssuerAndSerialNumber is repeated requesting entity also owns. IssuerAndSerialNumber is repeated
here for convenience: here for convenience:
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber ::= INTEGER
* The requestTime field uses the BinaryTime type [RFC6019] in order * The requestTime field uses the BinaryTime type [RFC6019] in order
to ensure freshness, such that the signed data can only be used at 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 the time of the initial CSR. The means by which the CA and RA
synchronize time is outside the scope of this document. synchronize time is outside the scope of this document.
BinaryTime is repeated here for convenience: BinaryTime is repeated here for convenience:
BinaryTime ::= INTEGER (0..MAX) BinaryTime ::= INTEGER (0..MAX)
* The locationInfo field uses UniformResourceIdentifier to provide * The locationInfo field uses UniformResourceIdentifier to provide
information on the location of the other certificate the information on the location of the other certificate the
requesting entity owns. We define UniformResourceIdentifier as: requesting entity owns. UniformResourceIdentifier is defined as:
UniformResourceIdentifier ::= IA5String UniformResourceIdentifier ::= IA5String
The UniformResourceIdentifier is a pointer to a location via HTTP/ The UniformResourceIdentifier is a pointer to a location via
HTTPS, or a dataURI. This field can contain one of two acceptable HTTP(S) or a dataURI. This field can contain one of two
values: acceptable values:
* - If the request for (new) Cert B is to the same CA organization - If the request for (new) Cert B is to the CA organization that
as issued (existing) Cert A, then the UniformResourceIdentifier also issued (existing) Cert A, then the
value SHOULD be a URL that points to a file containing a UniformResourceIdentifier value SHOULD be a URL that points to
certificate or certificate chain that the requesting entity owns, a file containing a certificate or certificate chain that the
as detailed in [RFC5280]; the URL is made available via HTTP or requesting entity owns, as detailed in [RFC5280]; the URL is
HTTPS. The file must permit access to a CMS 'certs-only' message made available via HTTP or HTTPS. The file must permit access
containing the end entity X.509 certificate, or the entire to a CMS 'certs-only' message containing the end-entity
certificate chain. In this case, preference for a URL keeps the certificate or the entire certificate chain. This option uses
data limit smaller than using a dataURI. All certificates less data than a dataURI. All certificates contained must be
contained must be DER encoded. DER encoded.
- If the request for (new) Cert B is to a CA organization - If the request for (new) Cert B is to a CA organization
different to the CA organization that issued the certificate different than the CA organization that issued the certificate
(existing) Cert A referenced in the CSR, then the (existing) Cert A referenced in the CSR, then the
UniformResourceIdentifier value SHOULD be a dataURI [RFC2397] UniformResourceIdentifier value SHOULD be a dataURI [RFC2397]
containing inline degenerate PKCS#7 (see Sections 3.2.1, and 3.8 containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8
of [RFC8551]) consisting of all the certificates and CRLs required of [RFC8551]) consisting of all the certificates and CRLs
to validate Cert A. This allows validation without the CA having required to validate Cert A. This allows the CA to perform
to retrieve certificates/CRLs from another CA. Further discussion validation (as described in Section 3.2) without having to
of requirements for this scenario is in Section 5. 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 * The signature field provides evidence that the requesting entity
owns the certificate indicated by the certID. Specifically, the owns the certificate indicated by the certID field. Specifically,
signature field contains a digital signature over the the signature field contains a digital signature over the
concatenation of DER encoded requestTime and concatenation of DER-encoded IssuerAndSerialNumber and BinaryTime.
IssuerAndSerialNumber. The concatenated value is signed using the The concatenated value is signed using the signature algorithm and
signature algorithm and private key associated with the private key associated with the certificate identified by the
certificate identified by the certID field. certID field.
- If the related certificate is a key establishment certificate - If the related certificate is a key establishment certificate
(e.g., using RSA key transport or ECC key agreement), use the (e.g., using RSA key transport or Elliptic Curve Cryptography
private key to sign one time for POP (as detailed in NIST SP (ECC) key agreement), the private key is used to sign one time
800-57 Part 1 Rev 5 Section 8.1.5.1.1.2) for proof of possession (POP) (as detailed in
Section 8.1.5.1.1.2 of [NIST-SP-800-57]).
The validation of this signature by the CA ensures that the owner of The verification of this signature by the CA ensures that the
the CSR also owns the certificate indicated in the relatedCertRequest owner of the CSR also owns the certificate indicated in the
attribute. relatedCertRequest attribute.
3.2. CSR Processing 3.2. CSR Processing
The information provided in the relatedCertRequest attribute allows The information provided in the relatedCertRequest attribute allows
the CA to locate a previously issued certificate that the requesting the CA to locate a previously issued certificate that the requesting
entity owns, and verify ownership by using the public key in that entity owns, and confirm ownership by using the public key in that
certificate to validate the signature in the relatedCertRequest certificate to verify the signature in the relatedCertRequest
attribute. attribute.
If a CA receives a CSR that includes the relatedCertRequest attribute If a CA receives a CSR that includes the relatedCertRequest attribute
and that CA supports the attribute, the CA: and that CA supports the attribute, the CA:
* MUST retrieve the certificate identified in the relatedCertRequest * MUST retrieve the certificate identified in the relatedCertRequest
attribute using the information provided in attribute using the information provided in
UniformResourceIdentifier, and validate it using certificate path UniformResourceIdentifier, and validate it using certificate path
validation rules defined in [RFC5280]. The CA then extracts the validation rules defined in [RFC5280]. The CA then extracts the
IssuerAndSerialNumber from the indicated certificate and compares IssuerAndSerialNumber from the indicated certificate and compares
this value against the IssuerAndSerialNumber provided in the this value against the IssuerAndSerialNumber provided in the
certID field of relatedCertRequest. certID field of relatedCertRequest.
* MUST check that the BinaryTime indicated in the requestTime field * MUST check that the BinaryTime indicated in the requestTime field
is sufficiently fresh. Note sufficient freshness is defined by is sufficiently fresh. Note that sufficient freshness is defined
local policy out of scope of this document. by local policy and is out of the scope of this document.
* MUST verify the signature field of the relatedCertRequest * MUST verify the signature field of the relatedCertRequest
attribute. The CA validates the signature using the public key attribute. The CA verifies the signature using the public key
associated with the certificate it located via the info provided associated with the certificate identified by the
in the UniformResourceIdentifier field. The details of the relatedCertRequest attribute. The details of the verification
validation process are outside the scope of this document. process are outside the scope of this document.
* SHOULD issue the new certificate containing the RelatedCertificate * SHOULD issue the new certificate containing the RelatedCertificate
extension as specified in Section 4, which references the extension as specified in Section 4, which references the
certificate indicated in the attribute's IssuerAndSerialNumber certificate indicated in the attribute's IssuerAndSerialNumber
field. The CA may apply local policy regarding the suitability of field. The CA may also apply local policy regarding the
the related certificate, such as validity period remaining. suitability of the related certificate, such as validity period
remaining.
The RA MUST only allow a previously-issued certificate to be The RA MUST only allow a previously issued certificate to be
indicated in the relatedCertRequest attribute in order to enable the indicated in the relatedCertRequest attribute in order to enable the
CA to perform the required signature verification. CA to perform the required signature verification.
The RA MAY send the CA a CSR containing a relatedCertRequest The RA MAY send the CA a CSR containing a relatedCertRequest
attribute that includes the IssuerAndSerialNumber of a certificate attribute that includes the IssuerAndSerialNumber of a certificate
that was issued by a different CA. that was issued by a different CA.
4. Related Certificate 4. Related Certificate
4.1. The RelatedCertificate Extension 4.1. The RelatedCertificate Extension
This section profiles a new X.509v3 certificate extension, This section specifies a new X.509 certificate extension,
RelatedCertificate. RelatedCertificate creates an association RelatedCertificate. RelatedCertificate creates an association
between the certificate containing the RelatedCertificate extension between the certificate containing the RelatedCertificate extension
(Cert B) and the certificate referenced within the extension (Cert (Cert B) and the certificate referenced within the extension (Cert
A). When two end-entity certificates are used in a protocol, where A). When two end-entity certificates are used in a protocol, where
one of the certificates contains a RelatedCertificate extension that one of the certificates contains a RelatedCertificate extension that
references another certificate, the authenticating entity is provided references the other certificate, the authenticating entity is
with additional assurance that all certificates belong to the same provided with additional assurance that both certificates belong to
entity. the same entity.
The RelatedCertificate extension is an octet string that contains the The RelatedCertificate extension contains the hash of a single end-
hash of a single end-entity certificate. entity certificate.
The RelatedCertificate extension has the following syntax: The RelatedCertificate extension has the following syntax:
-- Object Identifiers for certificate extension -- Object Identifier for certificate extension
id-relatedCert OBJECT IDENTIFIER ::= { TBD2 } id-relatedCert OBJECT IDENTIFIER ::= { 36 }
-- X.509 Certificate extension -- X.509 Certificate extension
RelatedCertificate ::= OCTET STRING RelatedCertificate ::= SEQUENCE {
-- hash of entire related certificate } hashAlgorithm AlgorithmIdentifier,
hashValue OCTET STRING }
The extension is comprised of an octet string, which is the digest The extension is a SEQUENCE of two fields. The hashAlgorithm field
value obtained from hashing the entire related certificate identified identifies the hash algorithm used to compute hashValue, which is the
in the CSR attribute defined above, relatedCertRequest. The digest value obtained from hashing the entire related certificate
algorithm used to hash the certificate in the RelatedCertificate identified in the relatedCertRequest CSR attribute defined above. If
extension MUST match the hash algorithm used to sign the certificate there is a hash algorithm explicitly indicated by the related
that contains the extension. certificate's signature OID (e.g., ecdsa-with-SHA512), that hash
algorithm SHOULD be also used for this extension.
This extension SHOULD NOT be marked critical. Marking this extension This extension SHOULD NOT be marked critical. Marking this extension
critical would severely impact interoperability. critical would severely impact interoperability.
For certificate chains, this extension MUST only be included in the For certificate chains, this extension MUST only be included in the
end-entity certificate. end-entity certificate.
For the RelatedCertificate extension to be meaningful, a CA that For the RelatedCertificate extension to be meaningful, a CA that
issues a certificate with this extension: issues a certificate with this extension:
* MUST only include a certificate in the extension that is listed * MUST only include a certificate in the extension that is listed in
and validated in the relatedCertRequest attribute of the CSR the relatedCertRequest attribute of the CSR submitted by the
submitted by the requesting entity. requesting entity.
* MUST ensure that the related certificate at least contains the KU * MUST ensure that the related certificate contains the key usage
bits and EKU OIDs [RFC5280] being asserted in the certificate (KU) bits and extended key usage (EKU) OIDs [RFC5280] being
being issued. asserted in the certificate being issued.
* SHOULD determine that all certificates are valid at the time of * SHOULD determine that the related certificate is valid at the time
issuance. The usable overlap of validity periods is a Subscriber of issuance. The usable overlap with the validity period of the
concern. newly issued certificate is a Subscriber concern.
4.2. Endpoint Protocol Multiple Authentication Processing 4.2. Endpoint Protocol Multiple Authentication Processing
When the preference to use a non-composite hybrid authentication mode When the preference to use a non-composite hybrid authentication mode
is expressed by an endpoint through the protocol itself (e.g., during is expressed by an endpoint through the protocol itself (e.g., during
negotiation), the use of the RelatedCertificate extension and its negotiation), the use of the RelatedCertificate extension and its
enforcement are left to the protocol's native authorization mechanism enforcement are left to the protocol's existing authorization
(along with other decisions endpoints make about whether to complete mechanism (along with other decisions endpoints make about whether to
or drop a connection). complete or drop a connection).
If an endpoint has indicated that it is willing to do non-composite If an endpoint has indicated that it supports non-composite hybrid
hybrid authentication and receives the appropriate authentication authentication and receives the appropriate authentication data, it
data, it should check end-entity certificates (Cert A and Cert B) for should check end-entity certificates (Cert A and Cert B) for the
the RelatedCertificate extension. If present in one certificate, for RelatedCertificate extension. If present in one certificate (e.g.,
example Cert B, it should: Cert B), it should:
* Compute the appropriate hash of Cert A, the other end-entity * Compute the appropriate hash of Cert A, the other end-entity
certificate received. The hash algorithm is the same as the one certificate received.
used to sign the certificate containing the extension.
* Verify that the hash value matches the hash entry in the * Confirm that the hash value matches the hash entry in the
RelatedCertificate extension of Cert B. RelatedCertificate extension of Cert B.
It is outside the scope of this document how to proceed with How to proceed with authentication based on the outcome of this
authentication based on the outcome of this verification process. process is outside the scope of this document. Different
Different determinations may be made depending on each peer's policy determinations may be made depending on each peer's policy regarding
regarding whether both or at least one authentication needs to whether both or at least one authentication needs to succeed.
succeed.
5. Use Case 5. Use Case
The general design of this method is best illustrated through The general design of this method is best illustrated through
specific use within a migration strategy to PQ cryptography via a specific use within a migration strategy to PQC via a non-composite
non-composite hybrid authentication mechanism. The intent is for a hybrid authentication mechanism. The intent is for a CA issuing a
CA issuing a new, PQ certificate to add an X.509 extension that new, post-quantum (PQ) certificate to add an X.509 extension that
provides information about a previously-issued, traditional provides information about a previously issued, traditional
certificate in which the private key is controlled by the same end certificate in which the private key is controlled by the same end
entity as the PQ certificate. entity as the PQ certificate.
In the following scenario, an entity currently has a traditional In the following scenario, an entity currently has a traditional
certificate, and is requesting a new, PQ certificate be issued with certificate and requests that a new, PQ certificate be issued
the RelatedCertificate extension included that references the containing a RelatedCertificate extension, which references the
entity's traditional certificate. entity's traditional certificate.
The RA receives a CSR for a PQ certificate, where the CSR includes The RA receives a CSR for a PQ certificate, where the CSR includes
the relatedCertRequest attribute detailed in this document. The the relatedCertRequest attribute detailed in this document. The
relatedCertRequest attribute includes a certID field that identifies relatedCertRequest attribute includes a certID field that identifies
the entity's previously-issued traditional certificate, and a the entity's previously issued traditional certificate and a
signature field in which the requesting entity produces a digital signature field in which the requesting entity produces a digital
signature over the certID and a timestamp, using the private key of signature over the concatenation of the IssuerAndSerialNumber and
the certificate identified by the certID. BinaryTime, using the private key of the certificate identified by
the IssuerAndSerialNumber.
The purpose of the relatedCertRequest attribute is to serve as a tool The purpose of the relatedCertRequest attribute is to serve as a tool
for the RA to provide assurance to the CA organization that the for the RA to provide assurance to the CA organization that the
entity that controls the private key of the PQ certificate being entity that controls the private key of the PQ certificate being
requested also controls the private key of the referenced, requested also controls the private key of the referenced, previously
previously-issued traditional certificate. issued traditional certificate.
Upon receipt of the CSR, the CA issues a PQ certificate to the Upon receipt and validation of the CSR, the CA issues a PQ
requesting entity that includes the RelatedCertificate extension certificate to the requesting entity that includes the
detailed in this document; the extension includes a hash of the RelatedCertificate extension detailed in this document; the extension
entire traditional certificate identified in the CSR. The X.509 includes a hash of the entire traditional certificate identified in
extension creates an association between the PQ certificate and the the CSR. The X.509 extension creates an association between the PQ
traditional certificate via end-entity ownership. certificate and the traditional certificate via an assertion of end-
entity ownership.
The attribute and subsequent extension together provide assurance The attribute and subsequent extension together provide assurance
from the CA organization that the same end-entity controls the from the CA organization that the same end entity controls the
private keys of both certificates. It is neither a requirement nor a private keys of both certificates. It is neither a requirement nor a
mandate that either certificate be used with the other; it is simply 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 an assurance that they can be used together, as they are under the
control of the same entity. control of the same entity.
6. CA Organization Considerations 6. CA Organization Considerations
The relatedCertRequest CSR attribute provides assertion to the CA The relatedCertRequest CSR attribute asserts end-entity control of
organization issuing Cert B, of end entity control of the private key the private key associated with a related certificate (Cert A) to the
of a related certificate, Cert A. There may arise scenarios where a CA organization issuing a new certificate (Cert B). A public-facing
public-facing CA organization is not configured to validate CA organization may not be configured to validate certificates that
signatures associated with certificates that have been issued by a have been issued by different CA organizations. In this case,
different CA organization. In this case, recognition of the contents recognition of the contents in the relatedCertRequest attribute may
in the relatedCertRequest attribute may be contingent upon a pre- necessitate pre-arrangement, e.g., a contract with pre-configured
arranged contract with pre-configured trust anchors from the other CA trust anchors from another CA organization and agreements regarding
organization, and include agreements on certificate policy with policies concerning certificate application, issuance, and
regards to certificate application, issuance, and acceptance. 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 Continuing with this scenario, in order for the CA organization to
can recognize the relatedCertRequest attribute in the CSR and wishes ensure that Cert B is issued under security parameters comparable to
to issue the certificate with the RelatedCerts extension, it may be Cert A, the issuing CA organization should match the issued
the case that a different CA organization issued the related certification policies to the related ones. The issuing CA
certificate referenced in the CSR. In order to ensure that the organization, as part of its validation of Cert A, ascertains what
certificates have been issued under homogeneous sets of security policies are asserted in Cert A’s certification path and determines
parameters, the certificate policies should be the same with regard which of their own certification policies will best ensure that the
to common security requirements. The issuing CA, as part of related protection of the private key associated with Cert B is comparable to
certificate public key validation, determines what policies are that of Cert A. The relatedCertRequest attribute and subsequent
acceptable for the certification path of the related certificate. RelatedCertificate certificate extension are solely intended to
The issuing CA determines what is acceptable to them in terms of provide assurance that both private keys are controlled by the same
certificate policy, to ensure that the policies for protection of end entity.
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 7. Security Considerations
This document inherits security considerations identified in This document inherits security considerations identified in
[RFC5280]. [RFC5280].
The mechanisms described in this document provide only a means to The mechanisms described in this document provide only a means to
express that multiple certificates are related. They are intended express that multiple certificates are related. They are intended
for the interpretation of the recipient of the data in which they are 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 embedded (i.e., a CSR or certificate). They do not by themselves
effect any security function. effect any security function.
Authentication, unlike key establishment, is necessarily a one-way Authentication, unlike key establishment, is necessarily a one-way
arrangement. That is, authentication is an assertion made by a arrangement. That is, authentication is an assertion made by a
claimant to a verifier. The means and strength of mechanism for claimant to a verifier. The means and strength of the authentication
authentication have to be to the satisfaction of the verifier. A mechanism have to be satisfactory to the verifier. A system security
system security designer needs to be aware of what authentication designer needs to be aware of what authentication assurances are
assurances are needed in various parts of the system and how to needed in various parts of the system and how to achieve that
achieve that assurance. In a closed system (e.g. Company X assurance. In a closed system (e.g., Company X distributing firmware
distributing firmware to its own devices) the approach may be to its own devices), the approach may be implicit. In an online
implicit. In an online protocol like IPsec where the peers are protocol like IPsec where the peers are generally known, any
generally known, any mechanism selected from a pre-established set mechanism selected from a pre-established set may be sufficient. For
may be sufficient. For more promiscuous online protocols, like TLS, more promiscuous online protocols like TLS, the ability for the
the ability for the verifier to express what is possible and what is verifier to express what is possible and what is preferred -- and to
preferred - and to assess that it got what it needed - is important. assess that its requirements were met -- is important.
A certificate is an assertion of binding between an identity and a A certificate is an assertion of binding between an identity and a
public key. However, that assertion is based on several other public key. However, that assertion is based on several other
assurances, specifically, that the identity belongs to a particular assurances, especially that the identity belongs to a particular
physical entity, and that that physical entity has control over the physical entity and that the physical entity has control over the
private key corresponding to the public. For any hybrid approach, it private key corresponding to the public key. For any hybrid
is important that there be evidence that the same entity controls all approach, it is important that there be evidence that the same entity
private keys at time of use (to the verifier) and at time of controls all private keys at time of use (to the verifier) and at
registration (to the CA). time of registration (to the CA).
All hybrid implementations are vulnerable to a downgrade attack in All hybrid implementations are vulnerable to a downgrade attack in
which a malicious peer does not express support for the stronger which a malicious peer does not express support for the stronger
algorithm, resulting in an exchange that can only rely upon a weaker algorithm, resulting in an exchange that can only rely upon a weaker
algorithm for security. algorithm for security.
Implementors should be aware of risks that arise from the retrieval Implementors should be aware of risks that arise from the retrieval
of a related certificate via the UniformResourceIdentifier provided of a related certificate via the UniformResourceIdentifier provided
in the relatedCertRequest CSR attribute, if the URI points to in the relatedCertRequest CSR attribute, as a URL can point to
malicious code. Implementors should ensure the data is properly malicious code. Implementors should ensure the data is properly
formed and validate the retrieved data fully. formed and validate the retrieved data fully.
CAs should be aware that retrieval of existing certificates may be CAs should be aware that retrieval of existing certificates may be
subject to observation; if this is a concern, it may be advisable to subject to observation; if this is a concern, it is advisable to use
use the dataURI option described in Section 3.1. the dataURI option described in Section 3.1.
8. IANA Considerations 8. IANA Considerations
This document defines an extension for use with X.509 certificates. This document defines an extension for use with X.509 certificates.
IANA is requested to register the following OID in the SMI Security IANA has registered the following OID in the "SMI Security for PKIX
for PKIX Certificate Extension registry: Certificate Extension" registry (1.3.6.1.5.5.7.1):
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 } +=========+===================+============+
| Decimal | Description | References |
+=========+===================+============+
| 36 | id-pe-relatedCert | RFC 9763 |
+---------+-------------------+------------+
with this document as the Required Specification. Table 1
This document defines a CSR attribute. IANA is requested to register The registration procedure is Specification Required [RFC8126].
the following OID in the SMI Security for S/MIME Attributes registry:
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 } 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 is +=========+==========================+============+
requested to register an OID for the module identifier in the SMI | Decimal | Description | References |
Security for PKIX Module Identifier registry: +=========+==========================+============+
| 60 | id-aa-relatedCertRequest | RFC 9763 |
+---------+--------------------------+------------+
id-mod-related-cert(TBD0) Table 2
The RFC Editor is requested to replace the TBDs in the text with the This document defines an ASN.1 module in Appendix A. IANA has
assigned OIDs. 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):
+=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| 115 | id-mod-related-cert-2023 | RFC 9763 |
+---------+--------------------------+------------+
Table 3
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 29 skipping to change at line 559
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019, Representing Date and Time in ASN.1", RFC 6019,
DOI 10.17487/RFC6019, September 2010, DOI 10.17487/RFC6019, September 2010,
<https://www.rfc-editor.org/info/rfc6019>. <https://www.rfc-editor.org/info/rfc6019>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[NIST-SP-800-57]
Barker, E., "Recommendation for Key Management: Part 1 -
General", National Institute of Standards and Technology,
NIST SP 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, May
2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268, Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011, DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>. <https://www.rfc-editor.org/info/rfc6268>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
The following RelatedCertificate ASN.1 module describes the The following RelatedCertificate ASN.1 module describes the
RequesterCertificate type found in the relatedCertAttribute. It RequesterCertificate type found in the relatedCertAttribute. It
pulls definitions from modules defined in [RFC5912], and [RFC6268], pulls definitions from modules defined in [RFC5912] and [RFC6268] for
and [RFC6019] for the IssuerAndSerialNumber type, and BinaryTime the IssuerAndSerialNumber type and in [RFC6019] for the BinaryTime
type, respectively. type.
RelatedCertificate { iso(1) identified-organization(3) dod(6) RelatedCertificate { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 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 ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
ATTRIBUTE, EXTENSION ATTRIBUTE, EXTENSION
FROM PKIX-CommonTypes-2009 -- in [RFC5912] FROM PKIX-CommonTypes-2009 -- in RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } id-mod-pkixCommon-02(57) }
IssuerAndSerialNumber IssuerAndSerialNumber
FROM CryptographicMessageSyntax-2010 -- in [RFC6268] FROM CryptographicMessageSyntax-2010 -- in RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) } id-mod-cms-2009(58) }
BinaryTime BinaryTime
FROM BinarySigningTimeModule -- in [RFC6019] FROM BinarySigningTimeModule -- in RFC 6019
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-binarySigningTime(27) } ; id-mod-binarySigningTime(27) } ;
-- Object identifier arcs -- Object identifier arcs
id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) }
-- relatedCertificate Extension -- relatedCertificate Extension
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 } id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 }
RelatedCertificate ::= OCTET STRING
RelatedCertificate ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OCTET STRING }
ext-relatedCertificate EXTENSION ::= { ext-relatedCertificate EXTENSION ::= {
SYNTAX RelatedCertificate SYNTAX RelatedCertificate
IDENTIFIED BY id-pe-relatedCert } IDENTIFIED BY id-pe-relatedCert }
-- relatedCertRequest Attribute -- relatedCertRequest Attribute
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa TBD1 } id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
RequesterCertificate ::= SEQUENCE { RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber, certID IssuerAndSerialNumber,
requestTime BinaryTime, requestTime BinaryTime,
locationInfo UniformResourceIdentifier, locationInfo UniformResourceIdentifier,
signature BIT STRING } signature BIT STRING }
UniformResourceIdentifier ::= IA5String UniformResourceIdentifier ::= IA5String
aa-relatedCertRequest ATTRIBUTE ::= { aa-relatedCertRequest ATTRIBUTE ::= {
 End of changes. 81 change blocks. 
269 lines changed or deleted 305 lines changed or added

This html diff was produced by rfcdiff 1.48.