idnits 2.17.1 draft-seantek-certspec-06.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: ---------------------------------------------------------------------------- No issues found here. 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 8, 2016) is 2878 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'A-Z' is mentioned on line 529, but not defined == Unused Reference: 'RFC2119' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC2585' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC4517' is defined on line 961, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LDAPDESC' ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-16 -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2253 (Obsoleted by RFC 4510, RFC 4514) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 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: Standards Track June 8, 2016 5 Expires: December 10, 2016 7 String Specification for Certificates 8 draft-seantek-certspec-06 10 Abstract 12 Digital certificates are used in many systems and protocols to 13 identify and authenticate parties. This document describes a string 14 format that identifies certificates, along with optional attributes. 15 This string format has been engineered to work without re-encoding in 16 a variety of protocol slots. 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 10, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation and Purpose . . . . . . . . . . . . . . . . . . . 4 56 2.1. Static Identification . . . . . . . . . . . . . . . . . . 4 57 2.2. Relationship with Other Specifications . . . . . . . . . 5 58 3. certstring Syntax . . . . . . . . . . . . . . . . . . . . . . 6 59 4. certspec Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. certspec Type and Value . . . . . . . . . . . . . . . . . 7 61 5. Standard Certificate Specifications . . . . . . . . . . . . . 8 62 5.1. Cryptographic Hash-Based Specifications . . . . . . . . . 8 63 5.2. Content-Based Specifications . . . . . . . . . . . . . . 9 64 5.3. Element-Based Specifications . . . . . . . . . . . . . . 10 65 5.4. Path-Based Specifications . . . . . . . . . . . . . . . . 12 66 6. Other Certificate Specifications . . . . . . . . . . . . . . 13 67 6.1. DBKEY (Reserved) . . . . . . . . . . . . . . . . . . . . 14 68 6.2. SELECT (Reserved) . . . . . . . . . . . . . . . . . . . . 14 69 7. Multiple certspecs (multispec) . . . . . . . . . . . . . . . 14 70 8. Certificate Attributes (certattrs) . . . . . . . . . . . . . 14 71 8.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.2. Mandatory Attribute Support . . . . . . . . . . . . . . . 16 73 8.3. Canonicalization . . . . . . . . . . . . . . . . . . . . 17 74 9. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 10. Guidelines for Extending certspec . . . . . . . . . . . . . . 18 76 11. Use of certspec in Systems . . . . . . . . . . . . . . . . . 19 77 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 81 14.2. Informative References . . . . . . . . . . . . . . . . . 22 82 Appendix A. [[Omitted]] . . . . . . . . . . . . . . . . . . . . 23 83 Appendix B. Mandatory Attribute Descriptors for Distinguished 84 Names . . . . . . . . . . . . . . . . . . . . . . . 23 85 Appendix C. Recommended Attribute Descriptors for issuersn 86 certspec . . . . . . . . . . . . . . . . . . . . . . 25 87 Appendix D. Algorithm for Distinguishing Between (Public Key) 88 Certificates and Attribute Certificates . . . . . . 25 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 91 1. Introduction 93 Digital certificates [RFC5280] are used in many systems and protocols 94 to identify and authenticate parties. Security considerations 95 frequently require that the certificate must be identified with 96 certainty, because selecting the wrong certificate will lead to 97 validation errors (resulting in denial of service), or in improper 98 credential selection (resulting in unwanted disclosure or 99 substitution attacks). The goal of this document is to provide a 100 uniform syntax for identifying certificates with precision without 101 re-encoding in a variety of protocol slots. 103 Using this syntax, any protocol or system that refers to a 104 certificate in a textual format can unambiguously identify that 105 certificate by value or reference. Implementations that parse these 106 strings can resolve them into actual certificates. Examples include: 108 SHA-1:3ea3f070773971539b9dbf1b98c54be3a4f0f3c8 109 ISSUERSN:cn=AcmeIssuingCompany,st=California,c=US;0134F1 110 BASE64:MIIBHDCBxaADAgECAgIAmTAJBgcqhkjOPQQBMBAxDjAMBgNVBAMT 111 BVNtYWxsMB4XDTEzMTEwNTE5MjUzM1oXDTE2MDgwMjE5MjUzM1ow 112 EDEOMAwGA1UEAxMFU21hbGwwWTATBgcqhkjOPQIBBggqhkjOPQMB 113 BwNCAAS2kwRQ1thNMBMUq5d/SFdFr1uDidntNjXQrc3D/QpzYWkE 114 WDsxeY8xcbl2m0TBO4TJ/2CevdoOX0OMIOaqJ/TNoxAwDjAMBgNV 115 HRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIgPyF8ok6h2NxMQ4uJ 116 OcGcXYcvZ1ua0kB+rIv0omHcfNECICKwpTp3LDIwhlHTQ/DulQDD 117 eYn+lnYQVc2Gm1WKAuxp 118 /etc/myserver.cer|friendlyName=fluffy the Tomcat 119 URI:https://certificates.example.com/acme/BAADF00D.cer 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119. 127 1.2. Definitions 129 The term "certificate" means either a certificate [RFC5280] or an 130 attribute certificate [RFC5755]. When a certificate [RFC5280] alone 131 is to be distinguished, this specification may use the term "public 132 key certificate". 134 The term "whitespace" means HT, VT, FF, LF, CR, and SP, when 135 referring to the ASCII range. An implementation SHOULD also consider 136 whitespace beyond the ASCII range, if the implementation supports it, 137 e.g., the characters that have the White_Space character property in 138 [UNICODE].) 140 The term "content" means a fixed sequence of octets (i.e., data) with 141 an Internet media type and optional parameters. 143 2. Motivation and Purpose 145 Although certificates [RFC5280] have diverse applications, there has 146 been no uniform way to refer to a certificate in text. De-facto 147 standards such as PEM [RFC1421] and PKIX text encoding [RFC7468] are 148 used to include whole certificates in textual formats, but this 149 practice is impractical for a variety of use cases. Certificates 150 that identify long public keys (e.g., 2048-bit RSA keys) and that 151 contain required and recommended PKIX extensions can easily exceed 152 many kilobytes in length. 154 The purpose of this document is to provide a uniform textual format 155 for identifying individual certificates, with human usability as a 156 design goal. Certificate specifications, or "certspecs", are not 157 designed or intended to provide a search tool or query language to 158 match multiple certificates. The goal is to replace data elements 159 that would otherwise have to include whole certificates, or that 160 employ proprietary reference schemes. For example, certspecs fit 161 easily into XML/SGML data, YAML, JSON, and config files and databases 162 (e.g., .properties, .ini, and Windows Registry) with minimal required 163 escaping. 165 To be usable by humans, certspecs are supposed to be amenable to 166 copy-and-paste operations. The structure of a certspec is also 167 supposed to be plainly visible, do that someone glancing at a 168 certspec can ascertain the data types that it comprises. 170 2.1. Static Identification 172 Identifying a specific certificate by reference or value allows 173 diverse applications to have a common syntax. For example, 174 applications can store certspecs as local or shared preferences, so 175 that users can edit them without resorting to application-specific 176 storage formats or relying on the availability of particular 177 protocols represented by URIs (such as http:, ldap: [RFC4516], file: 178 [RFC1738], or ni: schemes). When conveyed in protocol, a certspec 179 can identify a specific certificate to a client or server using text- 180 based formats such as YAML, XML, JSON, and others. The format 181 described in this document is intended to be readily reproducible by 182 users using common certificate processing tools, so that users can 183 easily create, recognize, compare, and reproduce them at a glance. 184 For example, the hash-based identifications use hexadecimal encoding 185 so that a user can easily compose or compare an URN with a simple 186 copy-and-paste operation. 188 2.2. Relationship with Other Specifications 190 Previous versions of this draft attempted to define certspecs as a 191 URN namespace, and then as a family of URI schemes. Certspecs were 192 found to be incompatible with these approaches for several 193 engineering reasons. 195 The definition of URN [I-D.ietf-urnbis-rfc2141bis-urn] changed during 196 the course of this draft's development, and as of this publication, 197 remains unclear. Overall, URNs are meant to be assigned durably and 198 persistently by namespace authorities. An algorithm that identifies 199 a datum with high but not absolute precision does not satisfy this 200 requirement, because the pigeonhole principle shows that there will 201 always be collisions for unbounded data sets, even though finding 202 particular collisions may be computationally infeasible. (The other 203 specification types are even less precise.) 205 URI schemes were also pursued and rejected. URIs have dereferencing 206 semantics, which could have significant security implications. When 207 a URI is dereferenced, an access mechanism is determined and an 208 action is performed on the URI's resource (see Section 1.2.2 of 209 [RFC3986]). When the URI scheme identifies an information retrieval 210 protocol, such as HTTP, the access mechanisms usually involve 211 performing actions on the resource (most commonly, retrieving the 212 resource). However, a wide variety of standardized and proprietary 213 URI schemes do not correspond to information retrieval protocols; 214 instead, these URI schemes serve to launch applications associated 215 with the scheme names. The practical effect of dereferencing a 216 mailto: URI [RFC6068], for example, is to launch a preferred e-mail 217 client from a user agent (e.g., a web browser), so that the user can 218 easily send e-mail to a recipient with certain fields pre-populated 219 by the contents of a URI. The practical effect of the ymsgr: URI 220 [PROVURI] is much more application and vendor-specific: dereferencing 221 such a URI is supposed to launch Yahoo! Messenger to send an instant 222 message to a designated Yahoo! screen name. The launching semantics 223 of URIs are exploited in modern consumer desktop and mobile operating 224 systems as a convenient methodology to launch an application from 225 another application, as well as to communicate application-specific 226 data between applications that otherwise have no privileged 227 relationship. 229 The arbitrary, misdirected, or outright malicious launching of 230 applications to handle certificates has grave security implications. 231 These risks are mitigated by avoiding URI schemes for certspecs. 233 URI schemes such as ni: [RFC6920] and data: identify resources in a 234 similar way as (for example) the hash and data-based spec types, 235 although they were not as usable for copy-and-paste operations. 237 Resistance was encountered when new URI scheme names were proposed 238 that did similar things as ni: and data:, but with better usability 239 for this use case. 241 Nevertheless, this draft allows for specifying a certificate by URI, 242 recognizing that an implementation might categorically decline to 243 retrieve URI certspecs on security or other grounds. 245 To distinguish this syntax from URI syntax, this Internet-Draft 246 capitalizes the "introducer characters" of the various certspec types 247 and does not require that they be delimited with a colon, even though 248 these productions (mostly) are case-insensitive and (mostly) end with 249 a colon. OpenSSL's x509v3_config format inspired this aspect of the 250 syntax. 252 3. certstring Syntax 254 A certificate string ("certstring") is a string with a single 255 certspec (see Section 4) or multiple certspecs (a "multispec", see 256 Section 7), followed by an optional set of attributes ("certattrs", 257 see Section 8). While strings in this document can be in any 258 character encoding, the delimiter characters in this document are 259 drawn from ASCII; applications MUST support Unicode. The string has 260 the ABNF [RFC5234] below (TODO: case-sensitive ABNF, import core 261 rules). 263 certstring = (certspec / multispec) [ "|" certattrs ] 265 Figure 1: certstring ABNF 267 4. certspec Syntax 269 A certspec is a string that is intended to identify a single 270 certificate. A certspec has introducer characters followed by value 271 characters; these introducer characters MAY be part of the "value" of 272 the identifier. The string has the ABNF [RFC5234] below (TODO: case- 273 sensitive ABNF, import core rules). 275 certspec = certspec-hash / certspec-content / certspec-el / 276 certspec-path 278 hexOctet = 2HEXDIG 280 certspec-hash = "SHA-1" ":" 20hexOctet / 281 "SHA-256" ":" 32hexOctet / 282 "SHA-384" ":" 48hexOctet / 283 "SHA-512" ":" 64hexOctet / 284 certspec-other-hash 286 certspec-other-hash = certspec-hash-type ":" certspec-hash-value 287 ; Proposal: Hash Function Textual Name registry hereby limited 288 ; to RFC 3986 scheme characters 289 certspec-hash-type = scheme 290 ; implication is that it must be at least 128 bits 291 certspec-hash-value = 16*hexOctet 293 certspec-content = ("HEX" / "BASE16") ":" 1*hexOctet / 294 "BASE64" ":" base64string 296 base64char = ALPHA / DIGIT / "+" / "/" 297 base64string = 1*(4base64char) 298 [ 3base64char "=" / 2base64char "==" ] 300 ; distinguishedName from [RFC4514] 301 certspec-el = "ISSUERSN" ":" distinguishedName ";" serialNumber / 302 "SKI" ":" 1*(hexOctet) 304 serialNumber = 1*hexOctet 306 certspec-path = certspec-uri / certspec-filepath 308 ; from RFC3986; RFC 6570 309 certspec-uri = "URI:" URI-reference / URI-Template 311 ; see POSIX, etc. 312 certspec-filepath = ("/" / "\" / [A-Z] ":" / 313 ("." / "..") ("/" / "\") / "~" / "%" / "$") 314 *filepathchar 316 ; BEYONDASCII is from draft-seantek-more-core-rules 317 filepathchar = %x01-29 / %x2B-3B / "=" / %x40-5B / 318 %x5D-7B / %x7D-7F / quoted-fpc / BEYONDASCII 320 quoted-fpc = "\" ("*" / "<" / ">" / "?" / "\" / "|") 322 ; TODO: validate Windows file path characters 324 ; TODO: certattrs 326 Figure 2: certspec ABNF 328 4.1. certspec Type and Value 330 Semantically, a certspec is comprised of its type and value. The 331 value is always provided, but the type is either explicitly declared, 332 or is inferred from the initial (introducer) characters in the type. 333 When types are explicitly provided, they are compared case- 334 insensitively. The certspec-value identifies the certificate 335 specification value. 337 Several certspecs use hexadecimal encodings of octets. Generally: if 338 the hex octets are malformed (whether in the source material, such as 339 the corresponding certificate element, or in the hex text), the 340 certspec is invalid. 342 5. Standard Certificate Specifications 344 Standard certificate specifications are intended for interchange as 345 intuitive (to users and developers) identifiers for individual 346 certificates. This section provides four cryptographic hash-based 347 certspecs, two content-based certspecs, three element-based 348 certspecs, and two path-based certspecs. 350 5.1. Cryptographic Hash-Based Specifications 352 A cryptographic hash or "fingerprint" of a certificate uniquely 353 identifies that certificate. For hash-based certspecs, the hash is 354 computed over the octets of the DER encoding of the certificate, 355 namely, the Certificate type in Section 4.1 of [RFC5280] and the 356 AttributeCertificate type in Section 4.1 of [RFC5755]. The certspec- 357 value is the hexadecimal encoding of the hash value octets. For 358 example, a 256-bit SHA-256 hash is represented by exactly 32 hex 359 octets, or 64 hex characters. The hexadecimal encoding is not case 360 sensitive. 362 A conforming generator SHALL emit only hexadecimal encoded data, 363 i.e., the characters A-F (case-insensitive) and 0-9. 365 A conforming parser SHALL accept value productions that contain the 366 following non-hex digits: whitespace, hyphen, and colon. A 367 conforming parser MAY accept values that contain other characters. 369 Conforming implementations to this Internet-Draft MUST process these 370 hash-based certspecs, unless security considerations dictate 371 otherwise. Acceptable reasons for refusing to process a certspec 372 include a) the local policy prohibits use of the hash, or b) the hash 373 has known cryptographic weaknesses, such as a preimage attacks, which 374 weaken the cryptographic uniqueness guarantees of the hash. 376 5.1.1. SHA-1 378 The introducer production is "SHA-1:". The hash is computed using 379 SHA-1 [SHS]. 381 5.1.2. SHA-256 383 The introducer production is "SHA-256:". The hash is computed using 384 SHA-256 [SHS]. 386 5.1.3. SHA-384 388 The introducer production is "SHA-384:". The hash is computed using 389 SHA-384 [SHS]. 391 5.1.4. SHA-512 393 The introducer production is "SHA-512:". The hash is computed using 394 SHA-512 [SHS]. 396 5.2. Content-Based Specifications 398 Content-based certspecs identify certificates by their constituent 399 octets. For small-to-medium certificates, identifying the 400 certificate by embedding it in the certspec will be computationally 401 efficient and resistant to denial-of-service attacks (by always being 402 available). A conforming implementation MUST implement base64 and 403 hex specs. 405 The octets of a certificate are the octets of the DER encoding of the 406 certificate, namely, the Certificate type in Section 4.1 of [RFC5280] 407 and the AttributeCertificate type in Section 4.1 of [RFC5755]. The 408 DER encoding includes tag and length octets, so it always starts with 409 30h (the tag for SEQUENCE). 411 Because users may end up copying and pasting base64 or hex-encoded 412 certificates into certspecs, and because these certspecs will 413 routinely exceed 72 characters, a production might contain embedded 414 whitespace. A conforming generator SHALL emit no whitespace, or 415 SHALL emit a hanging indent, between semantically significant 416 characters. 418 5.2.1. BASE64 420 The introducer production is "BASE64:". The value production is the 421 BASE64 encoding of the certificate octets (Section 4 of [RFC4648]). 423 [[NB: base64url syntax was explicitly considered and rejected for 424 this draft. This is because certspecs are no longer URIs.]] 426 5.2.2. HEX and BASE16 428 The introducer production is "HEX:" or "BASE16:". Generators MUST 429 generate "HEX:"; parsers MUST accept "HEX:" and "BASE16:". The value 430 production is the hexadecimal encoding of the certificate octets. 432 5.3. Element-Based Specifications 434 A certificate may be identified by certain data elements contained 435 within it. The following certspecs reflect the traditional reliance 436 of PKIX [RFC5280] and CMS [RFC5652] on a certificate's issuer 437 distinguished name and serial number, a certificate's subject 438 distinguished name and expiration, or a certificate's subject key 439 identifier. 441 Note that distinguished names can contain "|" in attribute value 442 strings, but this production is unambiguous with the certattr 443 delimiter because distinguished names are always terminated by ";". 445 5.3.1. ISSUERSN: Issuer Name and Serial Number 447 The introducer production is "ISSUERSN:". 449 5.3.1.1. Issuer 451 The distinguishedName production encodes the certificate's issuer 452 distinguished name (DN) field in LDAP string format [RFC4514]. 453 [RFC4514] no longer separates relative distinguished names (RDNs) by 454 semicolons, as required by its predecessor, [RFC2253]. Accordingly, 455 ";" is used to separate the issuer's DN from the subject's serial 456 number. 458 5.3.1.2. Serial Number 460 The serialNumber production is the hexadecimal encoding the DER- 461 encoded contents octets of the CertificateSerialNumber (INTEGER, 462 i.e., not the type or length octets) as specified in Section 4.1.2.2 463 of [RFC5280]. 465 5.3.1.2.1. Conformance 467 A conforming implementation SHALL implement the ISSUERSN certspec. 468 An implementation MUST process serial numbers up to the same length 469 as required by Section 4.1.2.2 of [RFC5280] (20 octets), and MUST 470 process distinguished name strings as required by [RFC4514], 471 including the table of minimum AttributeType name strings that MUST 472 be recognized. Additionally, implementations MUST process attribute 473 descriptors specified in [RFC5280] (MUST or SHOULD), and [RFC5750] 474 (specifically: E, email, emailAddress). For reference, a complete 475 list of required attribute descriptors is provided in Appendix B. 476 Implementations are encouraged to recognize additional attribute 477 descriptors where possible. A sample list of such attribute 478 descriptors is provided in Appendix C. Conforming implementations 479 MUST be able to parse all distinguished name attribute types that are 480 encoded in OID dotted decimal form, as well as all distinguished name 481 attribute values that are encoded in "#" hexadecimal form. 483 5.3.1.3. SUBJECTEXP: Subject and Expiration 485 The introducer production is "SUBJECTEXP:". The value production is 486 the [RFC4514] encoding of the subject distinguished name, followed by 487 a semicolon, followed by the certificate expiration expressed in 488 standard form [[TODO: ASN.1 text form, or RFC3339 form? Proposal is 489 to allow both. ASN.1 text form: GeneralizedTime with four-digit 490 years (UTCTime/four-digit years SHALL NOT be used), in accordance 491 with Section 4.1.2.5.2 of [RFC5280]. RFC3339 form: The date-time 492 production from [RFC3339]. (The production requires the full four- 493 digit year, but allows for a time zone offset. Time zone offsets 494 MUST be supported on usability grounds.)]] The certificate's 495 expiration is the notAfter value of the certificate validity period 496 (Section 4.1.2.5 of [RFC5280]). 498 A conforming implementation SHALL parse and generate distinguished 499 name productions with the same adherence as stated above in 500 Section 5.3.1.2.1. 502 5.3.1.4. ski: Subject Key Identifier 504 The introducer production is "SKI:". The value production is the 505 hexadecimal encoding of the certificate's subject key identifier, 506 which is recorded in the certificate's Subject Key Identifier 507 extension (Section 4.2.1.2 of [RFC5280]). The octets are the DER- 508 encoded contents octets of the SubjectKeyIdentifier (OCTET STRING) 509 extension value. For a certificate that lacks a subject key 510 identifier, an underlying implementation MAY operatively associate a 511 subject key identifier with the certificate. 513 A conforming generator SHALL emit only hexadecimal encoded data, 514 i.e., the characters A-F (case-insensitive) and 0-9. 516 A conforming parser SHALL accept value productions that contain the 517 following non-hex digits: whitespace (HT, VT, SP, FF, CR, LF), 518 hyphen, and colon. A conforming parser MAY accept values that 519 contain other characters. 521 5.4. Path-Based Specifications 523 A certificate may be identified by a path to file or content data. A 524 conforming parser MUST recognize file path and URI specs, although 525 conforming implementations merely MAY process them. 527 5.4.1. File Path 529 File paths are identified by their introducer productions / \ [A-Z]: 530 ./ ../ .\ ..\ ~ % and $. The characters that follow MUST be valid 531 path characters for the system on which the files are being accessed. 532 Since the starting character sequences for file paths are fixed and 533 determinable, prefixing the file path with a type identifier is 534 (thought to be) unnecessary. 536 A relative file path begins with "." or "..", and is relative to a 537 "current directory". Determining an appropriate "current directory" 538 is outside the scope of this specification. 540 When the file is read, implementations MUST accept the following, 541 regardless of filename: 543 1. Textual data, which is analyzed as if it were text/plain content 544 (below) 546 2. Raw octet-oriented data, which is analyzed as if it were 547 application/octet-stream content (below) 549 File paths may have unexpanded environment variables, such as 550 %USERNAME% or ${LOGNAME}; implementations MUST parse these 551 environment variable syntaxes, but merely MAY perform environment 552 variable substitution as environment, capability, and security 553 concerns dictate. 555 Note that Unix-oriented file paths can contain "|" in the production 556 "\|", but this production is unambiguous with the certattr delimiter. 558 5.4.2. URI 560 The introducer production is "URI:". The value is a [RFC3986] 561 conforming URI-reference or [RFC6570] conforming URI-Template. 563 In the context of URIs, a relative reference conforms to the 564 relative-ref production of [RFC3986] and the usage described in 565 Section 4.2 of [RFC3986], it is relative to a "base URI". 566 Determining an appropriate "base URI" is outside the scope of this 567 specification. 569 When the URI is dereferenced, implementations MUST accept the 570 following, regardless of the path or query productions: 572 1. Content with media type application/pkix-cert and application/ 573 pkix-attr-cert 575 2. Content with media type application/pkcs7-mime and application/ 576 cms, when the content represents a SignedData containing 577 certificates (regardless of the smime-type or 578 encapsulatingContent parameters, and regardless of whether or not 579 the SignedData is in a degenerate, certs-only format) 581 3. Content with media type text/plain, which is analyzed according 582 to [RFC7468] for "CERTIFICATE" and "ATTRIBUTE CERTIFICATE" 583 textual encodings 585 4. Content with media type application/octet-stream, which is 586 analyzed for textual or [X.690] data 588 5. Raw textual data, which is analyzed as if it were text/plain 590 6. Raw octet-oriented data, which is analyzed as if it were 591 application/octet-stream 593 The URI certspec can include a fragment identifier. Implementations 594 MUST parse fragment identifiers, but merely MAY perform "secondary 595 resource" isolation and processing as environment, capability, and 596 security concerns dictate. 598 The URI certspec can be a URI Template [RFC6570]. Implementations 599 MUST parse URI templates, but merely MAY expand them in accordance 600 with [RFC6570] as environment, capability, and security concerns 601 dictate. 603 Note that URI templates can contain "|" in the production "{|".."}", 604 but this production is unambiguous with the certattr delimiter. 606 6. Other Certificate Specifications 608 The additional certificate specifications in this section are 609 provided for applications to use as local identifiers that are 610 useful, intuitive, or supportive of legacy systems or overriding 611 design goals. These certspecs SHOULD NOT be used for interchange. 613 6.1. DBKEY (Reserved) 615 The introducer production is "DBKEY:". The DBKEY certspec is meant 616 for an opaque string that serves as the unique key to a certificate 617 in an implementation's certificate database. This document reserves 618 this introducer sequence for future use. 620 6.2. SELECT (Reserved) 622 The introducer production is "SELECT" (without a colon). The SELECT 623 certspec is meant for a valid SQL statement (suitably escaped) that 624 retrieves a row representing a certificate. This document reserves 625 this introducer sequence for future use. 627 7. Multiple certspecs (multispec) 629 A multispec is a string that contains multiple certspecs, each of 630 which is intended to identify the exact same certificate. If 631 multiple certificates match a single spec, a single certificate can 632 be returned by the access operation, so long as the intersection of 633 certificates identified by all of the certspecs in the multispec is 634 one. The purpose of multispec is to provide multiple access and 635 verification methods. For example, a hash algorithm may have known 636 weaknesses, but may be the most efficient way to identify a 637 certificate (e.g., because it is the index method). Providing 638 additional certspecs (i.e., strong hash algorithms) would increase 639 the certainty that the correct certificate is accessed. 641 As the certspecs above make use of almost all other characters in the 642 ASCII range, < and > have been chosen to delimit certspecs between 643 each other. (Whitespace can also appear between each < and > 644 delimited certspec.) The ABNF of multispec is: 646 multispec = 1*("<" certspec ">") 648 Figure 3: multispec ABNF 650 8. Certificate Attributes (certattrs) 652 A certificate can have additional attributes (i.e., metadata) 653 operatively associated with--but not intrinsic to--it. For example, 654 the additional attributes may represent preferences. The syntax is 655 intended primarily to convey certificate metadata such as attributes 656 found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12 [RFC7292], 657 and particular implementations of cryptographic libraries. 659 Certattrs are delimited from a certspec or multispec production with 660 "|". Each certattr SHALL have a corresponding ASN.1 definition. The 661 textual syntax of certattrs is very similar to (in fact, a superset 662 of) [RFC4514]: the certattrs production represents the PKCS 663 Attributes family of types, which are repeatedly defined in those 664 standards, and standards that derive from them, as 665 SET SIZE (1..MAX) OF Attribute. E.g., CMS (from PKCS #7) [RFC5652], 666 private keys (from PKCS #8) [RFC5958], and PKCS #12 [RFC7292]. 667 Attributes are semantically unordered. Multiple attributes are 668 separated with ",". 670 Each attribute has a single attrType (canonically defined as OBJECT 671 IDENTIFIER in [RFC5652]), and a SET OF attrValues. The attrType is 672 encoded as the string representation of AttributeType (that is, 673 either a registered short name (descriptor) [RFC4520], or the dotted- 674 decimal encoding, of the OBJECT IDENTIFIER [RFC4512]). 676 When an attribute has at least one value, the attrType is followed by 677 "=" and the encoding of the attrValues (empty strings are possible). 678 Multiple attrValues are separated by "+". When the attribute has no 679 values, the attrType MUST NOT be followed by "=". 681 An attrValue can have one of several encodings: 683 hex: The attrValue can always be represented by "#" followed by the 684 hexadecimal encoding of each of the octets of the BER encoding of the 685 attrValue, following paragraph 1 of Section 2.4 of [RFC4514]. 686 Implementations MUST support this encoding. 688 string: If the attrValue has a LDAP-specific string encoding, that 689 encoding can be used as the string representation of the value, with 690 characters suitably escaped according to paragraph 2 and onward of 691 Section 2.4 of [RFC4514]. Implementations SHOULD support this 692 encoding for attributes of interest to it. 694 XER: The attrValue can be represented by its BASIC-XER encoding 695 [X.693] (Clause 8). When in BASIC-XER encoding, the string MUST be a 696 complete XML fragment comprising one element, i.e., there SHALL NOT 697 be an XML prolog. XER encoding is self-delimiting because it has 698 balanced elements; this string always begins with "<" and ends with 699 ">". Processing is simplified compared to arbitrary XML in that XML 700 processing instructions, XML comments, and CDATA sections are 701 prohibited. Implementations MAY support this encoding. 703 ASN.1 value: The attrValue can be represented by its ASN.1 value 704 notation [X.680], enclosed in quotation marks <"> on both ends. 705 [[NB: per RFC 4514, a leading space might also be unambiguous.]] 706 ASN.1 value notation requires a bit of finesse in that <"> can appear 707 inside to delimit "cstring" lexical items (see Clause 12.14 and 708 Clause 41 of [X.680]). A "cstring" starts and ends with <">, and can 709 represent <"> internally with a pair of consecutive <">. Therefore, 710 <"> is balanced because it always occurs in multiples of two. If the 711 value is just a cstring, then the representation will have exactly 712 two <"> at the beginning, and two <"> at the end, with evenly- 713 balanced <"> pairs inside. Other values that are not composites 714 (enclosed with "{" and "}") do not have <"> occur within them. 715 Otherwise, the representation must have at least one "{" "}" balanced 716 pair at either end, hemming in <"> occurrences to within the balanced 717 pairs of "{" and "}". Implementations MAY support this encoding. 719 Of the attrValue encodings listed above, only "hex" can reliably 720 transfer the underlying BER representation without an implementation 721 maintaining specific knowledge of every attribute. Therefore, "hex" 722 is RECOMMENDED for open interchange of certattrs. 724 8.1. ABNF 726 The collective ABNF of certattrs is: 728 certattrs = certattr ["," certattrs] 729 certattr = certattrType ["=" certattrValues] 730 ; descr, numericoid from RFC 4512 731 certattrType = descr / numericoid 732 certattrValues = certattrValue ["+" certAttrValues] 733 ; string, hexstring from RFC 4514 734 certattrValue = hexstring / string / 735 basic-xer-string / asn1-value-string 736 ; TODO: complete basic-xer-string, asn1-value-string 737 basic-xer-string = "<" ">" 738 ; TODO: may also distinguish with leading space " "--think about it 739 asn1-value-string = %x22 %x22 741 Figure 4: certattrs ABNF 743 8.2. Mandatory Attribute Support 745 [[NB: attributes related to certificate objects are in the domain of 746 CMS attributes, NOT distinguished name attributes. Therefore, 747 referring to the LDAP Object Identifier Descriptors subregistry may 748 actually be inappropriate, since it's pretty much filled with 749 attributes that one would encounter for distinguished names. The 750 "CMS attributes" encompass things like friendlyName and 751 smimeCapabilities from PKCS #9; they are a disjoint set from 752 distinguished name attributes. "CMS attributes" also encompass 753 things like signingTime and messageDigest; these attributes are not 754 interesting with respect to certificate objects.]] 755 A conforming implementation that supports certattrs SHALL process the 756 following attributes, including recognizing the following short names 757 (descriptors) and associated LDAP-specific string encodings. 759 friendlyName (1.2.840.113549.1.9.20) from PKCS #9 [RFC2985] 761 localKeyId (1.2.840.113549.1.9.21) from PKCS #9 [RFC2985] 763 signingDescription (1.2.840.113549.1.9.13) from PKCS #9 [RFC2985] 765 smimeCapabilities (1.2.840.113549.1.9.15) from PKCS #9 [RFC2985] 766 [[NB: smimeCapabilities does not have a SYNTAX with an LDAP-specific 767 encoding. ASN.1 value notation is probably the most readable 768 alternative, but support for ASN.1 value notation remains OPTIONAL.]] 770 8.3. Canonicalization 772 The certattrs production is a textual encoding of the ASN.1 773 SET SIZE (1..MAX) OF Attribute. The textual format in this section 774 is not intended to be used as any kind of canonical form. The 775 canonical form is the DER encoding of the corresponding 776 SET SIZE (1..MAX) OF Attribute. 778 9. Whitespace 780 This specification is intended for textual data that may be visible 781 to or edited by humans. Whitespace is a key factor in usability, so 782 this specification permits whitespace in certain productions. 784 The certspec, multispec, certattrs, and certstring productions are 785 ideally emitted as one (long) line. The overall intent is that a 786 bare line break (without leading or trailing horizontal space) is 787 supposed to delimit these productions from each other. 789 If it is desirable to break one of these productions across multiple 790 lines, a hanging indent SHALL be used at syntactically appropriate 791 places. A hanging indent means a newline production (LF, CRLF, or 792 other characters appropriate to the character set, e.g., [[UNICODE]]) 793 followed by one or more horizontal space characters. The preferred 794 horizontal space production is a single SP character. 796 Generally, where whitespace is permitted, the whitespace either has 797 no semantic meaning and therefore can be collapsed to a zero-length 798 substring, i.e., skipped, or can be folded into a single whitespace 799 character, i.e., a single SP. 801 Productions that represent the hexadecimal (or base64) encodings of 802 octets MAY have arbitrary whitespace interspersed between the 803 hexadecimal (or base64) characters. The whitespace has no semantic 804 meaning, and can be collapsed. Certspec and certattrs parsers that 805 parse "#" delimited attribute values in distinguished names and 806 certificate attributes MAY accept and collapse whitespace; however, 807 such whitespace is not permitted by [RFC4514]. Note that the 808 attribute value MUST begin with "#"; there MUST NOT be leading 809 whitespace. 811 A parser MAY accept whitespace preceding the certattrType production 812 in certattrs. 814 A parser MAY accept whitespace between each angle-bracket-delimited 815 certspec in the multispec production. 817 A parser MAY accept whitespace preceding the attributeType production 818 in distinguishedName. 820 Generally, whitespace characters in values are otherwise considered 821 to be semantically meaningful. A generator SHOULD encode such 822 characters (e.g., with hexpair [RFC4514]) to avoid ambiguity or 823 corruption. 825 10. Guidelines for Extending certspec 827 The certspec definition presented in this document is intended to be 828 fairly comprehensive. Nevertheless, there are several points of 829 extension for implementors who may want to identify a certificate 830 with more than what is presented in this document. 832 Firstly, certspec is naturally extended by supporting additional hash 833 algorithms. The hash introducer characters are tied to the Hash 834 Function Textual Names Registry; adding a new hash algorithm to that 835 registry is necessary for certificates to get identified with that 836 hash algorithm under this specification. However, for security 837 reasons, the introducers "MD2" and "MD5" SHALL NOT be generated or 838 parsed. 840 Secondly, certspec allows for the full range of "local" identifiers 841 (i.e., file paths, which may not actually be local) and "network" 842 identifiers (i.e., URIs, which may not actually need the network). A 843 certspec implementation that can make use of these facilities can 844 naturally be extended by extending the path (e.g., with pipes and 845 mount points) or the URI topology (e.g., with novel URI schemes). 847 Implementations MAY recognize other types of certspecs. However, new 848 types intended for open interchange require an update to this 849 document. 851 A new certspec SHALL satisfy the following criteria: 853 1. The type is identified by a keyword, followed by ":", or, the 854 type is identified by very short sequences of characters that 855 unambiguously signal the type of the certspec value (as file 856 paths currently do). The specification MUST state whether the 857 introducer characters are case-sensitive. 859 2. The characters "<", ">", and "|" need to be distinguishable from 860 their uses in multispec and certattrs (certstring) using a 861 context-free grammar, e.g., ABNF. 863 3. [[TODO: further elaborate, or remove.]] If internal whitespace 864 (including line-breaking) is permitted, the internal whitespace 865 is consistent with this specification. 867 11. Use of certspec in Systems 869 certspec is useful wherever a system may need to include or refer to 870 a certificate. Some systems may wish to refer to a certificate 871 without enabling all of the expressive power (and security 872 considerations) of all strings in this specification. Accordingly, 873 those systems and specifications SHOULD develop profiles of this 874 specification. 876 This document guarantees that the introducer characters "URN:" and 877 "CERT:" are RESERVED and will never be used. Implementors MUST take 878 note that a raw certspec is not a valid URI: certspec-types are not 879 registered URI schemes, have a broader character repertoire than 880 permitted by [RFC3986], and do not have the same semantics as URIs. 882 12. IANA Considerations 884 This document implies no IANA considerations. 886 13. Security Considerations 888 Digital certificates are important building blocks for 889 authentication, integrity, authorization, and (occasionally) 890 confidentiality services. Accordingly, identifying digital 891 certificates incorrectly can have significant security ramifications. 893 When using hash-based certspecs, the cryptographic hash algorithm 894 MUST be implemented properly and SHOULD have no known attack vectors. 895 For this reason, algorithms that are considered "broken" as of the 896 date of this Internet-Draft, such as MD5 [RFC6151], are precluded 897 from being valid certspecs. The registration of a particular 898 algorithm spec in this namespace does NOT mean that it is acceptable 899 or safe for every usage, even though this Internet-Draft requires 900 that a conforming implementation MUST implement certain specs. 902 When using content-based certspecs, the implementation MUST be 903 prepared to process strings of arbitrary length. As of this writing, 904 useful certificates rarely exceed 10KB, and most implementations are 905 concerned with keeping certificate sizes down. However, a 906 pathological or malicious certificate could easily exceed these 907 metrics. 909 When using element-based certspecs, the implementation MUST be 910 prepared to deal with multiple found certificates that contain the 911 same certificate data, but are not the same certificate. In such a 912 case, the implementation MUST segregate these certificates so that 913 the implementation only continues with certificates that it considers 914 valid or trustworthy (as discussed further below). If, despite this 915 segregation, multiple valid or trustworthy certificates match the 916 certspec, the certspec (not in a multispec) MUST be rejected, because 917 a certspec is meant to identify exactly one certificate (not a family 918 of certificates). 920 Certificates identified by certspecs should only be used with an 921 analysis of their validity, such as by computing the Certification 922 Path Validation Algorithm (Section 6 of [RFC5280]) or by other means. 923 For example, if a certificate database contains a set of certificates 924 that it considers inherently trustworthy, then the inclusion of a 925 certificate in that set makes it trustworthy, regardless of the 926 results of the Certification Path Validation Algorithm. Such a 927 database is frequently used for "Root CA" lists. 929 14. References 931 14.1. Normative References 933 [LDAPDESC] 934 IANA, "LDAP Parameters: Object Identifier Descriptors", 935 . 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, March 1997. 941 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 942 Infrastructure Operational Protocols: FTP and HTTP", RFC 943 2585, May 1999. 945 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 946 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 947 . 949 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 950 Resource Identifier (URI): Generic Syntax", STD 66, RFC 951 3986, January 2005. 953 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 954 (LDAP): Directory Information Models", RFC 4512, June 955 2006. 957 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 958 (LDAP): String Representation of Distinguished Names", RFC 959 4514, June 2006. 961 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 962 Syntaxes and Matching Rules", RFC 4517, June 2006. 964 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 965 Considerations for the Lightweight Directory Access 966 Protocol (LDAP)", BCP 64, RFC 4520, DOI 10.17487/RFC4520, 967 June 2006, . 969 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 970 Encodings", RFC 4648, October 2006. 972 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 973 Specifications: ABNF", STD 68, RFC 5234, January 2008. 975 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 976 Housley, R., and W. Polk, "Internet X.509 Public Key 977 Infrastructure Certificate and Certificate Revocation List 978 (CRL) Profile", RFC 5280, May 2008. 980 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 981 Mail Extensions (S/MIME) Version 3.2 Certificate 982 Handling", RFC 5750, January 2010. 984 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 985 Attribute Certificate Profile for Authorization", RFC 986 5755, January 2010. 988 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 989 and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/ 990 RFC6570, March 2012, 991 . 993 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 994 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 995 April 2015, . 997 [SHS] National Institute of Standards and Technology, "Secure 998 Hash Standard", Federal Information Processing Standard 999 (FIPS) 180-4, March 2012, 1000 . 1003 14.2. Informative References 1005 [I-D.ietf-urnbis-rfc2141bis-urn] 1006 Saint-Andre, P. and J. Klensin, "Uniform Resource Names 1007 (URNs)", draft-ietf-urnbis-rfc2141bis-urn-16 (work in 1008 progress), April 2016. 1010 [PKCS11] RSA Laboratories, "PKCS #11 v2.30: Cryptographic Token 1011 Interface Standard", PKCS 11, April 2009. 1013 [PROVURI] IANA, "Uniform Resource Identifier (URI) Schemes: 1014 Provisional URI Schemes", 1015 . 1018 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1019 Mail: Part I: Message Encryption and Authentication 1020 Procedures", RFC 1421, February 1993. 1022 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1023 Resource Locators (URL)", RFC 1738, December 1994. 1025 [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 1026 Access Protocol (v3): UTF-8 String Representation of 1027 Distinguished Names", RFC 2253, December 1997. 1029 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1030 Classes and Attribute Types Version 2.0", RFC 2985, 1031 November 2000. 1033 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 1034 Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 1035 2006. 1037 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1038 RFC 5652, September 2009. 1040 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1041 2010. 1043 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 1044 URI Scheme", RFC 6068, October 2010. 1046 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1047 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1048 RFC 6151, March 2011. 1050 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1051 Keranen, A., and P. Hallam-Baker, "Naming Things with 1052 Hashes", RFC 6920, April 2013. 1054 [RFC7292] Moriarty, K., Nystrom, M., Parkinson, S., Rusch, A., and 1055 M. Scott, "PKCS #12: Personal Information Exchange Syntax 1056 v1.1", RFC 7292, July 2014. 1058 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 1059 8.0.0", ISBN 978-1-936213-10-8, August 2015. 1061 Mountain View, CA: The Unicode Consortium. 1063 [X.680] International Telecommunications Union, "Abstract Syntax 1064 Notation One (ASN.1): Specification of basic notation", 1065 ITU-T Recommendation X.680, August 2015, . 1068 [X.690] International Telecommunications Union, "ASN.1 encoding 1069 rules: Specification of basic encoding Rules (BER), 1070 Canonical encoding rules (CER) and Distinguished encoding 1071 rules (DER)", ITU-T Recommendation X.690, August 2015, 1072 . 1074 [X.693] International Telecommunications Union, "ASN.1 encoding 1075 rules: XML Encoding Rules (XER)", ITU-T Recommendation 1076 X.693, August 2015, . 1078 Appendix A. [[Omitted]] 1080 [[Omitted in this draft.]] 1082 Appendix B. Mandatory Attribute Descriptors for Distinguished Names 1084 As per [RFC4514], attribute descriptors case-insensitive. A 1085 conformant implementation MUST recognize the attributes in the table 1086 below when parsing certspecs containing distinguished names, both by 1087 the OIDs and by the names recorded in the LDAP Parameters: Object 1088 Identifier Descriptors registry [LDAPDESC]. A conforming generator 1089 SHOULD emit these attribute descriptors in lieu of their dotted 1090 decimal representations. 1092 +----------------------------+-------------------------------+------+ 1093 | OID | Names | RFC | 1094 +----------------------------+-------------------------------+------+ 1095 | 2.5.4.3 | cn (CN) | 4514 | 1096 | | commonName | | 1097 | 2.5.4.7 | l (L) | 4514 | 1098 | | localityName | | 1099 | 2.5.4.8 | st (ST) | 4514 | 1100 | | (S)* | | 1101 | | stateOrProvinceName | | 1102 | 2.5.4.10 | o (O) | 4514 | 1103 | | organizationName | | 1104 | 2.5.4.11 | ou (OU) | 4514 | 1105 | | organizationalUnitName | | 1106 | 2.5.4.6 | c (C) | 4514 | 1107 | | countryName | | 1108 | 2.5.4.9 | street (STREET) | 4514 | 1109 | | streetAddress | | 1110 | 0.9.2342.19200300.100.1.25 | dc (DC) | 4514 | 1111 | | domainComponent | | 1112 | 0.9.2342.19200300.100.1.1 | uid (UID) | 4514 | 1113 | | userId | | 1114 | 2.5.4.5 | serialNumber (SERIALNUMBER) | 5280 | 1115 | 2.5.4.46 | dnQualifier (DNQUALIFIER) | 5280 | 1116 | 2.5.4.4 | sn (SN) | 5280 | 1117 | | surname | | 1118 | 2.5.4.42 | gn (GN)** | 5280 | 1119 | | givenName | | 1120 | 2.5.4.12 | (T)* | 5280 | 1121 | | title | | 1122 | 2.5.4.43 | (I)* | 5280 | 1123 | | initials | | 1124 | 2.5.4.44 | (GENQUALIFIER)* | 5280 | 1125 | | generationQualifier | | 1126 | | (GENERATIONQUALIFIER) | | 1127 | 2.5.4.65 | (PNYM)* | 5280 | 1128 | | pseudonym (PSEUDONYM) | | 1129 | 1.2.840.113549.1.9.1 | (E)* | 5750 | 1130 | | emailAddress | | 1131 | | email | | 1132 +----------------------------+-------------------------------+------+ 1133 Names in parentheses are variations that are not assigned as such in 1134 [LDAPDESC]. Implementations MAY parse these names, but SHOULD NOT 1135 generate them. 1136 Names in ALL-CAPS may be emitted by some certificate-processing 1137 applications; these names are compatible with lowercase or mixed-case 1138 variations due to case-insensitivity. 1139 * Name may appear in some implementations, but is not in [LDAPDESC]. 1140 ** Name commonly appears in implementations, but is RESERVED in 1141 [LDAPDESC]. Conforming implementations MAY generate this name from 1142 2.5.4.42 and MUST parse this name as 2.5.4.42, despite its RESERVED 1143 status. 1145 Table 1: Attribute Descriptors 1147 Appendix C. Recommended Attribute Descriptors for issuersn certspec 1149 As per [RFC4514], attribute descriptors case-insensitive. [[TODO: 1150 complete. Probably date of birth, place of birth, gender, etc. 1151 already defined elsewhere.]] 1153 Appendix D. Algorithm for Distinguishing Between (Public Key) 1154 Certificates and Attribute Certificates 1156 A certspec can identify a (public key) certificate ("PKC") or an 1157 attribute certificate ("AC"). When the type of certificate is 1158 specified unambiguously in the source data, an implementation SHOULD 1159 follow specifier in the source data. However, of the certspecs 1160 listed in this document, only a subset of URIs are capable of 1161 unambiguous specification (e.g., via Internet media type designation 1162 of application/pkix-cert or application/pkix-attr-cert). (The file 1163 extension ought not be considered a reliable indicator of the type.) 1164 Most other certspecs will return a blob of bytes or characters. 1165 Therefore, an implementation needs to implement some content-sniffing 1166 to figure out what the data represents. There are two (not entirely 1167 orthogonal) decisions: is the data textual [RFC7468] or binary (i.e., 1168 DER-encoded), and does the data represent a PKC or AC? (Note: The 1169 data-based certspecs BASE64 and HEX, always represent one DER-encoded 1170 certificate or ContentInfo/SignedData; the encodings MUST NOT encode 1171 a textual blob.) 1173 This appendix provides an informative algorithm that implementations 1174 MAY use to do such content-sniffing. 1176 Ensure that the first octet is SEQUENCE 30h. 1178 If there are 2 elements -> confirm that the first element is OBJECT 1179 IDENTIFIER 1.2.840.113549.1.7.2 and the second element is explicitly 1180 tagged (APPLICATION 0, A0). This is a ContentInfo containing 1181 SignedData. 1183 Otherwise, ensure that there are 3 elements, and that the first 1184 element is a SEQUENCE 30h (either AttributeCertificateInfo or 1185 TBSCertificate). 1187 this SEQUENCE has: 6, 7, or 7+ elements 1189 if 6 elements -> V1 certificate 1191 if 7+ elements -> 1193 look at version filed (first element) 1195 if INTEGER (UNIVERSAL 2), it's an attribute certificate 1197 if explicitly tagged (APPLICATION 0, A0) and the contents are INTEGER 1198 (UNIVERSAL 2), it's a public key certificate. 1200 otherwise -> malformed, not in DER. 1202 *END* 1204 If DER (or DER-like material, i.e., BER that an application chooses 1205 to accept as if it were DER anyway) is found, the complete 1206 certificate SHOULD be the only PDU in the data blob, and SHOULD 1207 occupy the entirety of the data blob. Pathological cases may exist, 1208 however, where data is appended to the end of the blob, that is not 1209 part of the certificate. An implementation has three choices: a) 1210 ignore the data, b) attempt to parse the data for additional 1211 certificates, c) reject the entire data blob as malformed (thus, 1212 rejecting at least the initial identified certificate). c) is valid 1213 behavior. a) depends on the nature of the identification (e.g., if 1214 the certspec is a hash, the application MUST confirm that the hash is 1215 computed over the actual certificate octets, and does not include the 1216 jetsam past the end of the certificate). If b) is attempted, the 1217 implementation MUST verify that the first certificate matches the 1218 identification (see comment on a) ), and that subsequent 1219 certificates, if found, match the identification as well. 1221 If the data blob is found not to contain DER (or DER-like material, 1222 see above), the data may be textual. [RFC7468] outlines the 1223 possibilities of PKIX structures that could be present in such text. 1224 After determining one or more appropriate encoding possibilities, an 1225 implementation MUST scan the entire textual blob and handle the 1226 possibility that multiple certificates might be present. The 1227 implementation MUST NOT stop at parsing the first one, the last one, 1228 or some middle one after it "tires out". Parsers SHOULD [[NB: or 1229 MUST, or MUST NOT??]] treat the label on a textually encoded item as 1230 definitive; therefore, parsers SHOULD NOT need to [[NB: or MUST NOT, 1231 or MUST??]] process all textually encoded items. [[NB: compare with 1232 Content-Type, which this document considers definitive: mislabeled 1233 contents get punished.]] 1235 Author's Address 1237 Sean Leonard 1238 Penango, Inc. 1239 5900 Wilshire Boulevard 1240 21st Floor 1241 Los Angeles, CA 90036 1242 USA 1244 Email: dev+ietf@seantek.com 1245 URI: http://www.penango.com/