idnits 2.17.1 draft-seantek-ldap-pkcs9-05.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. -- The draft header indicates that this document updates RFC4520, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4520, updated by this document, for RFC5378 checks: 2003-06-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2016) is 2862 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5750 (Obsoleted by RFC 8550) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Updates: 4520 (if approved) June 24, 2016 5 Intended Status: Informational 6 Expires: December 26, 2016 8 Lightweight Directory Access Protocol (LDAP) 9 Registrations for PKCS #9 10 draft-seantek-ldap-pkcs9-05 12 Abstract 14 PKCS #9 includes several useful definitions that are not yet 15 reflected in the LDAP IANA registry. This document adds those 16 definitions to the IANA registry. 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 working 25 documents as Internet-Drafts. The list of current Internet-Drafts is 26 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 26, 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 1. Introduction 52 This document registers the LDAP [RFC4510] schema definitions 53 [RFC4512] for a subset of elements specified in PKCS #9 [PKCS9], 54 including attribute types; matching rules and syntaxes to be used 55 with these attribute types; and related object classes. 57 As the elements and their semantics are defined in [PKCS9], this 58 document needs to be read in conjunction with [PKCS9] to make use of 59 the LDAP registrations provided herein. [PKCS9] provides complete 60 definitions, with one significant omission: the IANA Considerations 61 section was never appended. This document provides the IANA 62 Considerations section necessary to register appropriate descriptors. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [BCP14]. 68 2. Syntaxes 70 Appendix B.1 of [PKCS9] describes various syntaxes used in LDAP to 71 transfer PKCS #9 elements and related data types. 73 3. Matching Rules 75 Appendix B.4 of [PKCS9] provides matching rules for use in LDAP. 77 4. Attribute Types 79 Appendix B.3 of [PKCS9] details attribute types for use in LDAP, 80 including (by its own admission) attributes that are highly unlikely 81 to be stored in a Directory. The attributes in Appendix B.3 that are 82 not highly unlikely to be stored in a Directory are registered via 83 this document. 85 [PKCS9] includes certain attribute types that have found meaningful 86 use outside of the PKCS series. Specifically: 88 o emailAddress is mandated in [RFC5750], and has mandatory 89 processing requirements if included in a certificate [RFC5280]. 90 o [RFC5280] recommends the recognition of pseudonym. 91 o The Qualified Certificates Profile [RFC3739] 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 4.1. Semantics of dateOfBirth Clarified 103 [PKCS9] Section 5.2.4 states that dateOfBirth "is the date of birth 104 for the subject it is associated with." Its GeneralizedTime syntax, 105 however, requires time and time zone specifications that are not 106 related to dateOfBirth's semantics. 108 [RFC3739] RECOMMENDS that the time recorded be GMT (i.e., UTC) noon 109 down to the granularity of seconds "in order to prevent accidental 110 change of date due to time zone adjustments." Since contemporary time 111 zones range from -1200 to +1400, however, naive processing will 112 misinterpret this value by one day for timezones significantly ahead 113 of UTC. 115 Since all specifications are under the change control of the IETF, 116 the semantics of dateOfBirth are hereby defined: in dateOfBirth, only 117 the date is meaningful. Parsers that need to convert the 118 GeneralizedTime value to a specific point in time MUST decode the 119 date in the UTC timezone to avoid shifting of the date due to 120 timezone differences (such as in +14). Thus, a subject born in 121 GMT+1400 will have a GeneralizedTime value that is essentially one 122 day ahead (2am), when interpreted literally. 124 When stored in LDAP, a conformant implementation MAY record this 125 value in UTC or in local time, but MUST NOT record this value with a 126 timezone offset. I.e., [X.680] subclauses 46.2 a) and b) and 46.3 a) 127 and b) are acceptable; subclauses 46.2 c) and 46.3 c) are not 128 acceptable. [[TODO: get consensus on this.]] When comparing such 129 values, "local time" values SHALL be compared as if the local time is 130 UTC. 132 The following sentence of [RFC3739] Section 3.2.2 remains in effect 133 for both certificate and non-certificate uses: "Compliant 134 [certificate] [sic] parsing applications SHOULD ignore any time data 135 and just present the contained date without any time zone 136 adjustments." 138 4.2. Short Descriptors for Certain Useful Attribute Types 140 As permitted by Section 3.4 of [RFC4520], the short descriptors in 141 Table 1 are registered along with their more verbose counterparts 142 reflected in [PKCS9]: 144 Short Descriptor Regular Descriptor 145 --------------------------------------- 146 e emailAddress 147 dob dateOfBirth 148 pob placeOfBirth 149 g gender 150 coc countryOfCitizenship 151 cor countryOfResidence 152 pnym pseudonym 154 Table 1: Short Descriptors for Certain Attribute Types 156 4.3. Short Descriptors for Certain Other Attribute Types 158 As permitted by Section 3.4 of [RFC4520], the short descriptors in 159 Table 2 are registered along with their more verbose counterparts 160 elsewhere: 162 Short Descriptor Regular Descriptor 163 --------------------------------------- 164 desc description 166 Table 2: Short Descriptors for Certain Attribute Types 168 6. PKCS Attribute Types 170 Security-related applications make use of the Object Identifier 171 Descriptors registry, but these registrations are not likely to be 172 used directly by Directory (LDAP) applications. It is apparent that 173 the descriptors for these applications occupy the same broad 174 namespace, although LDAP-related technologies (including 175 distinguished names, which are used outside of LDAP) have very little 176 use for descriptors used by security applications, and vice-versa. 178 This section modifies the LDAP Descriptor Registration Template 179 (Appendix A.4 of [RFC4520]) to permit an additional Usage: PKCS 180 attribute type. LDAP implementations do not need to recognize these 181 types. Conversely, PKCS (including PKIX and CMS) applications do not 182 need to recognize non-PKCS attribute types when the context calls for 183 PKCS attribute types (e.g., in CMS [RFC5652] and private key 184 [RFC5958] attributes). 186 Generally, the proper way to store PKCS attributes in a directory is 187 to include the attributes within a corresponding PKCS object, and 188 then to store the PKCS object (e.g., PKCS #12 object [RFC7292]) in 189 the appropriate attribute in the pkcsEntity auxiliary object class 190 (Section 4.1 of [PKCS9]). 192 The remaining attributes in [PKCS9] are registered as PKCS attribute 193 types in this document. 195 5. Object Classes 197 Appendix B.2 of [PKCS9] details a set of object classes for use in 198 LDAP. 200 6. Security Considerations 202 PKCS #9 security considerations (written for the RFC edition) [PKCS9] 203 apply to the definitions in this document. LDAP security and privacy 204 considerations in [RFC4510] and [RFC4512] apply as well. 206 Some attributes such as dateOfBirth and placeOfBirth may be subject 207 to privacy laws in certain jurisdictions. If conveyed with LDAP, 208 these attributes ought to be returned over a protected channel, such 209 as TLS. 211 7. IANA Considerations 213 The IANA shall register an LDAP Object Identifier [RFC4520] for use 214 in this technical specification. The IANA shall update the Note in 215 the LDAP Descriptor registry [RFC4520] to include the new usage PKCS 216 Attribute Type, with symbol P. The IANA shall update the LDAP 217 Descriptor registry [RFC4520] with definitions from [PKCS9] as 218 indicated below. 220 7.1. Object Identifier Registration 222 Subject: Request for LDAP OID Registration 223 Person & email address to contact for further information: 224 Sean Leonard 225 Specification: draft-seantek-ldap-pkcs9 226 Author/Change Controller: IESG 227 Comments: 228 Identifies the PKCS #9 schema elements registered in 229 the IANA LDAP Descriptor and Syntaxes registries via 230 this document. 232 7.2. Descriptor Registration 234 Subject: Request for LDAP Descriptor Registration 235 Descriptor (short name): see table 236 Object Identifier: see table 237 Person & email address to contact for further information: 238 Sean Leonard 239 Usage: see table 240 Specification: draft-seantek-ldap-pkcs9 241 Author/Change Controller: IESG 243 pkcsEntity O 1.2.840.113549.1.9.24.1 244 naturalPerson O 1.2.840.113549.1.9.24.2 246 pKCS7PDU A 1.2.840.113549.1.9.25.5 247 userPKCS12 A 2.16.840.1.113730.3.1.216 248 pKCS15Token A 1.2.840.113549.1.9.25.1 249 encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 251 e A 1.2.840.113549.1.9.1 253 unstructuredName A 1.2.840.113549.1.9.2 254 unstructuredAddress A 1.2.840.113549.1.9.8 256 dob A 1.3.6.1.5.5.7.9.1 257 dateOfBirth A 1.3.6.1.5.5.7.9.1 258 pob A 1.3.6.1.5.5.7.9.2 259 placeOfBirth A 1.3.6.1.5.5.7.9.2 260 g A 1.3.6.1.5.5.7.9.3 261 gender A 1.3.6.1.5.5.7.9.3 262 coc A 1.3.6.1.5.5.7.9.4 263 countryOfCitizenship A 1.3.6.1.5.5.7.9.4 264 cor A 1.3.6.1.5.5.7.9.5 265 countryOfResidence A 1.3.6.1.5.5.7.9.5 267 pnym A 2.5.4.65 269 desc A 2.5.4.13 271 contentType P 1.2.840.113549.1.9.3 272 messageDigest P 1.2.840.113549.1.9.4 273 signingTime P 1.2.840.113549.1.9.5 274 randomNonce P 1.2.840.113549.1.9.25.3 275 sequenceNumber P 1.2.840.113549.1.9.25.4 276 counterSignature P 1.2.840.113549.1.9.6 277 challengePassword P 1.2.840.113549.1.9.7 278 extensionRequest P 1.2.840.113549.1.9.14 279 extendedCertificateAttributes P* 1.2.840.113549.1.9.9 280 friendlyName P 1.2.840.113549.1.9.20 281 localKeyId P 1.2.840.113549.1.9.21 282 signingDescription P 1.2.840.113549.1.9.13 283 smimeCapabilities P 1.2.840.113549.1.9.15 285 pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 286 signingTimeMatch M 1.2.840.113549.1.9.27.3 288 7.3. PKCS9String Syntax Registration 290 Subject: Request for LDAP Syntax Registration 291 Object Identifier: 1.2.840.113549.1.9.26.1 292 Description: PKCS9String 293 Person & email address to contact for further information: 294 Sean Leonard 295 Specification: draft-seantek-ldap-pkcs9 296 Author/Change Controller: IESG 297 Comments: 298 Identifies the PKCS #9 String syntax, which is 299 a CHOICE of IA5String and DirectoryString. 301 7.4. SigningTime Syntax Registration 303 Subject: Request for LDAP Syntax Registration 304 Object Identifier: 1.2.840.113549.1.9.26.2 305 Description: SigningTIme 306 Person & email address to contact for further information: 307 Sean Leonard 308 Specification: draft-seantek-ldap-pkcs9 309 Author/Change Controller: IESG 310 Comments: 311 Identifies the SigningTime syntax, which is Time, 312 which is a CHOICE of UTCTime and GeneralizedTime. 314 8. Acknowledgements 316 This document relies on PKCS #9, a product of RSA Laboratories. 318 9. References 320 9.1. Normative References 322 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [PKCS9] Nystrom, M. and Kaliski, B., "PKCS #9: Selected Object 326 Classes and Attribute Types Version 2.0", RFC 2985, 327 November 2000. 329 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 330 (LDAP): Technical Specification Road Map", RFC 4510, June 331 2006. 333 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 334 (LDAP): Directory Information Models", RFC 4512, June 335 2006. 337 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 338 Considerations for the Lightweight Directory Access 339 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 341 [X.680] International Telecommunications Union, "Information 342 technology -- Abstract Syntax Notation One (ASN.1): 343 Specification of basic notation", ITU-T Recommendation 344 X.680, November 2008. 346 9.2. Informative References 348 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 349 Public Key Infrastructure: Qualified Certificates 350 Profile", RFC 3739, March 2004. 352 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 353 Housley, R., and W. Polk, "Internet X.509 Public Key 354 Infrastructure Certificate and Certificate Revocation List 355 (CRL) Profile", RFC 5280, May 2008. 357 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 358 RFC 5652, September 2009. 360 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 361 Mail Extensions (S/MIME) Version 3.2 Certificate 362 Handling", RFC 5750, January 2010. 364 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 365 2010. 367 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 368 and M. Scott, "PKCS #12: Personal Information Exchange 369 Syntax v1.1", RFC 7292, July 2014. 371 Author's Address 373 Sean Leonard 374 Penango, Inc. 375 5900 Wilshire Boulevard 376 21st Floor 377 Los Angeles, CA 90036 378 USA 380 EMail: dev+ietf@seantek.com 381 URI: http://www.penango.com/