idnits 2.17.1 draft-seantek-ldap-pkcs9-08.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 2 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 (November 14, 2017) is 2355 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 14, 2017 5 Expires: May 18, 2018 7 Lightweight Directory Access Protocol (LDAP) 8 Registrations for PKCS #9 9 draft-seantek-ldap-pkcs9-08 11 Abstract 13 PKCS #9 includes several useful definitions that are not yet 14 reflected in the LDAP IANA registry. This document adds those 15 definitions to the IANA registry. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute working 24 documents as Internet-Drafts. The list of current Internet-Drafts is 25 at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 18, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document registers the LDAP [LDAPMAP] schema definitions 52 [LDAPDIM] for a subset of elements specified in PKCS #9 [PKCS#9], 53 including attribute types; matching rules and syntaxes to be used 54 with these attribute types; and related object classes. 56 The Public Key Cryptography Standard (PKCS) series is a group of 57 documents originally published by RSA Security, Inc. in the early 58 1990s. These de-facto industry standards specify cryptographic 59 formats and associated operations, such as the mathematical 60 properties of the RSA algorithm and of cryptographic software and 61 hardware modules. Since initial publication, change control of many 62 PKCS documents was transferred to the IETF. 64 [PKCS#9] "Selected Object Classes and Attribute Types" "provides a 65 selection of object classes and attribute types for use in 66 conjunction with public-key cryptography and Lightweight Directory 67 Access Protocol (LDAP) accessible directories." Many of these ASN.1 68 data items are used throughout cryptographic implementations, but 69 standardized names were never put into the IANA LDAP Parameters 70 registry. LDAP parameters are frequently user-visible (for better or 71 for worse) so registering these parameters will improve both 72 interoperability and usability. 74 As the elements and their semantics are defined in [PKCS#9], this 75 document needs to be read in conjunction with [PKCS#9] to make use of 76 the LDAP registrations provided herein. [PKCS#9] provides complete 77 definitions, with one significant omission: the IANA Considerations 78 section was never appended. This document provides the IANA 79 Considerations section necessary to register appropriate descriptors. 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 [BCP14]. 85 2. Syntaxes 87 Appendix B.1 of [PKCS#9] describes various syntaxes used in LDAP to 88 transfer PKCS #9 elements and related data types. 90 3. Matching Rules 92 Appendix B.4 of [PKCS#9] provides matching rules for use in LDAP. 94 4. Attribute Types 96 Appendix B.3 of [PKCS#9] details attribute types for use in LDAP, 97 including (by its own admission) attributes that are "highly 98 unlikely" to be stored in a Directory. This document registers all 99 such attributes en masse. 101 [PKCS#9] includes certain attribute types that have found meaningful 102 use outside of the PKCS series. Specifically: 104 o emailAddress is mandated in [SMIMEv3.2C], and has mandatory 105 processing requirements if included in a certificate 106 [PKIXPROF]. 107 o [PKIXPROF] recommends the recognition of pseudonym. 108 o The Qualified Certificates Profile [QCPROF] requires both 109 pseudonym and the vital records dateOfBirth, placeOfBirth, 110 gender, countryOfCitizenship, and countryOfResidence. 111 o "DESC" is sometimes emitted for the description (2.5.4.13) 112 attribute. 114 As a result, certain applications not only encounter and generate 115 these attributes in practice, but also use short descriptors that 116 have come to be widely recognized. 118 Implementations SHOULD also note that "gn" is a common descriptor for 119 "givenName" (2.5.4.42), and is widely emitted by cryptographic 120 applications. 122 4.1. Semantics of dateOfBirth Clarified 124 [PKCS#9] Section 5.2.4 states that dateOfBirth "is the date of birth 125 for the subject it is associated with." Its GeneralizedTime syntax, 126 however, requires time and time zone specifications that are not 127 related to dateOfBirth's semantics. 129 [QCPROF] RECOMMENDS that the time recorded be GMT (i.e., UTC) noon 130 down to the granularity of seconds "in order to prevent accidental 131 change of date due to time zone adjustments." Since contemporary time 132 zones range from -1200 to +1400, however, naive processing will 133 misinterpret this value by one day for timezones significantly ahead 134 of UTC. 136 The semantics of dateOfBirth are hereby defined: in dateOfBirth, only 137 the date is meaningful. Parsers that need to convert the 138 GeneralizedTime value to a specific point in time MUST decode the 139 date in the UTC timezone to avoid shifting of the date due to 140 timezone differences (such as in +14). Thus, a subject born in 141 GMT+1400 will have a GeneralizedTime value that is essentially one 142 day ahead (2am), when interpreted literally. 144 When stored in LDAP, a conformant implementation MAY record this 145 value in UTC or in local time, but MUST NOT record this value with a 146 timezone offset. I.e., [X.680] subclauses 46.2 a) and b) and 46.3 a) 147 and b) are acceptable; subclauses 46.2 c) and 46.3 c) are not 148 acceptable. When comparing such values, "local time" values SHALL be 149 compared as if the local time is UTC. 151 The following sentence of [QCPROF] Section 3.2.2 remains in effect 152 for both certificate and non-certificate uses: "Compliant 153 [certificate] [sic] parsing applications SHOULD ignore any time data 154 and just present the contained date without any time zone 155 adjustments." 157 4.2. Short Descriptors for Certain Useful Attribute Types 159 As permitted by Section 3.4 of [LDAPIANA], the short descriptors in 160 Table 1 are registered along with their more verbose counterparts 161 reflected in [PKCS#9]: 163 Short Descriptor Regular Descriptor 164 --------------------------------------- 165 e emailAddress 166 dob dateOfBirth 167 pob placeOfBirth 168 g gender 169 coc countryOfCitizenship 170 cor countryOfResidence 171 pnym pseudonym 173 Table 1: Short Descriptors for Certain Attribute Types 175 4.3. Short Descriptors for Certain Other Attribute Types 177 As permitted by Section 3.4 of [LDAPIANA], the short descriptors in 178 Table 2 are registered along with their more verbose counterparts 179 elsewhere: 181 Short Descriptor Regular Descriptor 182 --------------------------------------- 183 desc description 185 Table 2: Short Descriptors for Certain Attribute Types 187 5. Object Classes 189 Appendix B.2 of [PKCS#9] details a set of object classes for use in 190 LDAP. 192 6. Security Considerations 193 PKCS #9 security considerations (written for the RFC edition) 194 [PKCS#9] apply to the definitions in this document. LDAP security and 195 privacy considerations in [LDAPMAP] and [LDAPDIM] apply as well. 197 Some attributes such as those in [QCPROF], namely dateOfBirth, 198 placeOfBirth, gender, countryOfCitizenship, and countryOfResidence 199 are sensitive and may be subject to privacy laws in certain 200 jurisdictions. If conveyed with LDAP, these attributes ought to be 201 returned over a protected channel, such as TLS. 203 7. IANA Considerations 205 The IANA shall register an LDAP Object Identifier [LDAPIANA] for use 206 in this technical specification. The IANA shall update the LDAP 207 Descriptor registry [LDAPIANA] with definitions from [PKCS#9] as 208 indicated below. 210 7.1. Object Identifier Registration 212 Subject: Request for LDAP OID Registration 213 Person & email address to contact for further information: 214 Sean Leonard 215 Specification: draft-seantek-ldap-pkcs9 216 Author/Change Controller: IESG 217 Comments: 218 Identifies the PKCS #9 schema elements registered in 219 the IANA LDAP Descriptor and Syntaxes registries via 220 this document. 222 7.2. Descriptor Registration 224 Subject: Request for LDAP Descriptor Registration 225 Descriptor (short name): see table 226 Object Identifier: see table 227 Person & email address to contact for further information: 228 Sean Leonard 229 Usage: see table 230 Specification: draft-seantek-ldap-pkcs9 231 Author/Change Controller: IESG 233 pkcsEntity O 1.2.840.113549.1.9.24.1 234 naturalPerson O 1.2.840.113549.1.9.24.2 236 pKCS7PDU A 1.2.840.113549.1.9.25.5 237 userPKCS12 A 2.16.840.1.113730.3.1.216 238 pKCS15Token A 1.2.840.113549.1.9.25.1 239 encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 240 e A 1.2.840.113549.1.9.1 242 unstructuredName A 1.2.840.113549.1.9.2 243 unstructuredAddress A 1.2.840.113549.1.9.8 245 dob A 1.3.6.1.5.5.7.9.1 246 dateOfBirth A 1.3.6.1.5.5.7.9.1 247 pob A 1.3.6.1.5.5.7.9.2 248 placeOfBirth A 1.3.6.1.5.5.7.9.2 249 g A 1.3.6.1.5.5.7.9.3 250 gender A 1.3.6.1.5.5.7.9.3 251 coc A 1.3.6.1.5.5.7.9.4 252 countryOfCitizenship A 1.3.6.1.5.5.7.9.4 253 cor A 1.3.6.1.5.5.7.9.5 254 countryOfResidence A 1.3.6.1.5.5.7.9.5 256 pnym A 2.5.4.65 258 desc A 2.5.4.13 260 Add a note to the following attributes: 261 This attribute is to be used in PKCS applications 262 (including PKCS #6, PKCS #7/CMS, and PKCS #12). 264 contentType A 1.2.840.113549.1.9.3 265 messageDigest A 1.2.840.113549.1.9.4 266 signingTime A 1.2.840.113549.1.9.5 267 randomNonce A 1.2.840.113549.1.9.25.3 268 sequenceNumber A 1.2.840.113549.1.9.25.4 269 counterSignature A 1.2.840.113549.1.9.6 270 challengePassword A 1.2.840.113549.1.9.7 271 extensionRequest A 1.2.840.113549.1.9.14 272 extendedCertificateAttributes A* 1.2.840.113549.1.9.9 273 friendlyName A 1.2.840.113549.1.9.20 274 localKeyId A 1.2.840.113549.1.9.21 275 signingDescription A 1.2.840.113549.1.9.13 276 smimeCapabilities A 1.2.840.113549.1.9.15 278 pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 279 signingTimeMatch M 1.2.840.113549.1.9.27.3 281 7.3. PKCS9String Syntax Registration 283 Subject: Request for LDAP Syntax Registration 284 Object Identifier: 1.2.840.113549.1.9.26.1 285 Description: PKCS9String 286 Person & email address to contact for further information: 287 Sean Leonard 288 Specification: draft-seantek-ldap-pkcs9 289 Author/Change Controller: IESG 290 Comments: 291 Identifies the PKCS #9 String syntax, which is 292 a CHOICE of IA5String and DirectoryString. 294 7.4. SigningTime Syntax Registration 296 Subject: Request for LDAP Syntax Registration 297 Object Identifier: 1.2.840.113549.1.9.26.2 298 Description: SigningTIme 299 Person & email address to contact for further information: 300 Sean Leonard 301 Specification: draft-seantek-ldap-pkcs9 302 Author/Change Controller: IESG 303 Comments: 304 Identifies the SigningTime syntax, which is Time, 305 which is a CHOICE of UTCTime and GeneralizedTime. 307 8. Acknowledgements 309 This document relies on PKCS #9, a product of RSA Laboratories. 311 9. References 313 9.1. Normative References 315 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [PKCS#9] Nystrom, M. and Kaliski, B., "PKCS #9: Selected Object 319 Classes and Attribute Types Version 2.0", RFC 2985, 320 November 2000. 322 [LDAPMAP] Zeilenga, K., Ed., "Lightweight Directory Access 323 Protocol (LDAP): Technical Specification Road Map", RFC 324 4510, June 2006. 326 [LDAPDIM] Zeilenga, K., "Lightweight Directory Access Protocol 327 (LDAP): Directory Information Models", RFC 4512, June 328 2006. 330 [LDAPIANA] Zeilenga, K., "Internet Assigned Numbers Authority 331 (IANA) Considerations for the Lightweight Directory 332 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 334 [X.680] International Telecommunication Union, "Information 335 technology - Abstract Syntax Notation One (ASN.1): 336 Specification of basic notation", ITU-T Recommendation 337 X.680, ISO/IEC 8824-1, August 2015. 339 9.2. Informative References 341 [QCPROF] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 342 Public Key Infrastructure: Qualified Certificates 343 Profile", RFC 3739, March 2004. 345 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 346 Housley, R., and W. Polk, "Internet X.509 Public Key 347 Infrastructure Certificate and Certificate Revocation 348 List (CRL) Profile", RFC 5280, May 2008. 350 [SMIMEv3.2C] Ramsdell, B. and S. Turner, "Secure/Multipurpose 351 Internet Mail Extensions (S/MIME) Version 3.2 352 Certificate Handling", RFC 5750, January 2010. 354 Author's Address 356 Sean Leonard 357 Penango, Inc. 358 5900 Wilshire Blvd 359 Ste 2600 360 Los Angeles, CA 90036 361 USA 363 EMail: dev+ietf@seantek.com 364 URI: http://www.penango.com/