idnits 2.17.1 draft-seantek-ldap-pkcs9-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 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 (July 19, 2016) is 2838 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 July 19, 2016 5 Expires: January 20, 2017 7 Lightweight Directory Access Protocol (LDAP) 8 Registrations for PKCS #9 9 draft-seantek-ldap-pkcs9-06 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 January 20, 2017. 34 Copyright Notice 36 Copyright (c) 2016 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 As the elements and their semantics are defined in [PKCS#9], this 57 document needs to be read in conjunction with [PKCS#9] to make use of 58 the LDAP registrations provided herein. [PKCS#9] provides complete 59 definitions, with one significant omission: the IANA Considerations 60 section was never appended. This document provides the IANA 61 Considerations section necessary to register appropriate descriptors. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [BCP14]. 67 2. Syntaxes 69 Appendix B.1 of [PKCS#9] describes various syntaxes used in LDAP to 70 transfer PKCS #9 elements and related data types. 72 3. Matching Rules 74 Appendix B.4 of [PKCS#9] provides matching rules for use in LDAP. 76 4. Attribute Types 78 Appendix B.3 of [PKCS#9] details attribute types for use in LDAP, 79 including (by its own admission) attributes that are highly unlikely 80 to be stored in a Directory. The attributes in Appendix B.3 that are 81 not highly unlikely to be stored in a Directory are registered via 82 this document. 84 [PKCS#9] includes certain attribute types that have found meaningful 85 use outside of the PKCS series. Specifically: 87 o emailAddress is mandated in [SMIMEv3.2C], and has mandatory 88 processing requirements if included in a certificate 89 [PKIXPROF]. 90 o [PKIXPROF] recommends the recognition of pseudonym. 91 o The Qualified Certificates Profile [QCPROF] requires both 92 pseudonym and the vital records dateOfBirth, placeOfBirth, 93 gender, countryOfCitizenship, and countryOfResidence. 94 o "DESC" is sometimes emitted for the description (2.5.4.13) 95 attribute. 97 As a result, certain applications not only encounter and generate 98 these attributes in practice, but also use short descriptors that 99 have come to be widely recognized. 101 Implementations SHOULD also note that "gn" is a common descriptor for 102 "givenName" (2.5.4.42), and is widely emitted by cryptographic 103 applications. 105 4.1. Semantics of dateOfBirth Clarified 107 [PKCS#9] Section 5.2.4 states that dateOfBirth "is the date of birth 108 for the subject it is associated with." Its GeneralizedTime syntax, 109 however, requires time and time zone specifications that are not 110 related to dateOfBirth's semantics. 112 [QCPROF] RECOMMENDS that the time recorded be GMT (i.e., UTC) noon 113 down to the granularity of seconds "in order to prevent accidental 114 change of date due to time zone adjustments." Since contemporary time 115 zones range from -1200 to +1400, however, naive processing will 116 misinterpret this value by one day for timezones significantly ahead 117 of UTC. 119 Since all specifications are under the change control of the IETF, 120 the semantics of dateOfBirth are hereby defined: in dateOfBirth, only 121 the date is meaningful. Parsers that need to convert the 122 GeneralizedTime value to a specific point in time MUST decode the 123 date in the UTC timezone to avoid shifting of the date due to 124 timezone differences (such as in +14). Thus, a subject born in 125 GMT+1400 will have a GeneralizedTime value that is essentially one 126 day ahead (2am), when interpreted literally. 128 When stored in LDAP, a conformant implementation MAY record this 129 value in UTC or in local time, but MUST NOT record this value with a 130 timezone offset. I.e., [X.680] subclauses 46.2 a) and b) and 46.3 a) 131 and b) are acceptable; subclauses 46.2 c) and 46.3 c) are not 132 acceptable. When comparing such values, "local time" values SHALL be 133 compared as if the local time is UTC. 135 The following sentence of [QCPROF] Section 3.2.2 remains in effect 136 for both certificate and non-certificate uses: "Compliant 137 [certificate] [sic] parsing applications SHOULD ignore any time data 138 and just present the contained date without any time zone 139 adjustments." 141 4.2. Short Descriptors for Certain Useful Attribute Types 143 As permitted by Section 3.4 of [LDAPIANA], the short descriptors in 144 Table 1 are registered along with their more verbose counterparts 145 reflected in [PKCS#9]: 147 Short Descriptor Regular Descriptor 148 --------------------------------------- 149 e emailAddress 150 dob dateOfBirth 151 pob placeOfBirth 152 g gender 153 coc countryOfCitizenship 154 cor countryOfResidence 155 pnym pseudonym 157 Table 1: Short Descriptors for Certain Attribute Types 159 4.3. Short Descriptors for Certain Other Attribute Types 161 As permitted by Section 3.4 of [LDAPIANA], the short descriptors in 162 Table 2 are registered along with their more verbose counterparts 163 elsewhere: 165 Short Descriptor Regular Descriptor 166 --------------------------------------- 167 desc description 169 Table 2: Short Descriptors for Certain Attribute Types 171 5. Object Classes 173 Appendix B.2 of [PKCS#9] details a set of object classes for use in 174 LDAP. 176 6. Security Considerations 178 PKCS #9 security considerations (written for the RFC edition) 179 [PKCS#9] apply to the definitions in this document. LDAP security and 180 privacy considerations in [LDAPMAP] and [LDAPDIM] apply as well. 182 Some attributes such as dateOfBirth and placeOfBirth may be subject 183 to privacy laws in certain jurisdictions. If conveyed with LDAP, 184 these attributes ought to be returned over a protected channel, such 185 as TLS. 187 7. IANA Considerations 189 The IANA shall register an LDAP Object Identifier [LDAPIANA] for use 190 in this technical specification. The IANA shall update the LDAP 191 Descriptor registry [LDAPIANA] with definitions from [PKCS#9] as 192 indicated below. 194 7.1. Object Identifier Registration 196 Subject: Request for LDAP OID Registration 197 Person & email address to contact for further information: 198 Sean Leonard 199 Specification: draft-seantek-ldap-pkcs9 200 Author/Change Controller: IESG 201 Comments: 202 Identifies the PKCS #9 schema elements registered in 203 the IANA LDAP Descriptor and Syntaxes registries via 204 this document. 206 7.2. Descriptor Registration 208 Subject: Request for LDAP Descriptor Registration 209 Descriptor (short name): see table 210 Object Identifier: see table 211 Person & email address to contact for further information: 212 Sean Leonard 213 Usage: see table 214 Specification: draft-seantek-ldap-pkcs9 215 Author/Change Controller: IESG 217 pkcsEntity O 1.2.840.113549.1.9.24.1 218 naturalPerson O 1.2.840.113549.1.9.24.2 220 pKCS7PDU A 1.2.840.113549.1.9.25.5 221 userPKCS12 A 2.16.840.1.113730.3.1.216 222 pKCS15Token A 1.2.840.113549.1.9.25.1 223 encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 225 e A 1.2.840.113549.1.9.1 227 unstructuredName A 1.2.840.113549.1.9.2 228 unstructuredAddress A 1.2.840.113549.1.9.8 230 dob A 1.3.6.1.5.5.7.9.1 231 dateOfBirth A 1.3.6.1.5.5.7.9.1 232 pob A 1.3.6.1.5.5.7.9.2 233 placeOfBirth A 1.3.6.1.5.5.7.9.2 234 g A 1.3.6.1.5.5.7.9.3 235 gender A 1.3.6.1.5.5.7.9.3 236 coc A 1.3.6.1.5.5.7.9.4 237 countryOfCitizenship A 1.3.6.1.5.5.7.9.4 238 cor A 1.3.6.1.5.5.7.9.5 239 countryOfResidence A 1.3.6.1.5.5.7.9.5 241 pnym A 2.5.4.65 242 desc A 2.5.4.13 244 Add a note to the following attributes: 245 This attribute is to be used in PKCS applications 246 (including PKCS #6, PKCS #7/CMS, and PKCS #12). 248 contentType A 1.2.840.113549.1.9.3 249 messageDigest A 1.2.840.113549.1.9.4 250 signingTime A 1.2.840.113549.1.9.5 251 randomNonce A 1.2.840.113549.1.9.25.3 252 sequenceNumber A 1.2.840.113549.1.9.25.4 253 counterSignature A 1.2.840.113549.1.9.6 254 challengePassword A 1.2.840.113549.1.9.7 255 extensionRequest A 1.2.840.113549.1.9.14 256 extendedCertificateAttributes A* 1.2.840.113549.1.9.9 257 friendlyName A 1.2.840.113549.1.9.20 258 localKeyId A 1.2.840.113549.1.9.21 259 signingDescription A 1.2.840.113549.1.9.13 260 smimeCapabilities A 1.2.840.113549.1.9.15 262 pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 263 signingTimeMatch M 1.2.840.113549.1.9.27.3 265 7.3. PKCS9String Syntax Registration 267 Subject: Request for LDAP Syntax Registration 268 Object Identifier: 1.2.840.113549.1.9.26.1 269 Description: PKCS9String 270 Person & email address to contact for further information: 271 Sean Leonard 272 Specification: draft-seantek-ldap-pkcs9 273 Author/Change Controller: IESG 274 Comments: 275 Identifies the PKCS #9 String syntax, which is 276 a CHOICE of IA5String and DirectoryString. 278 7.4. SigningTime Syntax Registration 280 Subject: Request for LDAP Syntax Registration 281 Object Identifier: 1.2.840.113549.1.9.26.2 282 Description: SigningTIme 283 Person & email address to contact for further information: 284 Sean Leonard 285 Specification: draft-seantek-ldap-pkcs9 286 Author/Change Controller: IESG 287 Comments: 288 Identifies the SigningTime syntax, which is Time, 289 which is a CHOICE of UTCTime and GeneralizedTime. 291 8. Acknowledgements 293 This document relies on PKCS #9, a product of RSA Laboratories. 295 9. References 297 9.1. Normative References 299 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [PKCS#9] Nystrom, M. and Kaliski, B., "PKCS #9: Selected Object 303 Classes and Attribute Types Version 2.0", RFC 2985, 304 November 2000. 306 [LDAPMAP] Zeilenga, K., Ed., "Lightweight Directory Access 307 Protocol (LDAP): Technical Specification Road Map", RFC 308 4510, June 2006. 310 [LDAPDIM] Zeilenga, K., "Lightweight Directory Access Protocol 311 (LDAP): Directory Information Models", RFC 4512, June 312 2006. 314 [LDAPIANA] Zeilenga, K., "Internet Assigned Numbers Authority 315 (IANA) Considerations for the Lightweight Directory 316 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 318 [X.680] International Telecommunication Union, "Information 319 technology - Abstract Syntax Notation One (ASN.1): 320 Specification of basic notation", ITU-T Recommendation 321 X.680, ISO/IEC 8824-1, August 2015. 323 9.2. Informative References 325 [QCPROF] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 326 Public Key Infrastructure: Qualified Certificates 327 Profile", RFC 3739, March 2004. 329 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 330 Housley, R., and W. Polk, "Internet X.509 Public Key 331 Infrastructure Certificate and Certificate Revocation 332 List (CRL) Profile", RFC 5280, May 2008. 334 [SMIMEv3.2C] Ramsdell, B. and S. Turner, "Secure/Multipurpose 335 Internet Mail Extensions (S/MIME) Version 3.2 336 Certificate Handling", RFC 5750, January 2010. 338 Author's Address 340 Sean Leonard 341 Penango, Inc. 342 5900 Wilshire Boulevard 343 21st Floor 344 Los Angeles, CA 90036 345 USA 347 EMail: dev+ietf@seantek.com 348 URI: http://www.penango.com/