Related Certificates for Use in Multiple Authentications within a Protocol

1.1. Overview

The general roadmap of this design is best illustrated via an entity (device, service, user token, etc.) that has an existing traditional certificate and requests a new PQ certificate, perhaps as part of an organization's migration to post-quantum cryptography. After the PQ certificate is issued, the use of the PQ and traditional certificates will depend on the protocols it supports and the organization's transition strategy.¶

• For protocols where authentication is not negotiated, and rather is limited by what the signer offers, such as in CMS and S/MIME, either the traditional signing key, the PQ signing key, or both signing keys may be invoked, according to which validators the signer anticipates.¶
• For protocols where authentication is negotiated in-protocol, such as TLS and IKEv2, either the traditional or PQ 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 traditional and PQ authentication are used.¶

[It is possible for a strategy to comprise non-composite (such as described here) and composite schemes (as defined in [I-D.draft-ounsworth-pq-composite-sigs]). Because the mechanisms described in this document are not intended to effect composite certificate issuance, we do not further explore such a strategy.]¶

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 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 the traditional certificate and then verifies ownership before generating the PQ certificate.¶

3.1. The relatedCertRequest Attribute

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 { TBD }
}

RequesterCertificate ::= SEQUENCE {
     certID        IssuerAndSerialNumber
     requestTime   BinaryTime
     locationInfo  AccessDescription
     signature     BIT STRING
}

The RequesterCertificate type has four fields:¶

• The certID field uses the IssuerAndSerialNumber type [RFC5652] to identify a previously issued end-entity certificate that the requesting entity also owns. IssuerAndSerialNumber is repeated here for convenience:¶

IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }

    CertificateSerialNumber ::= INTEGER

• The requestTime field uses the BinaryTime type [RFC6019] 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:¶

BinaryTime ::= INTEGER (0..MAX)

• The locationInfo field uses AccessDescription [RFC5280] to provide information on the location of the other certificate the requesting entity owns. AccessDescription is repeated here for convenience:¶

AccessDescription  ::= SEQUENCE {
    accessMethod         id-ad-relatedCerts,
    accessLocation       GeneralName }

id-ad-relatedCerts OBJECT IDENTIFIER ::= { TBD }

- The accessMethod value is id-ad-relatedCerts, which is used when the subject is an end-entity that owns certificates published in a repository.¶

- The accessLocation value SHOULD be available via HTTP or FTP, and therefore must be a URI that points to a file containing a certificate or certificate chain that the requesting entity owns, as detailed in [RFC5280] . The file must permit access to a PKCS#7 'certs-only' repository containing either a single DER encoded X.509 certificate or an entire certificate chain.¶

• 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 (without tag and length). 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 KE certificate, use the ECC KE 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.¶

3.2. CSR Processing

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 is equipped to recognize and understand the attribute the CA:¶

• MUST retrieve and validate the certificate identified in the relatedCertRequest using the information provided in AccessDescription. The CA then extracts the IssuerAndSerialNumber from the indicated certificate and compares this value against the IssuerAndSerialNumber provided in the certID field of relatedCertRequest.¶
• MUST check that the BinaryTime indicated in the requestTime field is sufficiently fresh.¶
• MUST 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 AccessDescription field. The details of the validation process are outside the scope of this document.¶
• SHOULD issue the new certificate containing the RelatedCertificate extension as specified in [Section 4], which references the certificate indicated in the attribute's IssuerAndSerialNumber field.¶

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

4.1. The RelatedCertificate Extension

This section profiles a new X.509v3 certificate extension, RelatedCertificate. RelatedCertificate creates an association between the certificate containing the RelatedCertificate extension and the certificate referenced within the extension. 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 a list of entries, where each entry contains data that uniquely identifies a distinct end-entity certificate.¶

The RelatedCertificate extension has the following syntax:¶

--  Object Identifiers for certificate extension
  id-relatedCertificate OBJECT IDENTIFIER ::= { TBD }

--  X.509 Certificate extension
  RelatedCertificate ::= OCTET STRING
                -- hash of 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.¶

ED NOTE: We recognize the following SCVP structure from [RFC5055] may be preferable to defining a new extension, however, it adds extra bytes of options for the hash function that may be deemed unnecessary for the RelatedCertificates extension. The structure is repeated here for convenience:¶

SCVPCertID ::= SEQUENCE {
    certHash       OCTET STRING,
    IssuerSerial   SCVPIssuerSerial,
    hashAlgorithm  AlgorithmIdentifier DEFAULT {algorithm sha-1}}

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

• MUST only include a certificate in the extension that is listed and validated in the relatedCertRequest attribute of the CSR submitted by the requesting entity.¶
• MUST ensure that all certificates are intended for the same use case. For example, the CA must ensure that both certificates have the same key usage [RFC5280]. The intended purpose of the certificate may be determined by policy or other means (e.g KU, EKU OIDS) but this is outside the scope of this document.¶
• SHOULD determine that all certificates are valid at the time of issuance.  The usable overlap of validity periods is a Subscriber concern.¶

4.2. Endpoint Protocol Multiple Authentication Processing

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 for the RelatedCertificate extension. If present in one certificate, it SHOULD:¶

• Compute the appropriate hash of the other end-entity certificate received. The hash algorithm is the same as the one used to sign the certificate containing the extension.¶
• Verify that the hash value matches the hash entry in the RelatedCertificate extension.¶

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