Syntaxes for Unambiguous Naming of Certificates and Public Keys
draft-ietf-pkix-certid-keyid-00

Abstract

This document provides methods to unambiguously identify a particular certificate and a particular public key that may or may not be in a certificate. This document further provides syntaxes for these methods in the otherName field of a GeneralName structure, as used throughout the PKIX standards.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 8, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

1.  Introduction

When working with X.509 certificates and other cryptographic structures, it may be desirable to refer to another certificate, or to a raw public key, directly and unambiguously. The "gold standard" for certificates is to refer to the certificate's issuer name and serial number. Furthermore, [PKIX] (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,” May 2008.) and [X.509] (ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, “Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks,” .) define a subject key identifier extension, which provides a means of identifying distinct keys used by the same subject.

Unfortunately, neither the issuer name and serial number, nor the subject key identifier, are guaranteed to be universally unique. Multiple CA certificates can share the same subject name, and their use depends on the state of the trust anchors during certificate path validation. The subject key identifier is meant to facilitate path construction [PKIX] (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,” May 2008.), but is only unique to the extent that the certificate issuer guarantees it to be unique within some domain.

Therefore, this document provides a pair of ASN.1 structures to unambiguously identify a particular certificate and a particular public key. The method used here follows the same philosophy as the CertID (ESSCertIDv2 structure) in RFC 5035 (Schaad, J., “Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility,” August 2007.): digest the target with a cryptographic hash algorithm, and optionally refer to the target using standardized naming. Using this method, an implementation can cryptographically verify that the right certificate or public key is chosen, but can also use standard methods to locate the certificate or public key if the search facility does not index by the particular hash.

This document further defines otherName syntaxes for these structures, suitable for experession in a GeneralName. That way, any protocol or format that uses a GeneralName or GeneralNames can unambiguously name a certificate or key.

1.1.  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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  CertID Structure for Identifying Certificates

The following structure unambiguously identifies a certificate by its hash. This structure is simply ESSCertIDv2 from RFC 5035 (Schaad, J., “Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility,” August 2007.), with additional clarifying semantics discussed below.

  CertID ::= ESSCertIDv2

ESSCertIDv2 is reproduced below for convenience.

    ESSCertIDv2 ::=  SEQUENCE {
        hashAlgorithm           AlgorithmIdentifier
               DEFAULT {algorithm id-sha256},
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
    }

    Hash ::= OCTET STRING

    IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
    }

The fields of CertID (ESSCertIDv2, as used here) are defined as follows.

hashAlgorithm contains the identifier of the algorithm used in computing certHash.

certHash is computed over the entire DER-encoded certificate, including the signature, tag, and length octets, using the algorithm specified in hashAlgorithm.

issuerSerial holds the identification of the certificate. issuerSerial is optional. If present, it may be used to facilitate lookup of the certificate. Additionally, an implementation may use issuerSerial to eliminate a certificate from consideration early if the implementation does not support the certificate type.

The issuerSerial field is normative if it is present. Specifically, if a certificate is found that matches the issuerSerial, but does not match the hash, an implementation MUST skip or reject that certificate, because it does not match the hash. If a certificate is found that matches the hash, but does not match the issuerSerial, an implementation MUST skip or reject that certificate, because it does not match the issuerSerial. The assumption is that the implementation that generated CertID must have the certificate and must be able to process it in order to create a proper issuerSerial for it.

The semantics of issuerSerial are the same as those in RFC 5035 (Schaad, J., “Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility,” August 2007.).

3.  KeyID Structure for Identifying Public Keys

Unlike the CertID structure, there is no corresponding universal structure (among the various standards surveyed) to unambiguously name a public key. This section defines KeyID, which is such a structure.

  KeyID ::= CHOICE {
    subjectPublicKeyInfo  [0] SubjectPublicKeyInfo,
    subjectPublicKeyRef   [1] SubjectPublicKeyRef }

  SubjectPublicKeyRef ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier
      DEFAULT {algorithm id-sha256},
    keyHash Hash,
    subjectPublicKeyAlgorithm AlgorithmIdentifier OPTIONAL,
    subjectKeyIdentifier SubjectKeyIdentifier OPTIONAL,
    subjectKeyCert ESSCertIDv2 OPTIONAL }

