Binding Certificates for Multiple Authentications within a Protocol
National Security Agency
aebecke@uwe.nsa.gov
National Security Agency
rmguthr@uwe.nsa.gov
National Security Agency
mjjenki@cyber.nsa.gov
This document defines a new CSR attribute, bindingRequest, and a new X.509 certificate extension, BoundCertificates. The use of the bindingRequest attribute in a CSR and the inclusion of the BoundCertificates extension in the resulting certificate together provide additional assurance that multiple 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 PQ algorithms.
Introduction
The goal of this document is to define a method for binding together multiple X.509 (aka PKIX) end-entity certificates in order to perform multiple authentications, where each certificate corresponds to a distinct digital signature, while minimizing changes to the certificate format 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, BoundCertificates, that signals that the certificate containing the extension is able to be used in combination with other certificate(s).
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 bindingRequest, that permits an RA to make such an attestation.
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
Binding CSR to Certificates
The bindingRequest Attribute
This section defines a CSR attribute designed to allow the RA to attest that the owner of the public key on the CSR also owns the public key associated with each end-entity certificate identified in this attribute. The bindingRequest attribute indicates previously-issued certificate(s) that the requesting entity owns and wants linked to the new certificate requested through the CSR.
The bindingRequests attribute has the following syntax:
The RequesterCertificate type uses IssuerAndSerialNumber , repeated here for convenience.
The BindingInfo type is defined as a SEQUENCE OF RequesterCertificate type, which is a SEQUENCE of IssuerAndSerialNumber and signature.
BindingInfo includes a RequesterCertificate type for each certificate that the requesting entity would like linked to the CSR.
The RequesterCertificate type has two fields:
- The IssuerAndSerialNumber field identifies an end-entity certificate that the requesting entity would like linked to the CSR.
- The signature field provides evidence that the requesting entity owns this certificate. Specifically, the signature field contains a digital signature over IssuerAndSerialNumber, using the signature algorithm and private key associated with the certificate identified by the IssuerAndSerialNumber field.
The validation of this signature by the CA ensures that the owner of the CSR also owns the certificate(s) indicated in the bindingRequest attribute.
CSR Processing
If a CA receives a CSR containing the bindingRequest attribute, the CA:
- MUST verify the signature field(s) of the attribute. The CA validates the signature(s) using the public key associated with the certificate identified by the corresponding IssuerAndSerialNumber field. The details of the validation process are outside the scope of this document.
- SHOULD issue the certificate containing a BoundCertificates extension as specified in [Section 4], which references the associated certificate(s) indicated in the attribute.
The RA should only allow previously issued certificate(s) to be indicated in the bindingRequest attribute, to enable the CA to perform the signature verification described above.
It is not required that the requesting entity only include certificates in the bindingRequests attribute that were issued by the CA the CSR is being submitted to.
Binding Certificates
The BoundCertificates Extension
This section profiles a new X.509v3 certificate extension, BoundCertificates. BoundCertificates creates an association between the certificate containing the BoundCertificates extension and the certificate(s) referenced in the extension. When multiple end-entity certificates are used in a protocol, where one of the certificates contains a BoundCertificates extension that references another certificate(s), the authenticating entity is provided with additional assurance that all certificates belong to the same entity.
The BoundCertificates extension is a list of entries, where each entry contains data that uniquely identifies a distinct end-entity certificate.
The BoundCertificates extension has the following syntax:
The CertHash hashValue is the digest value obtained from hashing the DER-encoded IssuerAndSerialNumber type from [RFC5652, Section 10.2.4] with the hash function identified in hashAlgorithm. This type is repeated here for convenience:
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 BoundCertificates extension to be meaningful, a CA that issues a certificate with this extension:
- MUST only include CertHash types for certificates that were listed and validated in the bindingRequest attribute of the CSR submitted by the requesting entity.
- MUST ensure that all certificates are intended for the same use case.
- SHOULD determine that all certificates are valid at the time of issuance. The usable overlap of validity periods is a Subscriber concern.
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, the use of the BoundCertificates 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 capable of non-composite hybrid authentication, and receives the appropriate authentication data, it SHOULD check end-entity certificates for the BoundCertificates extension. If present in one certificate, it SHOULD:
- Use the hash algorithm given in the extension to compute the appropriate hash of the DER-encoded IssuerAndSerialNumber of the other end-entity certificate(s) received.
- Verify that the hash value matches a hashValue in the BoundCertificates extension.
It is outside the scope of this document how to proceed with authentication based on the outcome of this verification process.
Security Considerations
This document inherits security considerations identified in .
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.
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 :
with this document as the Required Specification.
This document also defines a CSR attribute. IANA is requested to register an OID:
References