idnits 2.17.1 draft-seantek-certspec-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 08, 2013) is 3821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CITE' is mentioned on line 611, but not defined == Unused Reference: 'RFC3406' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC3187' is defined on line 791, 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-06 == 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) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 November 08, 2013 5 Expires: May 12, 2014 7 A Uniform Resource Name (URN) Namespace for Certificates 8 draft-seantek-certspec-02 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 May 12, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 [RFC2119]. 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 exceptions for usability. Following [URNBIS], 147 NID is "cert", and the Namespace Specific String (NSS) has the ABNF 148 below. The query and fragment productions are relevant to certspecs; 149 these are discussed in Section 7. 151 NSS = certspec-hash / 152 certspec-content / 153 certspec-el / 154 other-certspec-type ":" other-certspec-value 156 hexOctet = 2HEXDIG 158 certspec-hash = "SHA-1" ":" 20hexOctet / 159 "SHA-256" ":" 32hexOctet / 160 "SHA-384" ":" 48hexOctet / 161 "SHA-512" ":" 64hexOctet 163 certspec-content = "hex" ":" 1*hexOctet / 164 "base64" ":" base64url / 165 base64relaxed 167 base64url = 1*base64urlcharP 168 base64relaxed = 1*(base64urlcharP / "+" / "/") ; not pchar 170 base64urlchar = ALPHA / DIGIT / "-" / "_" 172 base64urlcharP = base64urlchar / pct-encoded ; from RFC 3986 174 certspec-el = "issuersn" ":" distinguishedNameUC ";" 175 serialNumber / 176 "ski" ":" 1*(hexOctet) 178 distinguishedNameUC = 1*pchar / ; from RFC 3986 179 distinguishedNameUCrelaxed 181 distinguishedNameUCrelaxed = 1*(pchar / WSP) ; not pchar 183 serialNumber = 1*hexOctet 185 certspec-type = scheme ; from RFC 3986 186 certspec-value = 1*pchar ; from RFC 3986 188 other-certspec-type = certspec-type 189 other-certspec-value = certspec-value 191 Figure 1 193 4.1. certspec-type and certspec-value 195 A certspec NSS is comprised of two parts: certspec-type and certspec- 196 value. The certspec-type identifies the certificate specification 197 type. The acceptable characters for spec-type are the same as those 198 in an URI scheme name (Section 3.1 in [RFC3986]); types are compared 199 case-insensitively. The certspec-value identifies the certificate 200 specification value. The acceptable characters for spec-value depend 201 on the spec-type, but are never more than pchar except for relaxed 202 human usability reasons in a few cases discussed below. In several 203 cases, characters are significantly restricted, to the point that 204 percent-encoding is prohibited. In such cases, a generator MUST NOT 205 generate percent-encoded values, and a parser MUST treat the 206 production as an error. The reasons are to simplify processing in 207 such cases, and to improve human usability. 209 Several certspecs use hexadecimal encodings of octets. Generally: if 210 the hex octets are malformed (whether in the source material, such as 211 the corresponding certificate element, or in the hex text), the 212 certspec is invalid. 214 5. Standard Certificate Specifications 216 Standard certificate specifications are intended for interchange as 217 durable, persistent, unique, and intuitive (to users and developers) 218 identifiers for individual certificates--the exact criteria for URNs. 219 This section provides four cryptographic hash-based certspecs, two 220 content-based certspecs, and two element-based certspecs. 222 5.1. Cryptographic Hash-Based Specifications 224 A cryptographic hash or "fingerprint" of a certificate uniquely 225 identifies that certificate. For hash-based certspecs, the hash is 226 computed over the octets of the DER encoding of the certificate, 227 namely, the Certificate type in Section 4.1 of [RFC5280]. The 228 certspec-value is the hexadecimal encoding of the hash value octets. 229 For example, a 256-bit SHA-256 hash is represented by exactly 32 hex 230 octets, or 64 hex characters. 232 Lexical equivalence of two hash-based certspecs that have the same 233 certspec-type SHALL be determined by a case-insensitive comparison of 234 certspec-values, or by converting the hexadecimal certspec-values to 235 octets and comparing exact equivalence of the octets. A conforming 236 implementation MUST reject values that contain non-hex digits, such 237 as spaces, tabs, hyphens, percent-encoded characters, or anything 238 else. 240 Conforming implementations to this Internet-Draft MUST process these 241 hash-based certspecs, unless security considerations dictate 242 otherwise. Acceptable reasons for refusing to process a certspec 243 include a) the local policy prohibits use of the hash, or b) the hash 244 has known cryptographic weaknesses, such as a preimage attacks, which 245 weaken the cryptographic uniqueness guarantees of the hash. 247 5.1.1. SHA-1 249 The certspec-type is "SHA-1". The hash is computed using SHA-1 250 [SHS]. 252 5.1.2. SHA-256 254 The certspec-type is "SHA-256". The hash is computed using SHA-256 255 [SHS]. 257 5.1.3. SHA-384 259 The certspec-type is "SHA-384". The hash is computed using SHA-384 260 [SHS]. 262 5.1.4. SHA-512 264 The certspec-type is "SHA-512". The hash is computed using SHA-512 265 [SHS]. 267 5.2. Content-Based Specifications 269 A certificate may be identified reflexively by its constituent 270 octets. For small-to-medium certificates, identifying the 271 certificate by embedding it in the certspec will be computationally 272 efficient and resistant to denial-of-service attacks (by always being 273 available). A conforming implementation MUST implement base64 and 274 hex specs. 276 The octets of a certificate are the octets of the DER encoding of the 277 certificate, namely, the Certificate type in Section 4.1 of 278 [RFC5280]. The DER encoding includes tag and length octets, so it 279 always starts with 30h (the tag for SEQUENCE). 281 Lexical equivalence of two certspecs that are value-based SHALL be 282 determined by decoding the certspec-value to certificate octets, and 283 comparing the octets for strict equivalence. Accordingly, it is 284 possible that base64 and hex certspecs are lexically equivalent. 286 Because users may end up copying and pasting base64 or hex-encoded 287 certificates into certspecs, and because these certspecs will 288 routinely exceed 72 characters, a production might contain embedded 289 whitespace. If there are contexts where line breaks or other 290 whitespace must be allowed for practical reasons, the implementation 291 should consider the URN in context as "a URN, possibly with embedded 292 whitespace (which is ignored)". 294 5.2.1. base64 296 The certspec-type is "base64". The certspec-value is the base64url 297 encoding of the certificate octets (Section 5 of [RFC4648]), but MAY 298 be relaxed as follows. Unlike the data: URL [RFC2397], URN NSS 299 productions are not supposed to have the "/" character, which is 300 integral to standard base64. On the other hand, it is anticipated 301 that users will want to copy-and-paste base64 encoded certificates-- 302 such as those produced by PKIX text encodings--directly into base64 303 certspecs. Generators of base64 certspecs SHOULD emit base64url- 304 encoded data, where the characters '-' and '_' refer to values 62 and 305 63, respectively, and where the trailing equal signs '=' are absent. 306 Alternatively, generators MAY emit base64 data with precent-encoding 307 for the non-pchar conformant characters (specifically "/"). In any 308 event, generators MUST NOT generate non-pchar conformant characters 309 (specifically "/"). Parsers of base64 certspecs that are not under 310 strict URN conformance constraints MUST also accept '+' and '/' as 311 values 62 and 63, respectively, and MUST accept trailing '=' 312 characters in conformance with standard base64. None of '+', '/', or 313 '=' have reserved meanings in this certspec-type. This relaxed 314 parsing rule is reflected in the base64relaxed production of Figure 315 1. 317 Similarly, [URNBIS] states that non-reserved characters (in this 318 case, alphanumerics) must not be "%"-encoded, but a lenient 319 implementation MAY decode these "%"-encoded characters anyway. This 320 document neither recommends nor discourages such leniency, but 321 implementors should weigh the benefits and risks as discussed further 322 in the Security Considerations (Section 11). Overall, percent- 323 encoding in base64 certspecs is permissible because unlike most of 324 the other certspecs, the complete base64 encoding is not expected to 325 be human-readable or identifiable at a glance. 327 5.2.2. hex 329 The certspec-type is "hex". The certspec-value is the hexadecimal 330 encoding of the certificate octets. Percent-encoding is not allowed; 331 implementations MUST NOT process percent-encoded values. The reasons 332 are because percent-encoding would reduce the human readability of 333 the certspec, and (marginally) increase the complexity of certspec 334 parsers. 336 5.3. Element-Based Specifications 337 A certificate may be identified by certain data elements contained 338 within it. The following certspecs reflect the traditional reliance 339 of PKIX [RFC5280] and CMS [RFC5652] on a certificate's issuer 340 distinguished name and serial number, or a certificate's subject key 341 identifier. 343 If some of an element-based certspec is based on the DER encoded part 344 of a certificate, and if the encodings are incorrect, the URN is 345 invalid. 347 5.3.1. issuersn: Issuer Name and Serial Number 349 The certspec-type is "issuersn". 351 The distinguishedNameUC production encodes the certificate's issuer 352 distingiushed name (DN) field in LDAP string format, whose characters 353 are subsequently percent-encoded to conform to URN NSS syntax. The 354 on which distinguishedNameUC is based is defined 355 in [RFC4514], and is defined in [RFC4512]. [RFC4514] no 356 longer separates relative distinguished names (RDNs) by semicolons, 357 as required by its predecessor, [RFC2253]. Accordingly, ';' is used 358 to separate the issuer's DN from the subject's serial number. 360 Care should be taken in escaping and percent-encoding the relevant 361 characters. In particular: "?" is permitted in a distinguishedName, 362 but MUST NOT appear in a URN unless it delimits the query component 363 (see [URNBIS]). Any question marks in distinguished names MUST be 364 percent-encoded when placed in the certspec-value. "#" is used as a 365 token at the beginning of the hexstring production for attributeValue 366 data, but MUST NOT appear in a URN unless it delimits the fragment 367 component (see [URNBIS]). Any "#" characters in distinguished names 368 MUST be percent-encoded when placed in the certspec-value. 370 Due to the nature of distinguished names, it is likely that a given 371 LDAP string will contain spaces (for example, between words). 372 Additionally, implementations might consider emitting spacing between 373 name components for readability. For human usability, it is 374 anticipated that parsers would encounter such whitespace, even though 375 those characters are supposed to be percent-encoded in URNs. Parsers 376 SHOULD accept spaces when parsing this certspec; generators MAY emit 377 spaces when strict conformance to URN syntax is less important than 378 human readability (for example, when the URN is rendered for display, 379 or in cases where the URN is expected to be handled by humans). 380 These considerations are reflected in the distinguishedNameUCrelaxed 381 production. 383 For reference, the following characters are permitted in 384 distinguished names in the issuer production: 386 [[TODO put table here of valid characters, and spaces]] 388 The serialNumber production is the hexadecimal encoding of the 389 contents octets of the DER encoding of the CertificateSerialNumber 390 ::= INTEGER as specified in Section 4.1 of [RFC5280]. 392 A conforming implementation SHOULD implement this issuersn certspec. 393 If the implementation implements it, the implementation MUST process 394 serial numbers up to the same length as required by Section 4.1.2.2 395 of [RFC5280] (20 octets), and MUST process distinguished name strings 396 as required by [RFC4514], including the table of minimum 397 AttributeType name strings that MUST be recognized. Additionally, 398 implementations MUST process attribute descriptors specified in 399 [RFC5280] (MUST or SHOULD), and [RFC5750] (specifically: E, email, 400 emailAddress). Implementations are encouraged to recognize 401 additional attribute descriptors where possible. A complete list of 402 attribute descriptors for reference is provided in Appendix A. 404 Lexical equivalence of two issuersn certspecs SHALL be determined by 405 comparing the serialNumbers for exact equivalence, and comparing the 406 issuer distinguished names for a match. 408 The lexical equivalence of serialNumbers SHALL be determined by a 409 case-insensitive comparison of them, or by converting the hexadecimal 410 text to octets and comparing exact equivalence of the octets. A 411 conforming implementation MUST reject values that contain non-hex 412 digits, such as spaces, tabs, hyphens, percent-encoded characters, or 413 anything else. 415 Distinguished names match if they satisfy the name matching 416 requirements of [RFC5280] and [RFC4514] [TODO: or matching rules in 417 LDAP RFCs]. 419 5.3.2. ski: Subject Key Identifier 421 The certspec-type is "ski". The certspec-value is the hexadecimal 422 encoding of the certificate's subject key identifier, which is 423 recorded in the certificate's Subject Key Identifier extension 424 (Section 4.2.1.2 of [RFC5280]). The octets are the DER-encoded 425 contents octets of the SubjectKeyIdentifier (OCTET STRING) extension 426 value. A certificate that lacks a subject key identifier cannot and 427 MUST NOT be identified using this spec. 429 Lexical equivalence of two ski certspecs SHALL be determined by a 430 case-insensitive comparison of certspec-values, or by converting the 431 hexadecimal certspec-values to octets and comparing exact equivalence 432 of the octets. A conforming implementation MUST reject values that 433 contain non-hex digits, such as spaces, tabs, hyphens, percent- 434 encoded characters, or anything else. 436 A conforming implementation MAY implement this ski spec. 438 6. Other Certificate Specifications 440 The additional certificate specifications in this section are 441 provided for applications to use as local identifiers that are 442 useful, intuitive, or supportive of legacy systems or overriding 443 design goals. These certspecs SHOULD NOT be used for interchange. 445 6.1. data (Reserved) 447 The certspec-type is "data". This document reserves this spec-type 448 for future use. 450 An implementation may embed the contents of a data URL (data URI) 451 into the certspec-value. Specifically: 453 ; from RFC 2397 454 certspec-value = [ mediatype ] [ ";base64" ] "," data 456 See [RFC2397]. In such a case, the mediatype SHOULD be "application/ 457 pkix-cert" since the data URL components identify a certificate; 458 however, an implementation MAY be able to support other media types 459 so long as a single certificate is extractable from the data 460 production. 462 Data URLs containing certificates generally will not conform to URN 463 syntax "as-is". The considerations of stuffing base64-encoded 464 content into URNs discussed in Section 5.2.1 apply to this certspec 465 as well, bearing in mind that data URLs only contain traditional 466 base64 (not base64url)-encoded data, or binary percent-encoded data. 468 Because this certspec is content-based, an implementation can 469 determine lexical equivalence with other content-based certspecs. 471 6.2. dbkey (Reserved) 473 The spec-type is "dbkey". This document reserves this spec-type for 474 future use. 476 6.3. subject (Reserved) 478 The certspec-type is "subject". The certspec-value is the RFC 4514 479 LDAP string encoding of the certificate's subject distinguished name. 480 Characters MAY be percent-encoded; implementations MUST process the 481 percent-encoded characters in the certspec-value before further LDAP 482 string processing. All the considerations of encoding the issuer 483 field in Section 5.3.1 apply to this type. 485 7. Query and Fragment Productions 487 [URNBIS] clarifies that the query and fragment productions of 488 [RFC3986] apply to URNs. This document provides semantics for these 489 productions, as applied to certificates. 491 ; query for certspec URN 492 certattrs = query ; from RFC 3986 493 ; *( pchar / "/" / "?" ) 495 ; fragment for certspec URN 496 certpart = "v" / "sn" / "sig" / "issuer" / "notBefore " / 497 "notAfter" / "subject" / "spki" / 498 "ext" *(":" extoid *(":" extpart)) / 499 "sigval" / other-certpart 501 extoid = numericoid ; from RFC 4512 502 extpart = fragment ; from RFC 3986 503 other-certpart = fragment ; from RFC 3986 505 7.1. Equivalence Unaffected 507 As a certspec identifies a single certificate, two certspecs are 508 identical lexically or semantically if the NSS parts identify the 509 same certificate. The query and fragment productions do not affect 510 this equivalence. 512 7.2. Query (Attributes) 514 A certspec URN can have attributes (i.e., metadata) that are 515 associated with--but not instrinsic to--the certificate or its 516 identifiers. The syntax is intended primarily to convey certificate 517 metadata such as attributes found in PKCS #9, PKCS #11, PKCS #12, and 518 particular implementations of cryptographic libraries. This document 519 does not further define certattrs; the characters of certattrs can be 520 any valid query character from [RFC3986]. 522 7.3. Fragment 524 A certspec can include a fragment that identifies a part of interest 525 within the identified certificate. For example, a user agent may 526 wish to draw attention to the notAfter time for an expired 527 certificate. This document defines the following fragments 528 ("certparts"): 530 +---------------+---------------------------------------------------+ 531 | Identifier | Certificate Part (ASN.1 identifier) | 532 +---------------+---------------------------------------------------+ 533 | v | tbsCertificate.version | 534 | sn | tbsCertificate.serialNumber | 535 | sig | tbsCertificate.signature; also signatureAlgorithm | 536 | issuer | tbsCertificate.issuer | 537 | notBefore | tbsCertificate.validity.notBefore | 538 | notAfter | tbsCertificate.validity.notAfter | 539 | subject | tbsCertificate.subject | 540 | spki | tbsCertificate.subjectPublicKeyInfo | 541 | ext | tbsCertificate.extensions | 542 | ext: | tbsCertificate.extensions {Extension matching | 543 | | extoid == extnID}* | 544 | sigval | signatureValue | 545 +---------------+---------------------------------------------------+ 547 * The particular extension in the Extensions SEQUENCE is identified 548 by OID only; there are no textual identifiers. 550 Table 1: certparts 552 The certparts defined in the table above are case-insensitive. 553 Should additional certparts be required, a future document may 554 specify additional certparts that match the other-certpart 555 production. 557 8. Registration Template 559 Namespace ID: 560 cert 562 Registration Information: 563 Version: 1 564 Date: 2013-11-07 566 Declared registrant of the namespace: 567 IETF 569 Declaration of syntactic structures: 570 The structure of the Namespace Specific String is provided 571 above. 573 Relevant ancillary documentation: 574 Certificates are defined by [RFC5280] and [X.509]. 576 Identifier uniqueness considerations: 577 The certspec-type is assigned by IANA through the IETF 578 consensus process, so this process guarantees uniqueness of 579 these identifiers. The uniqueness of the certspec-value 580 is guaranteed by the definition of the value for 581 the certspec-type. For cryptographic hash-based certspecs, the 582 cryptographic hash algorithm itself guarantees uniquess. 583 For contents-based certspecs, the inclusion 584 of the certificate in the URN itself guarantees uniqueness. 585 For certspecs that identify certificates by certificate data 586 elements, as long as certificate issuers issue 587 certificates correctly, and the resolver's database of 588 certificates and the resolver's implementation 589 of certification path validation [RFC5280 sec. 6] are 590 consistent, no cert URN will identify two different 591 certificates. 593 Identifier persistence considerations: 594 A certificate is a permanent digital artifact, irrespective of 595 its origin. As the URN records only information that is 596 derivable from the certificate itself, such as one of its 597 cryptographic hashes, the binding between the URN and the 598 certificate is permanent. 599 Once the set of cert URNs identify a particular 600 certificate, that fact will never change. 602 Process of identifiers assignment: 603 Generating a certspec (cert URN) does not require that 604 a registration authority be contacted. 606 Process for identifier resolution: 607 This Internet Draft does not specify a resolution service 608 for certspecs. However, resolving certificate references 609 to actual certificates is a common practice with a wide number 610 of offline and online implementations. 611 [CITE][CITE][CITE][CITE] 613 Rules for Lexical Equivalence: 615 Certspecs (cert URNs) are lexically equivalent if they both 616 have the same certspec-type (compared case-insensitively) 617 and the same certspec-value, and therefore impliedly point 618 to the same certificate. 619 Comparison of certspec-values depends on the rules of the 620 certspec. 621 Additionally, the contents-based certspecs, base64 and hex 622 (and--if implemented--the data certspec), can be compared for 623 lexical equivalence between each other by decoding the 624 certspec-value to the underlying DER-encoded certificate 625 octets, and comparing these octets for exact equivalence. 626 Query ("certattrs") and fragment ("certpart") components 627 do not affect certificate identification, and therefore 628 do not affect lexical equivalence. 630 Certspecs are semantically equivalent if they both resolve 631 to the same certificate. 633 Conformance with URN Syntax: 634 The character '?' is reserved for future extensions to this 635 specification. The URN of this namespace conforms to URN Syntax 636 [RFC2141] and Uniform Resource Identifier (URI): Generic Syntax 637 [RFC3986]. 639 Validation mechanism: 640 Each certspec defines the validation mechanism for its respective 641 value. It may be appreciated that validation of the URN is a 642 completely different process from the Certification Path 643 Validation Algorithm [RFC5280 sec. 6], which determines whether 644 the *certificate* is valid. 646 Scope: 647 Global. 649 9. Use of certspec outside URN 651 certspec is useful wherever a system may need to include or refer to 652 a certificate. Some implementations may wish to refer to a 653 certificate without enabling all of the expressive power (and 654 security considerations) of URIs. Accordingly, this section provides 655 a uniform method for using a certspec outside of a URN. Examples: 657 urn:cert:SHA-1:3ea3f070773971539b9dbf1b98c54be3a4f0f3c8 658 urn:cert:issuersn:cn=AcmeIssuingCompany,st=California,c=US;0134F1 659 To use certspec outside of a URI (URN) context, simply omit the 660 prefix "urn:cert:". All other lexical rules apply, including 661 percent-encoding, query (certattrs), and fragment (certparts). Care 662 should be taken to process "?" and "#" in particular, since they 663 delimit the attributes and parts. A conforming implementation of raw 664 certspecs MUST permit the prefix "urn:cert:" in addition to the raw 665 certspec. Additionally, this document guarantees that the the 666 certspec-types "urn" and "cert" are RESERVED and will never be used. 667 However, implementors must take note that a raw certspec is not a 668 valid URI, because certspec-types are not registered URI schemes and 669 do not have the same semantics as URIs. 671 10. IANA Considerations 673 This document requests the assignment of formal URN namespace ID 674 "cert". 676 [[TODO: Consider...This document requests the creation of a registry 677 to record specs.]] New certspec types shall be ratified by the IETF 678 consensus process. [[Some commenters have suggested the creation of 679 a registry for certspec types. This is under consideration. One 680 drawback is that it is desirable to limit the certspec types for 681 interoperability and recognizability reasons--probably the only 682 reason to include more types is for using new hashes as old hash 683 algorithms become cryptanalyzed.]] 685 11. Security Considerations 687 Digital certificates are important building blocks for 688 authentication, integrity, authorization, and (occasionally) 689 confidentiality services. Accordingly, identifying digital 690 certificates incorrectly can have significant security ramifications. 692 When using hash-based certspecs, the cryptographic hash algorithm 693 MUST be implemented properly and SHOULD have no known attack vectors. 694 For this reason, algorithms that are considered "broken" as of the 695 date of this Internet-Draft, such as MD5 [RFC6151], are precluded 696 from being valid certspecs. The registration of a particular 697 algorithm spec in this namespace does NOT mean that it is acceptable 698 or safe for every usage, even though this Internet-Draft requires 699 that a conforming implementation MUST implement certain specs. 701 When using content-based certspecs, the implementation MUST be 702 prepared to process URNs of arbitrary length. As of this writing, 703 useful certificates rarely exceed 10KB, and most implementations are 704 concerned with keeping certificate sizes down rather than up [CITE: 705 Google SSL overclocking, etc.]. However, a pathological or malicious 706 certificate could easily exceed these metrics. If an URN resolver 707 cannot process a URN's full length, it MUST reject the certspec. 709 When using element-based certspecs, the implementation MUST be 710 prepared to deal with multiple found certificates that contain the 711 same certificate data, but are not the same certificate. In such a 712 case, the implementation MUST segregate these certificates so that it 713 only resolves the URN to certificates that it considers valid or 714 trustworthy (as discussed further below). If, despite this 715 segregation, multiple valid or trustworthy certificates match the 716 certspec, the certspec MUST be rejected, because a certspec is meant 717 to identify exactly one certificate (not a family of certificates). 719 Certificates identified by certspecs should only be used with an 720 analysis of their validity, such as by computing the Certification 721 Path Validation Algorithm ([RFC5280 sec. 6]) or by other means. For 722 example, if a certificate database contains a set of certificates 723 that it considers inherently trustworthy, then the inclusion of a 724 certificate in that set makes it trustworthy, regardless of the 725 results of the Certification Path Validation Algorithm. Such a 726 database is frequently used for "Root CA" lists. 728 12. References 730 12.1. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 737 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 738 1998. 740 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 741 "Uniform Resource Names (URN) Namespace Definition 742 Mechanisms", BCP 66, RFC 3406, October 2002. 744 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 745 Resource Identifier (URI): Generic Syntax", STD 66, RFC 746 3986, January 2005. 748 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 749 (LDAP): Directory Information Models", RFC 4512, June 750 2006. 752 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 753 (LDAP): String Representation of Distinguished Names", RFC 754 4514, June 2006. 756 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 757 Encodings", RFC 4648, October 2006. 759 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 760 Housley, R., and W. Polk, "Internet X.509 Public Key 761 Infrastructure Certificate and Certificate Revocation List 762 (CRL) Profile", RFC 5280, May 2008. 764 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 765 Mail Extensions (S/MIME) Version 3.2 Certificate 766 Handling", RFC 5750, January 2010. 768 [SHS] National Institute of Standards and Technology, "Secure 769 Hash Standard", Federal Information Processing Standard 770 (FIPS) 180-4, March 2012, . 773 [URNBIS] Saint-Andre, P., "Uniform Resource Name (URN) Syntax", 774 draft-ietf-urnbis-rfc2141bis-urn-06 (work in progress), 775 August 2013. 777 12.2. Informative References 779 [PT] Josefsson, S. and S. Leonard, "Text Encodings of PKIX and 780 CMS Structures", draft-josefsson-pkix-textual-02 (work in 781 progress), October 2013. 783 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 784 Mail: Part I: Message Encryption and Authentication 785 Procedures", RFC 1421, February 1993. 787 [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 788 Access Protocol (v3): UTF-8 String Representation of 789 Distinguished Names", RFC 2253, December 1997. 791 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 792 Book Numbers as Uniform Resource Names", RFC 3187, October 793 2001. 795 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 796 RFC 5652, September 2009. 798 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 799 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 800 RFC 6151, March 2011. 802 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 803 Keranen, A., and P. Hallam-Baker, "Naming Things with 804 Hashes", RFC 6920, April 2013. 806 Appendix A. Appendix A: Mandatory Attribute Descriptors for issuersn 807 certspec 809 As per [RFC4514], attribute descriptors case-insensitive. 811 [TODO: add table.] 813 Author's Address 815 Sean Leonard 816 Penango, Inc. 817 11400 West Olympic Boulevard 818 Suite 1500 819 Los Angeles, CA 90064 820 USA 822 Email: dev+ietf@seantek.com 823 URI: http://www.penango.com/