A KeyID is a CHOICE of a SubjectPublicKeyInfo, defined in [PKIX] (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,” May 2008.), or a SubjectPublicKeyRef, defined here. When KeyID is a SubjectPublicKeyInfo, the public key is simply the public key inside of the SubjectPublicKeyInfo. When KeyID is a SubjectPublicKeyRef, the public key is the one that matches the following parameters in the SubjectPublicKeyRef.

SubjectPublicKeyRef includes a hashAlgorithm and a keyHash. The keyHash is the output of the hash algorithm identified by hashAlgorithm computed over the entire DER-encoded SubjectPublicKeyInfo, including the tag and length octets.

subjectPublicKeyAlgorithm, subjectKeyIdentifier, and subjectKeyCert may be included to facilitate lookup of the public key. Additionally, an implementation may use subjectPublicKeyAlgorithm to eliminate a public key from consideration early if the implementation does not support the algorithm, or does not have any keys derived for use with the algorithm.

The subjectPublicKeyAlgorithm field is normative if it is present. When subjectPublicKeyAlgorithm is present, the public key MUST have an AlgorithmIdentifier that matches, in addition to a matching keyHash.

If subjectKeyIdentifier or subjectKeyCert are present, an implementation MAY use these identifiers to look up a subject public key. Unlike subjectPublicKeyAlgorithm, these identifiers are not normative. Specifically, if a public key is found that is contained within a certificate that matches the particular subjectKeyIdentifier, subjectKeyCert, or both, but does not match the hash and subjectPublicKeyAlgorithm (if present), an implementation MUST skip or reject that public key, because it does not match the hash and subjectPublicKeyAlgorithm (if present). If public key #1 is found that matches the hash and subjectPublicKeyAlgorithm (if present), but public key #1 differs from public key #2 in a certificate identified by subjectKeyIdentifier, subjectKeyCert, or both, the implementation MUST select public key #1. Similarly, if an implementation finds a public key #3 that matches the hash and subjectPublicKeyAlgorithm (if present), but cannot find a certificate that matches subjectKeyIdentifier, subjectKeyCert, or both, the implementation MUST select public key #3. The implementation MUST NOT reject public key #3 on the basis that the certificate is missing.

This document does not define the results if two different public keys match the same hash and subjectPublicKeyAlgorithm (if present), irrespective of whether a single key or certificate containing a key matches on the other fields. However, a sensible approach would be to reject both keys, and to consider the result a hash collision.

When generating a KeyID, an implementation may generate a SubjectPublicKeyInfo or a SubjectPublicKeyRef. When processing a KeyID, an implementation that complies with this document MUST process both SubjectPublicKeyInfo and SubjectPublicKeyRef.

When generating a SubjectPublicKeyRef, an implementation MUST only generate subjectKeyCert and subjectKeyIdentifier fields that it believes to be true. For example, if a certificate #4 contains a subjectKeyIdentifier 'ABCD'h, the implementation may serialize the subjectKeyIdentifier in the SubjectPublicKeyRef structure as 'ABCD'h, or may omit it entirely. An implementation MAY also choose to serialize the subjectKeyIdentifier as a value that it received or generated via another method, such as from another certificate. However, this document RECOMMENDS that the subjectKeyIdentifier be the same subjectKeyIdentifier as recorded in the certificate #4, when certificate #4 contains a subjectKeyIdentifier.

Other than these requirements, an implementation may choose any subjectKeyCert or subjectKeyIdentifier at its discretion. No semantic meaning is inferable from choosing a particular subjectKeyCert or subjectKeyIdentifier. However, generating these fields based on information that the receiver is most likely to have, such as by including the named certificate as part of the broader protocol, would be sensible.

Generating a KeyID that is a public key by value (SubjectPublicKeyInfo) is useful when the public key is sufficiently small, such as an elliptic curve public key. By way of example, a SHA-512 hash is 64 octets. A DER-encoded SubjectPublicKeyRef that identifies a key using SHA-512 will be at least 81 octets; with a subjectKeyCert, it will likely be 160 octets or more. In contrast, an ECC key with a 256-bit prime modulus has a DER-encoded SubjectPublicKeyInfo of approximately (TBD) octets. The savings in size alone, not to mention the time saved looking up the public key from a database, warrant including the public key by value with SubjectPublicKeyInfo instead of by reference with SubjectPublicKeyRef.

