Network Working Group S. Leonard
Internet-Draft Penango, Inc.
Intended status: Standards Track July 8, 2012
Expires: January 9, 2013
A Uniform Resource Name (URN) Namespace for Certificates
draft-seantek-certspec-00
Abstract
Digital certificates are used in many systems and protocols to
identify and authenticate parties. This document describes a Uniform
Resource Name (URN) namespace that identifies certificates. These
URNs can be used when certificates need to be identified by value or
reference. Applications can also use this specification in non-URI
contexts.
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 http://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 January 9, 2013.
Copyright Notice
Copyright (c) 2012 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
Leonard Expires January 9, 2013 [Page 1]
Internet-Draft certspec July 2012
described in the Simplified BSD License.
1. Introduction
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:
urn:cert:SHA-1:b1f090a8e2d70353107454f9618347b18b321bf1
urn:cert:issuersn:CN=Atlantis;2A
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.
2. Motivation and Purpose
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
Leonard Expires January 9, 2013 [Page 2]
Internet-Draft certspec July 2012
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.
3. certspec Syntax
The Namespace Specific String (NSS) portion of a certspec has the
following ABNF specification:
NSS = spec-type ":" spec-value ( '?' certattrs)
spec-type = scheme
certattrs = <URN chars>
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"
3.1. spec-type and spec-value
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 [RFC3986]. 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.
3.2. certattrs
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
[RFC2141] (effectively, any URI character from [RFC3986] except "["
and "]"). This Internet-Draft does not further define certattrs.
4. Certificate Specifications
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-
Leonard Expires January 9, 2013 [Page 3]
Internet-Draft certspec July 2012
Draft provides four cryptographic hash-based specs, two value-based
specs, and two data-based specs.
4.1. Cryptographic Hash-Based Specifications
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 [RFC5280]. 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:
spec-value-sha-1 = 20hexOctet
spec-value-sha-256 = 32hexOctet
spec-value-SHA-384 = 48hexOctet
spec-value-SHA-512 = 64hexOctet
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.
4.1.1. SHA-1
The spec-type is "SHA-1". The hash is computed using SHA-1 [SHS].
Leonard Expires January 9, 2013 [Page 4]
Internet-Draft certspec July 2012
4.1.2. SHA-256
The spec-type is "SHA-256". The hash is computed using SHA-256
[SHS].
4.1.3. SHA-384
The spec-type is "SHA-384". The hash is computed using SHA-384
[SHS].
4.1.4. SHA-512
The spec-type is "SHA-512". The hash is computed using SHA-512
[SHS].
4.1.5. [Discussion]
[[DP1: 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. --S.L.]]
4.2. Value-Based Specifications
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.
Leonard Expires January 9, 2013 [Page 5]
Internet-Draft certspec July 2012
4.2.1. base64
The spec-type is "base64". The spec-value is the base64 encoding
(Section 4 of [RFC4648]) of the certificate octets. Like the data:
URL [RFC2397], 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 [RFC2141] 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,
[RFC2141] 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
Security Considerations section.
4.2.2. hex
The spec-type is "hex". The spec-value is the hexadecimal encoding
(Section 8 of [RFC4648]) 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.
4.3. Data-Based Specifications
A certificate may be identified by data contained within it. The
following specs reflect the traditional reliance of PKIX [RFC5280]
and CMS [RFC5652] on a certficiate's issuer name and serial number,
or a certificate's subject key identifier. These specs provide
textual representations for these identifiers.
4.3.1. issuersn: Issuer Name and Serial Number
The spec-type is "issuersn". The spec-value is given by the
following ABNF:
Leonard Expires January 9, 2013 [Page 6]
Internet-Draft certspec July 2012
spec-value-issuersn = dn SEMI serialNumber
serialNumber = 1*hexOctet
<dn> is defined in [RFC4516], which is based on <distinguishedName>
from [RFC4514] with the addition of "%"-encoding. <SEMI> is defined
in [RFC4512]. 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 [RFC2141]. 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
[RFC5280]. 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 [RFC5280] (20 octets), and MUST process distinguished name strings
as required by [RFC4514], 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 [RFC5280]. An implementation MAY use attribute
matching rules that are more restrictive or comprehensive than
[RFC5280], provided that the applied rules do not contradict the LDAP
definitions of the attributes.
4.3.2. ski: Subject Key Identifier
The spec-type is "ski". The spec-value is given by the following
ABNF:
spec-value-ski = keyIdentifier
keyIdentifier = 1*hexOctet
<keyIdentifier> is the hexadecimal encoding of the certificate's
Leonard Expires January 9, 2013 [Page 7]
Internet-Draft certspec July 2012
subject key identifier, which is recorded in the certificate's
Subject Key Identifier extension (Section 4.2.1.2 of [RFC5280]). 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.
5. Registration Template
Namespace ID:
cert
Registration Information:
Version: 1
Date: 2012-07-08
Declared registrant of the namespace:
IETF
Declaration of syntactic structures:
The structure of the Namespace Specific String is provided
above.
Relevant ancillary documentation:
Certificates are defined by [RFC5280] and [X.509].
Identifier uniqueness considerations:
The spec type is assigned by IANA through the IETF consensus
process, so this process guarantees uniqueness of these
identifiers. The uniqueness of the spec value depends on the
spec type. For specs that identify cryptographic hashes, the
cryptographic hash algorithm itself guarantees uniquess.
For specs that identify certificates by value, the inclusion
of the certificate in the URN itself guarantees uniqueness.
For specs that identify certificates by certificate data,
the resolver's database of certificates and implementation
of certification path validation Section 6 of [RFC5280] ensure
uniqueness.
Identifier persistence considerations:
A certificate is a permanent digital artifact, irrespective of
its origin. As the assignment process records mathematical or
existential facts about the certificate, such as one of its
Leonard Expires January 9, 2013 [Page 8]
Internet-Draft certspec July 2012
cryptographic hashes, the binding between the URN and
the certificate resource is permanent. Changing even one bit
of the certificate will alter its URN, will make the
certificate unusable, or both.
Process of identifiers assignment:
Generating a certspec (cert URN) does not require that
a registration authority be contacted.
Process for identifier resolution:
This Internet Draft does not specify a resolution service
for certspecs. However, resolving certificate references
to actual certificates is a common practice with a wide number
of offline and online implementations.
Rules for Lexical Equivalence:
Certspecs (cert URNs) are lexically equivalent if they both
have the same spec type (compared case-insensitively)
and the same space value, and therefore impliedly point
to the same certificate.
Comparison of spec values depends on the rules of the spec.
Although extensions may be appended to a certspec,
these extensions are guaranteed not to affect lexical
equivalence.
Certspecs are semantically equivalent if they both resolve
to the same certificate.
Conformance with URN Syntax:
The character '?' is reserved for future extensions to this
specification. The URN of this namespace conforms to URN Syntax
[RFC2141] and Uniform Resource Identifier (URI): Generic Syntax
[RFC3986].
Validation mechanism:
Each spec defines the validation mechanism for its respective
value. It may be appreciated that validation of the URN is a
completely different process from the Certification Path
Validation Algorithm (Section 6 of [RFC5280]), which determines
whether the *certificate* is valid.
Scope:
Global.
6. Use of certspec outside URN
certspec is useful wherever a system may need to refer to a
Leonard Expires January 9, 2013 [Page 9]
Internet-Draft certspec July 2012
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:
SHA-1:b1f090a8e2d70353107454f9618347b18b321bf1
issuersn:CN=Atlantis;2A
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.
7. IANA Considerations
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.
8. Best Practices
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.
9. Security Considerations
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
Leonard Expires January 9, 2013 [Page 10]
Internet-Draft certspec July 2012
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.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
Leonard Expires January 9, 2013 [Page 11]
Internet-Draft certspec July 2012
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512,
June 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator", RFC 4516,
June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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, May 2008.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, March 2012, <http://
csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.
10.2. Informative References
[P11] RSA Laboratories, "PKCS #11 v2.20: Cryptographic Token
Interface Standard", PKCS #11, June 2004.
[P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information
Exchange Syntax Standard", PKCS #12, June 1999.
[P9] RSA Laboratories, "PKCS #9 v2.0: Selected Object Classes
and Attribute Types", PKCS #9, February 2000.
[RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
Leonard Expires January 9, 2013 [Page 12]
Internet-Draft certspec July 2012
[X.509] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks", ITU-
T Recommendation X.509, ISO Standard 9594-8,
November 2008.
Author's Address
Sean Leonard
Penango, Inc.
1215 K Street
17th Floor
Sacramento, CA 95814
USA
Email: dev+ietf@seantek.com
URI: http://www.penango.com/
Leonard Expires January 9, 2013 [Page 13]