Binding Certificates for Multiple Authentications within a Protocol

3.1. The bindingRequest Attribute

This section defines a CSR attribute [RFC2986] 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:¶

bindingRequest ATTRIBUTE ::= {
    WITH SYNTAX BindingInfo
    ID {TBD?}
}

BindingInfo ::= SEQUENCE OF RequesterCertificate

RequesterCertificate ::= SEQUENCE {
     certID    IssuerAndSerialNumber
     signature BIT STRING
}

The RequesterCertificate type uses IssuerAndSerialNumber [RFC5652], repeated here for convenience.¶

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

    CertificateSerialNumber ::= INTEGER

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

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

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

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

--  X.509 Certificate extension
  BoundCertificates ::= SEQUENCE OF CertHash
                         -- hash of IssuerAndSerialNumber

--  Data types
  CertHash ::= SEQUENCE {
       hashAlgorithm  AlgorithmIdentifier,
       hashValue      OCTET STRING }

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

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

    CertificateSerialNumber ::= INTEGER

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

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