A Uniform Resource Name (URN) Namespace for Certificates

Digital certificates are used in many systems and protocols to identify and authenticate parties. Security considerations frequently require that the certificate must be identified with certainty, because selecting the wrong certificate will lead to validation errors (resulting in denial of service) or improper credential selection (resulting in unwanted disclosure or substitution attacks). The goal of this namespace is to provide a uniform syntax for identifying certificates with precision in Uniform Resource Identifiers (URIs), specifically Uniform Resource Names (URNs). Using this syntax, any protocol or system that refers to a certificate in a textual format can unambiguously identify that certificate by value or reference. Implementers that parse these URNs can resolve them into actual certificates. Examples:

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.

Although certificates have diverse applications, there has been traditionally no way to refer to a certificate uniformly and unambiguously by reference in text. Certificates that identify long public keys (e.g., 2048-bit RSA keys) and that contain required and recommended PKIX extensions can easily exceed many kilobytes in length, which are impractical for certain applications to store by value. The purpose of this specification is to provide a uniform textual format for identifying individual certficates. When a resolver resolves a certificate specification, the resolver's output is either a single certficiate or nothing. This specification is not designed or intended to provide a search tool or query language to match multiple certificates. Identifying a specific certificate by reference or value allows diverse applications to have a common syntax. For example, applications can store certspecs as local or shared preferences, so that users can edit them without resorting to application-specific storage formats. When conveyed in protocol, a certspec can identify a specific certificate to a client or server using text-based formats such as YAML, XML, JSON, and others.

The Namespace Specific String (NSS) portion of a certspec has the following ABNF specification:

hexOctet = hexDigit hexDigit hexDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F"]]>

The spec-type identifies the certificate specification type. The acceptable characters for spec-type are the same as an URI scheme name Section 3.1 of . spec-types are compared case-insensitively. The spec-value identifies the certificate specification value. The acceptable characters for spec-value depend on the spec-type.

A certspec can include attributes that are associated with the identified certificate. These attributes do NOT affect certificate identification; the syntax is intended primarily to convey certificate metadata such as attributes found in PKCS #9, PKCS #11, PKCS #12, and particular implementations of cryptographic libraries. The characters of certattrs can be any valid URN character from (effectively, any URI character from except "[" and "]"). This Internet-Draft does not further define certattrs.

A certificate specification (certspec) unambiguously identifies a single certificate. A certificate has exactly one canonical certspec per applicable definition (irrespective of case changes or other differences that do not affect lexical equivalence). This Internet-Draft provides four cryptographic hash-based specs, two value-based specs, and two data-based specs.

A cryptographic hash of a certificate uniquely identifies that certificate. Such a hash may also be called a "certificate fingerprint". In all certspecs in this specification *or* derived from this specification, the hash is computed over the octets of the DER encoding of the certificate, namely, the Certificate type of Section 4.1 of . The DER encoding includes tag and length octets, so the first octet is always 30h (the tag for SEQUENCE), and the second octet is never 80h (the octet for indefinite length). In certspecs in this specification, the spec-value is the hexadecimal encoding of the hash value octets. For example, a 256-bit SHA-256 hash is represented by exactly 32 hex octets, or 64 hex characters. The following ABNF defines proper spec-values:

Lexical equivalence of two certspecs that have the same spec-type SHALL be determined by converting the hexadecimal spec-values to octets and comparing exact equivalence of the octets. A strict implementation would reject values that contain non-hex digits, such as spaces, tabs, or hyphens. However, a lenient implementation MAY ignore non-hex characters. In any event, lexical equivalence is determined by converting the hex to octets, and then comparing the octets. If there are too few or too many hex characters, a conforming implementation MUST reject the certspec. Conforming implementations to this Internet-Draft MUST recognize these hash-based certspecs, unless security considerations dictate otherwise. Acceptable reasons for refusing to process a certspec include a) the local policy prohibits use of the hash, or b) the hash has known cryptographic weaknesses, such as a preimage attacks, which weaken the cryptographic uniqueness guarantees of the hash.

