Internet-Draft Related Certificates June 2022
Becker, et al. Expires 31 December 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-becker-guthrie-cert-binding-for-multi-auth-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Becker
NSA
R. Guthrie
NSA
M. Jenkins
NSA

Related Certificates for Use in Multiple Authentications within a Protocol

Abstract

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.

Status of This Memo

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 31 December 2022.

Table of Contents

1. Introduction

The goal of this document is to define a method for providing assurance that multiple 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 post-quantum (PQ) migration 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) 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 attestation.

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.

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

2. Requirements Language

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

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:

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

    CertificateSerialNumber ::= INTEGER

BinaryTime ::= INTEGER (0..MAX)
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 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:

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:

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:

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.

5. 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 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 PQ algorithms, resulting in an exchange that can only rely upon traditional algorithms for security.

6. IANA Considerations

This document defines an extension for use with X.509 certificates. IANA is requested to register an OID in the PKIX certificate extensions arc [RFC7299]:

id-relateddCert OBJECT IDENTIFIER ::= { id-pkix 1 tbd }

with this document as the Required Specification.

This document also defines a CSR attribute. IANA is requested to register an OID:

id-relatedCertRequest OBJECT IDENTIFIER ::= { tbd }

An additional OID for a specific accessMethod is requested:

id-ad-relatedCert OBJECT IDENTIFIER ::= { tbd }

7. References

[I-D.draft-ounsworth-pq-composite-sigs]
Ounsworth, M. and M. Pala, "Composite Signatures For Use In Internet PKI", , <https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/06/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5055]
Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, DOI 10.17487/RFC5055, , <https://www.rfc-editor.org/info/rfc5055>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/info/rfc5652>.
[RFC6019]
Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, DOI 10.17487/RFC6019, , <https://www.rfc-editor.org/info/rfc6019>.
[RFC7299]
Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, , <https://www.rfc-editor.org/info/rfc7299>.

Authors' Addresses

Alison Becker
National Security Agency
Rebecca Guthrie
National Security Agency
Michael Jenkins
National Security Agency