A KeyID can only refer to a public key of an asymmetric keypair; it MUST NOT refer to a symmetric key or to an asymmetric private key. The Security Considerations (Security Considerations) section provides further discussion.

4.  GeneralName Definitions

This section defines the CertIDName and KeyIDName as forms of otherName in the GeneralName structure defined in [PKIX] (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,” May 2008.).

When referring to certificates, this document does not limit the selection to X.509 public key certificates. The IssuerSerial structure [RFC5035] (Schaad, J., “Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility,” August 2007.) contains a GeneralNames field that can accomodate other types of certificates, such as attribute certificates.

4.1.  CertIDName

A CertIDName has the following object identifier and syntax when used in a GeneralName.

  id-on-certID OBJECT IDENTIFIER ::= { id-on TBD }

  CertIDName ::= CertID

4.2.  KeyIDName

A KeyIDName has the following object identifier and syntax when used in a GeneralName.

  id-on-keyID OBJECT IDENTIFIER ::= { id-on TBD }

  KeyIDName ::= KeyID

4.3.  Usage Guide

GeneralName is a very versatile structure because it appears in many cryptographic protocols. This document does not define all the possible circumstances in which a GeneralName/otherName with id-on-certID or id-on-keyID may occur, or the complete semantics in such circumstances. However, some possible (non-normative) usages follow.

When a protocol uses one or more GeneralNames to name services or endpoints, id-on-certID and id-on-keyID might constrain the service or endpoint to use the particular named certificate or key. For example, if a service is named in the Authority Information Access extenison of an X.509 certificate, a GeneralName with otherName id-on-certID might constrain the service so that it can only be accessed when it presents the associated certificate.

The CertIDName and KeyIDName GeneralName types are not intended to change or extend certificate validation procedures. In the previous example, using id-on-certID merely names a service by its certificate. How the client locates the service, and whether the client accepts the service's certificate, are separate matters. A client might use the optional issuerSerial in CertIDName to retrieve the certificate, which the client validates using the the certificate path validation algorithm. If valid, the certificate may then provide a subject alternative name containing a uniformResourceIdentifier or dNSName to access the service using TCP/IP. A client would not access the service unless the certificate is valid, which the client determines as a local matter.

5.  Acknowledgements

The author thanks Russ Housley and Jim Schaad for direction and guidance during the development of this document.

6.  IANA Considerations

This memo includes no request to IANA.

7.  Security Considerations

The CertID and KeyID structures defined here provide integrity checking of the named certificate or key, but are not themselves integrity-checked. An implementer should use these structures within other integrity-checked structures, such as within X.509 public key or attribute certificates.

Weak hash algorithms will limit the utility of these structures. An implementation must skip or reject certificates or keys when the cryptographic integrity of the hash function is in doubt. On the other hand, an advanced algorithm may not be broadly compatible with all possible relying parties. Implementers should be aware of this tension when choosing a hash algorithm.

A KeyID MUST NOT refer to a symmetric key or to an asymmetric private key. Referring to such keys by value (with SubjectPublicKeyInfo) would destroy the security properties of keeping such keys secret, since KeyID is intended for use in public documents such as certificates or other signed objects. Similar considerations apply to referring to such keys by reference (with SubjectPublicKeyRef). Additionally, RFC 5280 (PKIX) (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,” May 2008.) and RFC 3279 (Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.) fix the semantics of SubjectPublicKeyInfo (and by extension, SubjectPublicKeyRef) to asymmetric public keys.

The GeneralName syntaxes in Section 4 (GeneralName Definitions) only provide "name" semantics; "bind" semantics are not implied. In particular, an X.509 public key certificate binds a subject named in the subject Name field and the subjectAltName extension to a single public key. The mere use of CertIDName or KeyIDName in such a certificate does not bind the subject to additional public keys. However, other specifications are free to create "bind" semantics within their scopes.

8. Normative References

Appendix A.  ASN.1 Modules

This Appendix will provide ASN.1 modules in a future revision.

A.1.  1988 ASN.1 Module

TBD

Author's Address