The spec-type is "SHA-1". The hash is computed using SHA-1 .

The spec-type is "SHA-256". The hash is computed using SHA-256 .

The spec-type is "SHA-384". The hash is computed using SHA-384 .

The spec-type is "SHA-512". The hash is computed using SHA-512 .

Hashes could be grouped into the spec-type "fp", such as: urn:cert:fp:HASHNAME:HASHVALUE. In such a case, a registry, such as one maintained by IANA, could be used to establish valid HASHNAMEs. In the formulation above, three characters ("fp:") are omitted, and the ability to use "arbitrary" hashes is curtailed. A new hash can be used, but must be procured through the IETF consensus process, which is a higher barrier for establishing new hashes than a registry entry, but offer less oversight. It is believed that omitting "fp:" fosters interoperability because it is better to identify certificates by a small number of widely-recognized, standard algorithms, especially if human consumption or production are foreseen.

A certificate may be identified reflexively, by its constitutent octets. For small-to-medium certificates, identifying the certificate by embedding it in the certspec will be computationally efficient and resistant to denial-of-service attacks (by being always available). The octets of a certificate are the octets of the DER encoding of the certificate, namely, the Certificate type of Section 4.1 of RFC 5280. Lexical equivalence of two certspecs that are value-based SHALL be determined by converting the spec-value to certificate octets, and comparing the octets for strict equivalence. Accordingly, it is possible for a base64 and a hex certspec to be lexically equivalent to each other. A conforming implementation MUST implement base64 and hex specs.

The spec-type is "base64". The spec-value is the base64 encoding (Section 4 of ) of the certificate octets. Like the data: URL , the characters '+' and '/' refer to values 62 and 63, respectively. Additionally, if the length of certificate octets is not a multiple of 3, it is expected that one or two trailing equal signs '=' will be present. '+', '/', and '=' have no reserved meaning in this spec-type. While the URN syntax rules state that '/' should not be used in unencoded form, in this specification, '/' MAY be present in unencoded form in the base64 spec-type. In any case, a conforming implementation MUST be able to process "%"-encoded characters. While a strict implementation would reject non-base64 characters, a lenient implementation MAY ignore non-base64 characters, such as CR, LF, whitespace, or the absence of trailing '='. As a result, two certspecs that have the same base64-encoded data but different stray non-base64 characters MAY be judged lexically equivalent. Similarly, requires that non-reserved characters (in this case, alphanumerics) must not be "%"-encoded, but a lenient implementation MAY decode these "%"-encoded characters anyway. This specification neither recommends nor discourages such leniency, but implementors should weigh the benefits and risks as discussed further in the section.

The spec-type is "hex". The spec-value is the hexadecimal encoding (Section 8 of ) of the certificate octets. Whether an implementation should process "%"-encoded characters or non-hex characters is subject to the same considerations as the equivalent characters in the base64 spec.

A certificate may be identified by data contained within it. The following specs reflect the traditional reliance of PKIX and CMS on a certficiate's issuer name and serial number, or a certificate's subject key identifier. These specs provide textual representations for these identifiers.

The spec-type is "issuersn". The spec-value is given by the following ABNF:

<dn> is defined in , which is based on <distinguishedName> from with the addition of "%"-encoding. <SEMI> is defined in . RFC 4514 no longer separates relative distinguished names (RDNs) by semicolons, as required by its predecessor, RFC 2253. Accordingly, ';' is used to separate the issuer's DN from the subject's serial number. If ';' is present in the dn, it MUST be preceded by a backslash '\', which MUST be "%"-encoded. Care should be taken in escaping and "%"-encoding the relevant characters. In particular, "?" is permitted in a distinguishedName, but is RESERVED by this specification and . Any question marks in distinguished names MUST be "%"-encoded when placed in the spec-value. <serialNumber> is the hexadecimal encoding of the certificate's serial number, with the exact same (DER encoded) contents octets of a CertificateSerialNumber ::= INTEGER as specified in Section 4.1 of . If the serial number hex octets are malformed, the certspec is invalid. A conforming implementation SHOULD implement this issuersn spec. If the implementation implements it, the implementation MUST process serial numbers up to the same length as required by Section 4.1.2.2 of (20 octets), and MUST process distinguished name strings as required by , including the table of minimum AttributeType name strings that MUST be recognized. Lexical equivalence of two issuersn certspecs SHALL be determined by comparing the integer values of the serialNumbers for exact equivalence, and comparing the distinguished names for a match. Distinguished names match if they satisfy the name matching requirements of . An implementation MAY use attribute matching rules that are more restrictive or comprehensive than , provided that the applied rules do not contradict the LDAP definitions of the attributes.

