idnits 2.17.1 draft-seantek-certspec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2014) is 3561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'RFC2141' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC3406' is defined on line 750, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-07 == Outdated reference: A later version (-10) exists of draft-josefsson-pkix-textual-02 -- Obsolete informational reference (is this intentional?): RFC 2253 (Obsoleted by RFC 4510, RFC 4514) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended status: Informational June 29, 2014 5 Expires: December 31, 2014 7 A Uniform Resource Name (URN) Namespace for Certificates 8 draft-seantek-certspec-03 10 Abstract 12 Digital certificates are used in many systems and protocols to 13 identify and authenticate parties. This document describes a Uniform 14 Resource Name (URN) namespace that identifies certificates. These 15 URNs can be used when certificates need to be identified by value or 16 reference. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 31, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Digital certificates are used in many systems and protocols to 53 identify and authenticate parties. Security considerations 54 frequently require that the certificate must be identified with 55 certainty, because selecting the wrong certificate will lead to 56 validation errors (resulting in denial of service), or in improper 57 credential selection (resulting in unwanted disclosure or 58 substitution attacks). The goal of this namespace is to provide a 59 uniform syntax for identifying certificates with precision in Uniform 60 Resource Identifiers (URIs), specifically Uniform Resource Names 61 (URNs). 63 Using this syntax, any protocol or system that refers to a 64 certificate in a textual format can unambiguously identify that 65 certificate by value or reference. Implementers that parse these 66 URNs can resolve them into actual certificates. Examples include: 68 urn:cert:SHA-1:3ea3f070773971539b9dbf1b98c54be3a4f0f3c8 69 urn:cert:issuersn:cn=AcmeIssuingCompany,st=California,c=US;0134F1 70 urn:cert:base64:MIIBHDCBxaADAgECAgIAmTAJBgcqhkjOPQQBMBAxDjAMBgNVBAMT 71 BVNtYWxsMB4XDTEzMTEwNTE5MjUzM1oXDTE2MDgwMjE5MjUzM1ow 72 EDEOMAwGA1UEAxMFU21hbGwwWTATBgcqhkjOPQIBBggqhkjOPQMB 73 BwNCAAS2kwRQ1thNMBMUq5d_SFdFr1uDidntNjXQrc3D_QpzYWkE 74 WDsxeY8xcbl2m0TBO4TJ_2CevdoOX0OMIOaqJ_TNoxAwDjAMBgNV 75 HRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIgPyF8ok6h2NxMQ4uJ 76 OcGcXYcvZ1ua0kB-rIv0omHcfNECICKwpTp3LDIwhlHTQ_DulQDD 77 eYn-lnYQVc2Gm1WKAuxp 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119. 85 2. Motivation and Purpose 87 Although certificates have diverse applications, there has been no 88 uniform way to refer to a certificate in text. De-facto standards 89 such as PEM [RFC1421] and PKIX text encoding [PT] are used to include 90 whole certificates in textual formats, but this practice is 91 impractical for a variety of use cases. Certificates that identify 92 long public keys (e.g., 2048-bit RSA keys) and that contain required 93 and recommended PKIX extensions can easily exceed many kilobytes in 94 length. 96 The purpose of this document is to provide a uniform textual format 97 for identifying individual certificates. Certificate specifications, 98 or "certspecs", are not designed or intended to provide a search tool 99 or query language to match multiple certificates; the goal is to 100 replace data elements that would otherwise have to include whole 101 certificates in order to identify them. When a URN resolver resolves 102 a "certspec", the resolver's output is expected to be a single 103 certificate or nothing. 105 2.1. Static Identification 107 Identifying a specific certificate by reference or value allows 108 diverse applications to have a common syntax. For example, 109 applications can store certspecs as local or shared preferences, so 110 that users can edit them without resorting to application-specific 111 storage formats or relying on the availability of particular 112 protocols represented by URLs (such as http:, ldap:, file:, or ni: 113 schemes). When conveyed in protocol, a certspec can identify a 114 specific certificate to a client or server using text-based formats 115 such as YAML, XML, JSON, and others. The format described in this 116 document is intended to be readily reproducible by users using common 117 certificate processing tools, so that users can easily create, 118 recognize, compare, and reproduce them at a glance. For example, the 119 hash-based identifications use hexadecimal encoding so that a user 120 can easily compose or compare an URN with a simple copy-and-paste 121 operation. Accordingly, some tradeoffs have been made in favor of 122 human usability. 124 2.2. Resolution to Context-Appropriate Schemes 126 When the certificate represented by a certspec needs to be resolved, 127 an application can resort to any number of schemes. For example, 128 when the certificate is identified by hash, the application can 129 resolve the certspec to a Named Information (ni:) URI [RFC6920] for 130 further processing. When the certificate is identified by issuer and 131 serial number, the application can resolve the certspec to an LDAP 132 service (for example, 133 ldap:///cn=ExampleCA,o=ExampleCo,st=California,c=US ). 135 3. One-Per-Kind 137 A certspec is intended to identify a single certificate 138 unambiguously. A certificate has no more than one corresponding 139 certspec per certspec type; however, a certificate is expected to 140 have an array of certspecs that identify the certificate. The choice 141 of which certspec to use in a given situation is context-specific. 143 4. certspec Syntax 145 A certspec is a URN that complies with the modern URN syntax 146 [URNBIS], with a few accommodations for usability. Following 147 [URNBIS], NID is "cert", and the Namespace Specific String (NSS) has 148 the ABNF below. The query and fragment productions are relevant to 149 certspecs; these are discussed in Section 7. Rules from [RFC5234] 150 are also used. 152 NSS = certspec-hash / certspec-content / certspec-el / 153 other-certspec-type ":" other-certspec-value 155 hexOctet = 2HEXDIG 157 certspec-hash = "SHA-1" ":" 20hexOctet / 158 "SHA-256" ":" 32hexOctet / 159 "SHA-384" ":" 48hexOctet / 160 "SHA-512" ":" 64hexOctet 162 certspec-content = "hex" ":" 1*hexOctet / 163 "base64" ":" base64url / base64relaxed 165 base64url = 1*base64urlcharP 166 base64relaxed = 1*(base64urlcharP / "+" / "/") ; not pchar 168 base64urlchar = ALPHA / DIGIT / "-" / "_" / pct-encoded ; from RFC 3986 170 certspec-el = "issuersn" ":" distinguishedNameUC ";" serialNumber / 171 "ski" ":" 1*(hexOctet) 173 distinguishedNameUC = 1*pchar-no-semi / ; close to RFC 3986 174 distinguishedNameUCrelaxed 175 serialNumber = 1*hexOctet 177 ; semicolon omitted, since it delimits serialNumber 178 pchar-no-semi = unreserved / pct-encoded / "!" / "$" / "&" / "'" / 179 "(" / ")" / "*" / "+" / "," / "=" / ":" / "@" 181 distinguishedNameUCrelaxed = 1*(pchar / WSP / UTFMB) ; not pchar 182 ; from RFC 4512 184 certspec-type = scheme ; from RFC 3986 185 certspec-value = 1*pchar ; from RFC 3986 187 other-certspec-type = certspec-type 188 other-certspec-value = certspec-value 190 Figure 1: certspec ABNF 192 4.1. certspec-type and certspec-value 194 A certspec NSS is comprised of two parts: certspec-type and certspec- 195 value. The certspec-type identifies the certificate specification 196 type. The acceptable characters for spec-type are the same as those 197 in an URI scheme name (Section 3.1 in [RFC3986]); types are compared 198 case-insensitively. The certspec-value identifies the certificate 199 specification value. The acceptable characters for spec-value depend 200 on the spec-type, but are never more than pchar except for relaxed 201 human usability reasons in a few cases discussed below. To simplify 202 processing in several other cases, characters are significantly 203 restricted to the point that percent-encoding is prohibited. In such 204 cases, a generator MUST NOT generate percent-encoded values, and a 205 parser MUST treat the production as an error. 207 Several certspecs use hexadecimal encodings of octets. Generally: if 208 the hex octets are malformed (whether in the source material, such as 209 the corresponding certificate element, or in the hex text), the 210 certspec is invalid. 212 5. Standard Certificate Specifications 214 Standard certificate specifications are intended for interchange as 215 durable, persistent, unique, and intuitive (to users and developers) 216 identifiers for individual certificates--the exact criteria for URNs. 217 This section provides four cryptographic hash-based certspecs, two 218 content-based certspecs, and two element-based certspecs. 220 5.1. Cryptographic Hash-Based Specifications 222 A cryptographic hash or "fingerprint" of a certificate uniquely 223 identifies that certificate. For hash-based certspecs, the hash is 224 computed over the octets of the DER encoding of the certificate, 225 namely, the Certificate type in Section 4.1 of [RFC5280]. The 226 certspec-value is the hexadecimal encoding of the hash value octets. 227 For example, a 256-bit SHA-256 hash is represented by exactly 32 hex 228 octets, or 64 hex characters. 230 Lexical equivalence of two hash-based certspecs that have the same 231 certspec-type SHALL be determined by a case-insensitive comparison of 232 certspec-values, or by converting the hexadecimal certspec-values to 233 octets and comparing exact equivalence of the octets. A conforming 234 implementation MUST reject values that contain non-hex digits, such 235 as spaces, tabs, hyphens, percent-encoded characters, or anything 236 else. 238 Conforming implementations to this Internet-Draft MUST process these 239 hash-based certspecs, unless security considerations dictate 240 otherwise. Acceptable reasons for refusing to process a certspec 241 include a) the local policy prohibits use of the hash, or b) the hash 242 has known cryptographic weaknesses, such as a preimage attacks, which 243 weaken the cryptographic uniqueness guarantees of the hash. 245 5.1.1. SHA-1 247 The certspec-type is "SHA-1". The hash is computed using SHA-1 248 [SHS]. 250 5.1.2. SHA-256 252 The certspec-type is "SHA-256". The hash is computed using SHA-256 253 [SHS]. 255 5.1.3. SHA-384 257 The certspec-type is "SHA-384". The hash is computed using SHA-384 258 [SHS]. 260 5.1.4. SHA-512 262 The certspec-type is "SHA-512". The hash is computed using SHA-512 263 [SHS]. 265 5.2. Content-Based Specifications 267 A certificate may be identified reflexively by its constituent 268 octets. For small-to-medium certificates, identifying the 269 certificate by embedding it in the certspec will be computationally 270 efficient and resistant to denial-of-service attacks (by always being 271 available). A conforming implementation MUST implement base64 and 272 hex specs. 274 The octets of a certificate are the octets of the DER encoding of the 275 certificate, namely, the Certificate type in Section 4.1 of 276 [RFC5280]. The DER encoding includes tag and length octets, so it 277 always starts with 30h (the tag for SEQUENCE). 279 Lexical equivalence of two certspecs that are value-based SHALL be 280 determined by decoding the certspec-value to certificate octets, and 281 comparing the octets for strict equivalence. Accordingly, it is 282 possible that base64 and hex certspecs are lexically equivalent. 284 Because users may end up copying and pasting base64 or hex-encoded 285 certificates into certspecs, and because these certspecs will 286 routinely exceed 72 characters, a production might contain embedded 287 whitespace. If there are contexts where line breaks or other 288 whitespace must be allowed for practical reasons, the implementation 289 should consider the URN in context as "a URN, possibly with embedded 290 whitespace (which is ignored)". 292 5.2.1. base64 294 The certspec-type is "base64". The certspec-value is the base64url 295 encoding of the certificate octets (Section 5 of [RFC4648]), but MAY 296 be relaxed as follows. Unlike the data: URL [RFC2397], URN NSS 297 productions are not supposed to have the "/" character, which is 298 integral to standard base64. On the other hand, it is anticipated 299 that users will want to copy-and-paste base64 encoded certificates-- 300 such as those produced by PKIX text encodings--directly into base64 301 certspecs. Generators of base64 certspecs SHOULD emit base64url- 302 encoded data, where the characters '-' and '_' refer to values 62 and 303 63, respectively, and where the trailing equal signs '=' are absent. 304 Alternatively, generators MAY emit base64 data with precent-encoding 305 for the non-pchar conformant characters (specifically "/"). In any 306 event, generators MUST NOT generate non-pchar conformant characters 307 (specifically "/"). Parsers of base64 certspecs that are not under 308 strict URN conformance constraints MUST also accept '+' and '/' as 309 values 62 and 63, respectively, and MUST accept trailing '=' 310 characters in conformance with standard base64. None of '+', '/', or 311 '=' have reserved meanings in this certspec-type. This relaxed 312 parsing rule is reflected in the base64relaxed production of 313 Figure 1. 315 Similarly, [URNBIS] states that non-reserved characters (in this 316 case, alphanumerics) must not be "%"-encoded, but a lenient 317 implementation MAY decode these "%"-encoded characters anyway. This 318 document neither recommends nor discourages such leniency, but 319 implementors should weigh the benefits and risks as discussed further 320 in the Security Considerations (Section 11). Overall, percent- 321 encoding in base64 certspecs is permissible because unlike most of 322 the other certspecs, the complete base64 encoding is not expected to 323 be human-readable or identifiable at a glance. 325 5.2.2. hex 327 The certspec-type is "hex". The certspec-value is the hexadecimal 328 encoding of the certificate octets. Percent-encoding is not allowed; 329 implementations MUST NOT process percent-encoded values. The reasons 330 are because percent-encoding would reduce the human readability of 331 the certspec, and (marginally) increase the complexity of certspec 332 parsers. 334 5.3. Element-Based Specifications 336 A certificate may be identified by certain data elements contained 337 within it. The following certspecs reflect the traditional reliance 338 of PKIX [RFC5280] and CMS [RFC5652] on a certificate's issuer 339 distinguished name and serial number, or a certificate's subject key 340 identifier. 342 If some of an element-based certspec is based on the DER encoded part 343 of a certificate, and if the encodings are incorrect, the URN is 344 invalid. 346 5.3.1. issuersn: Issuer Name and Serial Number 348 The certspec-type is "issuersn". 350 The distinguishedNameUC production encodes the certificate's issuer 351 distinguished name (DN) field in LDAP string format, whose characters 352 are subsequently percent-encoded to conform to URN NSS syntax. The 353 on which distinguishedNameUC is based is defined 354 in [RFC4514], and is defined in [RFC4512]. [RFC4514] no 355 longer separates relative distinguished names (RDNs) by semicolons, 356 as required by its predecessor, [RFC2253]. Accordingly, ";" is used 357 to separate the issuer's DN from the subject's serial number. 359 Care should be taken in escaping and percent-encoding the relevant 360 characters. In particular: 362 "?" is permitted in a distinguishedName, but MUST NOT appear in a 363 URN unless it delimits the query component (see [URNBIS]). Any 364 "?" characters in distinguished names MUST be percent-encoded when 365 placed in the certspec-value. 367 "#" is used as a token at the beginning of the hexstring 368 production for attributeValue data, but MUST NOT appear in a URN 369 unless it delimits the fragment component (see [URNBIS]). Any "#" 370 characters in distinguished names MUST be percent-encoded when 371 placed in the certspec-value. 373 "\" is the escape (ESC) character in LDAP strings (see [RFC4514]), 374 but is not in the URI repetoire. Any "\" characters MUST be 375 percent-encoded when placed in the certspec-value. 377 For reference, only the following characters are permitted in 378 distinguished names in the issuer production of a URN: 380 ALPHA DIGIT - . _ ~ ! $ & ' ( ) * + , = : @ 381 pct-encoded (% followed by two HEXDIG) 383 If human input is anticipated, an application MAY relax its 384 processing as suggested in Appendix A. 386 The serialNumber production is the hexadecimal encoding the DER- 387 encoded contents octets of the CertificateSerialNumber (INTEGER, 388 i.e., not the type or length octets) as specified in Section 4.1 of 389 [RFC5280]. 391 A conforming implementation SHOULD implement this issuersn certspec. 392 If the implementation implements it, the implementation MUST process 393 serial numbers up to the same length as required by Section 4.1.2.2 394 of [RFC5280] (20 octets), and MUST process distinguished name strings 395 as required by [RFC4514], including the table of minimum 396 AttributeType name strings that MUST be recognized. Additionally, 397 implementations MUST process attribute descriptors specified in 398 [RFC5280] (MUST or SHOULD), and [RFC5750] (specifically: E, email, 399 emailAddress). For reference, a complete list of required attribute 400 descriptors is provided in Appendix B. Implementations are 401 encouraged to recognize additional attribute descriptors where 402 possible. A sample list of such attribute descriptors is provided in 403 Appendix C. 405 Lexical equivalence of two issuersn certspecs SHALL be determined by 406 comparing the serialNumbers for exact equivalence, and comparing the 407 issuer distinguished names for a match. 409 The lexical equivalence of serialNumbers SHALL be determined by a 410 case-insensitive comparison of them, or by converting the hexadecimal 411 text to octets and comparing exact equivalence of the octets. A 412 conforming implementation MUST reject values that contain non-hex 413 digits, such as spaces, tabs, hyphens, percent-encoded characters, or 414 anything else. 416 The lexical equivalence of issuer distinguished names SHALL be 417 determined by (percent-)decoding the URNs, followed by parsing the 418 LDAP strings. The resulting distinguished names match if they 419 satisfy the name matching requirements of [RFC5280] and [RFC4517]. 421 5.3.2. ski: Subject Key Identifier 423 The certspec-type is "ski". The certspec-value is the hexadecimal 424 encoding of the certificate's subject key identifier, which is 425 recorded in the certificate's Subject Key Identifier extension 426 (Section 4.2.1.2 of [RFC5280]). The octets are the DER-encoded 427 contents octets of the SubjectKeyIdentifier (OCTET STRING) extension 428 value. A certificate that lacks a subject key identifier cannot and 429 MUST NOT be identified using this spec. 431 Lexical equivalence of two ski certspecs SHALL be determined by a 432 case-insensitive comparison of certspec-values, or by converting the 433 hexadecimal certspec-values to octets and comparing exact equivalence 434 of the octets. A conforming implementation MUST reject values that 435 contain non-hex digits, such as spaces, tabs, hyphens, percent- 436 encoded characters, or anything else. 438 A conforming implementation MAY implement this ski spec. 440 6. Other Certificate Specifications 442 The additional certificate specifications in this section are 443 provided for applications to use as local identifiers that are 444 useful, intuitive, or supportive of legacy systems or overriding 445 design goals. These certspecs SHOULD NOT be used for interchange. 447 6.1. data (Reserved) 449 The certspec-type is "data". This document reserves this spec-type 450 for future use. 452 An implementation may embed the contents of a data URL (data URI) 453 into the certspec-value. Specifically: 455 ; from RFC 2397 456 certspec-value = [ mediatype ] [ ";base64" ] "," data 458 See [RFC2397]. In such a case, the mediatype SHOULD be "application/ 459 pkix-cert" since the data URL components identify a certificate; 460 however, an implementation MAY be able to support other media types 461 so long as a single certificate is extractable from the data 462 production. 464 Data URLs containing certificates generally will not conform to URN 465 syntax "as-is". The considerations of stuffing base64-encoded 466 content into URNs discussed in Section 5.2.1 apply to this certspec 467 as well, bearing in mind that data URLs only contain traditional 468 base64 (not base64url)-encoded data, or binary percent-encoded data. 470 Because this certspec is content-based, an implementation can 471 determine lexical equivalence with other content-based certspecs. 473 6.2. dbkey (Reserved) 475 The spec-type is "dbkey". This document reserves this spec-type for 476 future use. 478 6.3. subject (Reserved) 480 The certspec-type is "subject". The certspec-value is the RFC 4514 481 LDAP string encoding of the certificate's subject distinguished name. 482 Characters MAY be percent-encoded; implementations MUST process the 483 percent-encoded characters in the certspec-value before further LDAP 484 string processing. All the considerations of encoding the issuer 485 field in Section 5.3.1 apply to this type. 487 7. Query and Fragment Productions 489 [URNBIS] clarifies that the query and fragment productions of 490 [RFC3986] apply to URNs. This document provides semantics for these 491 productions, as applied to certificates. 493 ; query for certspec URN 494 certattrs = query ; from RFC 3986 495 ; *( pchar / "/" / "?" ) 497 ; fragment for certspec URN 498 certpart = "v" / "sn" / "sig" / "issuer" / "notBefore " / 499 "notAfter" / "subject" / "spki" / 500 "ext" *(":" extoid *(":" extpart)) / 501 "sigval" / other-certpart 503 extoid = numericoid ; from RFC 4512 504 extpart = fragment ; from RFC 3986 505 other-certpart = fragment ; from RFC 3986 507 7.1. Equivalence Unaffected 509 As a certspec identifies a single certificate, two certspecs are 510 identical lexically or semantically if the NSS parts identify the 511 same certificate. The query and fragment productions do not affect 512 this equivalence. 514 7.2. Query (Attributes) 516 A certspec URN can have attributes (i.e., metadata) that are 517 associated with--but not instrinsic to--the certificate or its 518 identifiers. The syntax is intended primarily to convey certificate 519 metadata such as attributes found in PKCS #9, PKCS #11, PKCS #12, and 520 particular implementations of cryptographic libraries. This document 521 does not further define certattrs; the characters of certattrs can be 522 any valid query character from [RFC3986]. 524 7.3. Fragment 526 A certspec can include a fragment that identifies a part of interest 527 within the identified certificate. For example, a user agent may 528 wish to draw attention to the notAfter time for an expired 529 certificate. This document defines the following fragments 530 ("certparts"): 532 +------------+---------------------------------------------------+ 533 | Identifier | Certificate Part (ASN.1 identifier) | 534 +------------+---------------------------------------------------+ 535 | v | tbsCertificate.version | 536 | sn | tbsCertificate.serialNumber | 537 | sig | tbsCertificate.signature; also signatureAlgorithm | 538 | issuer | tbsCertificate.issuer | 539 | notBefore | tbsCertificate.validity.notBefore | 540 | notAfter | tbsCertificate.validity.notAfter | 541 | subject | tbsCertificate.subject | 542 | spki | tbsCertificate.subjectPublicKeyInfo | 543 | ext | tbsCertificate.extensions | 544 | ext: | tbsCertificate.extensions | 545 | | {Extension matching extoid == extnID}* | 546 | sigval | signatureValue | 547 +------------+---------------------------------------------------+ 549 * The particular extension in the Extensions SEQUENCE is identified 550 by OID only; there are no textual identifiers. 552 Table 1: certparts 554 The certparts defined in the table above are case-insensitive. 555 Should additional certparts be required, a future document may 556 specify additional certparts that match the other-certpart 557 production. 559 8. Registration Template 561 Namespace ID: 562 cert 564 Registration Information: 565 Version: 1 566 Date: 2014-06-29 568 Declared registrant of the namespace: 569 IETF 571 Declaration of syntactic structures: 573 The structure of the Namespace Specific String is provided 574 above. 576 Relevant ancillary documentation: 577 Certificates are defined by [RFC5280] and [X.509]. 579 Identifier uniqueness considerations: 580 The certspec-type is assigned by IANA through the IETF 581 consensus process, so this process guarantees uniqueness of 582 these identifiers. The uniqueness of the certspec-value 583 is guaranteed by the definition of the value for 584 the certspec-type. For cryptographic hash-based certspecs, the 585 cryptographic hash algorithm itself guarantees uniquess. 586 For contents-based certspecs, the inclusion 587 of the certificate in the URN itself guarantees uniqueness. 588 For certspecs that identify certificates by certificate data 589 elements, as long as certificate issuers issue 590 certificates correctly, and the resolver's database of 591 certificates and the resolver's implementation 592 of certification path validation [RFC5280 sec. 6] are 593 consistent, no cert URN will identify two different 594 certificates. 596 Identifier persistence considerations: 597 A certificate is a permanent digital artifact, irrespective of 598 its origin. As the URN records only information that is 599 derivable from the certificate itself, such as one of its 600 cryptographic hashes, the binding between the URN and the 601 certificate is permanent. 602 Once the set of cert URNs identify a particular 603 certificate, that fact will never change. 605 Process of identifiers assignment: 606 Generating a certspec (cert URN) does not require that 607 a registration authority be contacted. 609 Process for identifier resolution: 610 This Internet Draft does not specify a resolution service 611 for certspecs. However, resolving certificate references 612 to actual certificates is a common practice with a wide number 613 of offline and online implementations. See for example 614 [RFC5280] sec. 4.2.2.1. 616 Rules for Lexical Equivalence: 617 Certspecs (cert URNs) are lexically equivalent if they both 618 have the same certspec-type (compared case-insensitively) 619 and the same certspec-value, and therefore impliedly point 620 to the same certificate. 622 Comparison of certspec-values depends on the rules of the 623 certspec. 624 Additionally, the contents-based certspecs, base64 and hex 625 (and--if implemented--the data certspec), can be compared for 626 lexical equivalence between each other by decoding the 627 certspec-value to the underlying DER-encoded certificate 628 octets, and comparing these octets for exact equivalence. 629 Query ("certattrs") and fragment ("certpart") components 630 do not affect certificate identification, and therefore 631 do not affect lexical equivalence. 633 Certspecs are semantically equivalent if they both resolve 634 to the same certificate. 636 Conformance with URN Syntax: 637 The URN of this namespace conforms to URN Syntax 638 [URNBIS] and Uniform Resource Identifier (URI): Generic Syntax 639 [RFC3986]. 641 Validation mechanism: 642 Each certspec defines the validation mechanism for its respective 643 value. It may be appreciated that validation of the URN is a 644 completely different process from the Certification Path 645 Validation Algorithm [RFC5280] sec. 6, which determines whether 646 the *certificate* is valid. 648 Scope: 649 Global. 651 9. Use of certspec outside URN 653 certspec is useful wherever a system may need to include or refer to 654 a certificate. Some implementations may wish to refer to a 655 certificate without enabling all of the expressive power (and 656 security considerations) of URIs. Accordingly, this section provides 657 a uniform method for using a certspec outside of a URN. Examples: 659 urn:cert:SHA-1:3ea3f070773971539b9dbf1b98c54be3a4f0f3c8 660 urn:cert:issuersn:cn=AcmeIssuingCompany,st=California,c=US;0134F1 662 To use certspec outside of a URI (URN) context, simply omit the 663 prefix "urn:cert:". All other lexical rules apply, including 664 percent-encoding, query (certattrs), and fragment (certparts). Care 665 should be taken to process "?" and "#" in particular, since they 666 delimit the attributes and parts. A conforming implementation of raw 667 certspecs MUST permit the prefix "urn:cert:" in addition to the raw 668 certspec. Additionally, this document guarantees that the the 669 certspec-types "urn" and "cert" are RESERVED and will never be used. 671 However, implementors must take note that a raw certspec is not a 672 valid URI, because certspec-types are not registered URI schemes and 673 do not have the same semantics as URIs. 675 10. IANA Considerations 677 This document requests the assignment of formal URN namespace ID 678 "cert". 680 [[TODO: Consider...This document requests the creation of a registry 681 to record specs.]] New certspec types shall be ratified by the IETF 682 consensus process. [[Some commenters have suggested the creation of 683 a registry for certspec types. This is under consideration. One 684 drawback is that it is desirable to limit the certspec types for 685 interoperability and recognizability reasons--probably the only 686 reason to include more types is for using new hashes as old hash 687 algorithms become cryptanalyzed. The current view of the author is 688 that no registry should be created.]] 690 11. Security Considerations 692 Digital certificates are important building blocks for 693 authentication, integrity, authorization, and (occasionally) 694 confidentiality services. Accordingly, identifying digital 695 certificates incorrectly can have significant security ramifications. 697 When using hash-based certspecs, the cryptographic hash algorithm 698 MUST be implemented properly and SHOULD have no known attack vectors. 699 For this reason, algorithms that are considered "broken" as of the 700 date of this Internet-Draft, such as MD5 [RFC6151], are precluded 701 from being valid certspecs. The registration of a particular 702 algorithm spec in this namespace does NOT mean that it is acceptable 703 or safe for every usage, even though this Internet-Draft requires 704 that a conforming implementation MUST implement certain specs. 706 When using content-based certspecs, the implementation MUST be 707 prepared to process URNs of arbitrary length. As of this writing, 708 useful certificates rarely exceed 10KB, and most implementations are 709 concerned with keeping certificate sizes down. However, a 710 pathological or malicious certificate could easily exceed these 711 metrics. If an URN resolver cannot process a URN's full length, it 712 MUST reject the certspec. 714 When using element-based certspecs, the implementation MUST be 715 prepared to deal with multiple found certificates that contain the 716 same certificate data, but are not the same certificate. In such a 717 case, the implementation MUST segregate these certificates so that it 718 only resolves the URN to certificates that it considers valid or 719 trustworthy (as discussed further below). If, despite this 720 segregation, multiple valid or trustworthy certificates match the 721 certspec, the certspec MUST be rejected, because a certspec is meant 722 to identify exactly one certificate (not a family of certificates). 724 Certificates identified by certspecs should only be used with an 725 analysis of their validity, such as by computing the Certification 726 Path Validation Algorithm ([RFC5280] sec. 6) or by other means. For 727 example, if a certificate database contains a set of certificates 728 that it considers inherently trustworthy, then the inclusion of a 729 certificate in that set makes it trustworthy, regardless of the 730 results of the Certification Path Validation Algorithm. Such a 731 database is frequently used for "Root CA" lists. 733 12. References 735 12.1. Normative References 737 [LDAPDESC] 738 IANA, "LDAP Parameters: Object Identifier Descriptors", 739 . 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 747 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 748 1998. 750 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 751 "Uniform Resource Names (URN) Namespace Definition 752 Mechanisms", BCP 66, RFC 3406, October 2002. 754 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 755 Resource Identifier (URI): Generic Syntax", STD 66, RFC 756 3986, January 2005. 758 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 759 (LDAP): Directory Information Models", RFC 4512, June 760 2006. 762 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 763 (LDAP): String Representation of Distinguished Names", RFC 764 4514, June 2006. 766 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 767 Syntaxes and Matching Rules", RFC 4517, June 2006. 769 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 770 Encodings", RFC 4648, October 2006. 772 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 773 Specifications: ABNF", STD 68, RFC 5234, January 2008. 775 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 776 Housley, R., and W. Polk, "Internet X.509 Public Key 777 Infrastructure Certificate and Certificate Revocation List 778 (CRL) Profile", RFC 5280, May 2008. 780 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 781 Mail Extensions (S/MIME) Version 3.2 Certificate 782 Handling", RFC 5750, January 2010. 784 [SHS] National Institute of Standards and Technology, "Secure 785 Hash Standard", Federal Information Processing Standard 786 (FIPS) 180-4, March 2012, 787 . 790 [URNBIS] Saint-Andre, P., "Uniform Resource Name (URN) Syntax", 791 draft-ietf-urnbis-rfc2141bis-urn-07 (work in progress), 792 January 2014. 794 12.2. Informative References 796 [PT] Josefsson, S. and S. Leonard, "Text Encodings of PKIX and 797 CMS Structures", draft-josefsson-pkix-textual-02 (work in 798 progress), April 2014. 800 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 801 Mail: Part I: Message Encryption and Authentication 802 Procedures", RFC 1421, February 1993. 804 [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 805 Access Protocol (v3): UTF-8 String Representation of 806 Distinguished Names", RFC 2253, December 1997. 808 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 809 RFC 5652, September 2009. 811 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 812 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 813 RFC 6151, March 2011. 815 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 816 Keranen, A., and P. Hallam-Baker, "Naming Things with 817 Hashes", RFC 6920, April 2013. 819 Appendix A. Relaxed Processing for Issuer Distinguished Name 821 If human input is anticipated, an application may relax its 822 processing of the issuer distinguished name in the issuersn spec. 823 The following techniques will not produce a strictly conforming 824 certspec URN, but may prove useful in mapping borderline inputs to 825 valid URNs (and therefore, to specific certificates). Most of these 826 techniques are reflected in the distinguishedNameUCrelaxed 827 production. 829 A real-world LDAP string will likely contain spaces, such as between 830 words. Parsers SHOULD accept spaces when parsing this certspec; 831 generators MAY emit spaces when strict conformance to URN syntax is 832 less important than human readability (for example, when the URN is 833 rendered for display, or in cases where the URN is expected to be 834 handled by humans). 836 Distinguished name attribute values may include Unicode characters 837 outside of the US-ASCII range (0x00-0x7F), as well as characters that 838 need to be escaped with [RFC4514] rules. The interaction between 839 URNs, LDAP strings, and human usability allows for multiple 840 representations of these characters, two of which are strictly 841 conformant and one of which should be anticipated for human input. 843 At the LDAP string level, a non-ASCII character can be a UTF-8 844 sequence, or can be escaped with "\" followed by two hex digits for 845 each UTF-8 octet in the sequence. At the URN level, a UTF-8 sequence 846 must be converted to "%" followed by two hex digits for each UTF-8 847 octet in the sequence; if the characters are already escaped, "\" 848 must be converted to %5C. 850 Example Attribute: 852 Name: sn 853 Value: E. Mu1oz$el is actually U+00F1 Latin Small Letter N With Tilde, 855 UTF-8 encoded as octets 0xC3 0xB1. 856 $ is sub-delim; it may appear in a URN assigned-name. 857 < is required to be escaped per LDAP string rules. 858 ? is gen-delim; it may not appear in a URN assigned-name. 860 Conformant LDAP Strings: 862 sn=E. Mu1oz$el\