The spec-type is "ski". The spec-value is given by the following ABNF:

<keyIdentifier> is the hexadecimal encoding of the certificate's subject key identifier, which is recorded in the certificate's Subject Key Identifier extension (Section 4.2.1.2 of ). A certificate that lacks a subject key identifier cannot be identified using this spec. Lexical equivalence of two ski certspecs SHALL be determined by converting the hexadecimal spec-values to octets and comparing the exact equivalence of the octets. A conforming implementation MAY implement this ski spec.

certspec is useful wherever a system may need to refer to a certificate by value or by reference. Some implementations may wish to refer to a certificate without enabling all of the expressive power (and security considerations) of URIs. Accordingly, this section provides a uniform method for using a certspec outside of a URN. Examples:

To use certspec outside of a URI (URN) context, the prefix "urn:cert:" MAY be omitted. All other lexical rules remain in effect, including "%"-encoding. Care should be taken to process '?' in particular, since '?' separates the certspec from appended attributes. A conforming implementation of raw certspecs MUST permit the prefix "urn:cert:" in addition to the raw certspec, which starts with the spec-type. This specification guarantees that the the cert-type "urn" is RESERVED and will never be used. However, implementors must take note that a raw certspec is not a valid URI, because cert-types are not registered URI schemes and do not have the same semantics as a URI.

This document requests the assignment of formal URN namespace ID "cert". This document requests the creation of a registry to record specs. New specs shall be ratified by the IETF consensus process.

When producing a hash-based certspec, the producer has a wide choice of hashes. Nevertheless, this Internet-Draft RECOMMENDS that SHA-1 or SHA-256 be used to foster the greatest interoperability and human recognition, provided that the Security Considerations are heeded.

Digital certificates are important building blocks for authentication, integrity, authorization, and (occasionally) confidentiality services. Accordingly, identifying digital certificates incorrectly can have significant security ramifications. When using specs that are cryptographic hashes (fingerprints) for lookups and comparisons, the cryptographic hash algorithm MUST be implemented properly and SHOULD have no known attack vectors. The registration of a particular algorithm spec in this namespace does NOT mean that it is acceptable or safe for every usage, even though this Internet-Draft requires that a conforming implementation MUST implement certain specs. When using by-value specs, the implementation MUST be prepared to process URNs of arbitrary length. As of this writing, useful certificates rarely exceed 10KB, and most implementations are concerned with keeping certificate sizes down rather than up (for example, to fit in a single TCP packet). However, a pathological or malicious certificate could easily exceed these metrics. If an URN resolver cannot process a URN's full length, it MUST reject the certspec. When using specs that depend on certificate data, the implementation MUST be prepared to deal with multiple found certificates that contain the same certificate data, but are not the same certificate. In such a case, the implementation MUST segregate these certificates so that it only resolves the URN to certificates that it considers valid or trustworthy (as discussed further below). If, despite this segregation, multiple valid or trustworthy certificates match the certspec, the certspec MUST be rejected, because a certspec is meant to identify exactly one certificate (not a family of certificates). Apart from the mechanics of certspecs (cert URNs), certificates should not be used unless they have passed the Certification Path Validation Algorithm (Section 6 of [RFC5280]), or another algorithm that provides some guarantee of validity. For example, if a certificate database contains a set of certificates that it considers inherently trustworthy, then the inclusion of a certificate in that set makes it trustworthy, regardless of the results of the Certification Path Validation Algorithm. Such a database is frequently used for "Root CA" lists.