idnits 2.17.1 draft-seantek-ldap-pkcs9-03.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '...specific point in time MUST decode the...' RFC 2119 keyword, line 119: '...formant implementation MAY record this...' RFC 2119 keyword, line 120: '... local time, but MUST NOT record this ...' RFC 2119 keyword, line 124: '...cal time" values SHALL be compared as ...' RFC 2119 keyword, line 129: '...ing applications SHOULD ignore any tim...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2015) is 3123 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended Status: Informational September 9, 2015 5 Expires: March 12, 2016 7 Lightweight Directory Access Protocol (LDAP) 8 Registrations for PKCS #9 9 draft-seantek-ldap-pkcs9-03 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 March 12, 2016. 34 Copyright Notice 36 Copyright (c) 2015 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 [RFC4510] schema definitions 52 [RFC4512] for a subset of elements specified in PKCS #9 [PKCS9], 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 [PKCS9], this 57 document needs to be read in conjunction with [PKCS9] to make use of 58 the LDAP registrations provided herein. [PKCS9] 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 2. Syntaxes 65 Appendix B.1 of [PKCS9] describes various syntaxes used in LDAP to 66 transfer PKCS #9 elements and related data types. 68 3. Matching Rules 70 Appendix B.4 of [PKCS9] provides matching rules for use in LDAP. 72 4. Attribute Types 74 Appendix B.3 of [PKCS9] details attribute types for use in LDAP, 75 including (by its own admission) attributes that are highly unlikely 76 to be stored in a Directory. For parity, all attributes in Appendix 77 B.3--but not necessarily in PKCS #9 as a whole--are registered via 78 this document. 80 [PKCS9] includes certain attribute types that have found meaningful 81 use outside of the PKCS series. Specifically: 83 o emailAddress is mandated in [RFC5750], and has mandatory 84 processing requirements if included in a certificate [RFC5280]. 85 o [RFC5280] recommends the recognition of pseudonym. 86 o The Qualified Certificates Profile [RFC3739] requires both 87 pseudonym and the vital records dateOfBirth, placeOfBirth, 88 gender, countryOfCitizenship, and countryOfResidence. 89 o "DESC" is sometimes emitted for the description (2.5.4.13) 90 attribute. 92 As a result, certain applications not only encounter and generate 93 these attributes in practice, but also use short descriptors that 94 have come to be widely recognized. 96 4.1. Semantics of dateOfBirth Clarified 98 [PKCS9] Section 5.2.4 states that dateOfBirth "is the date of birth 99 for the subject it is associated with." Its GeneralizedTime syntax, 100 however, requires time and time zone specifications that are not 101 related to dateOfBirth's semantics. 103 [RFC3739] RECOMMENDS that the time recorded be GMT (i.e., UTC) noon 104 down to the granularity of seconds "in order to prevent accidental 105 change of date due to time zone adjustments." Since contemporary time 106 zones range from -1200 to +1400, however, naive processing will 107 misinterpret this value by one day for timezones significantly ahead 108 of UTC. 110 Since all specifications are under the change control of the IETF, 111 the semantics of dateOfBirth are hereby defined: in dateOfBirth, only 112 the date is meaningful. Parsers that need to convert the 113 GeneralizedTime value to a specific point in time MUST decode the 114 date in the UTC timezone to avoid shifting of the date due to 115 timezone differences (such as in +14). Thus, a subject born in 116 GMT+1400 will have a GeneralizedTime value that is essentially one 117 day ahead (2am), when interpreted literally. 119 When stored in LDAP, a conformant implementation MAY record this 120 value in UTC or in local time, but MUST NOT record this value with a 121 timezone offset. I.e., [X.680] subclauses 46.2 a) and b) and 46.3 a) 122 and b) are acceptable; subclauses 46.2 c) and 46.3 c) are not 123 acceptable. [[TODO: get consensus on this.]] When comparing such 124 values, "local time" values SHALL be compared as if the local time is 125 UTC. 127 The following sentence of [RFC3739] Section 3.2.2 remains in effect 128 for both certificate and non-certificate uses: "Compliant 129 [certificate] [sic] parsing applications SHOULD ignore any time data 130 and just present the contained date without any time zone 131 adjustments." 133 4.2. Short Descriptors for Certain Useful Attribute Types 135 As permitted by Section 3.4 of [RFC4520], the short descriptors in 136 Table 1 are registered along with their more verbose counterparts 137 reflected in [PKCS9]: 139 Short Descriptor Regular Descriptor 140 --------------------------------------- 141 e emailAddress 142 dob dateOfBirth 143 pob placeOfBirth 144 g gender 145 coc countryOfCitizenship 146 cor countryOfResidence 147 pnym pseudonym 149 Table 1: Short Descriptors for Certain Attribute Types 151 4.3. Short Descriptors for Certain Other Attribute Types 153 As permitted by Section 3.4 of [RFC4520], the short descriptors in 154 Table 2 are registered along with their more verbose counterparts 155 elsewhere: 157 Short Descriptor Regular Descriptor 158 --------------------------------------- 159 desc description 161 Table 2: Short Descriptors for Certain Attribute Types 163 5. Object Classes 165 Appendix B.2 of [PKCS9] details a set of object classes for use in 166 LDAP. 168 6. Security Considerations 170 PKCS #9 security considerations (written for the RFC edition) [PKCS9] 171 apply to the definitions in this document. LDAP security and privacy 172 considerations in [RFC4510] and [RFC4512] apply as well. 174 Some attributes such as dateOfBirth and placeOfBirth may be subject 175 to privacy laws in certain jurisdictions. If conveyed with LDAP, 176 these attributes ought to be returned over a protected channel, such 177 as TLS. 179 7. IANA Considerations 181 The IANA shall register an LDAP Object Identifier [RFC4520] for use 182 in this technical specification, and shall update the LDAP Descriptor 183 registry [RFC4520], as indicated below. 185 7.1. Object Identifier Registration 186 Subject: Request for LDAP OID Registration 187 Person & email address to contact for further information: 188 Sean Leonard 189 Specification: draft-seantek-ldap-pkcs9 190 Author/Change Controller: IESG 191 Comments: 192 Identifies the PKCS #9 schema elements registered in 193 the IANA LDAP Descriptor and Syntaxes registries via 194 this document. 196 7.2. Descriptor Registration 198 Subject: Request for LDAP Descriptor Registration 199 Descriptor (short name): see table 200 Object Identifier: see table 201 Person & email address to contact for further information: 202 Sean Leonard 203 Usage: see table 204 Specification: draft-seantek-ldap-pkcs9 205 Author/Change Controller: IESG 207 pkcsEntity O 1.2.840.113549.1.9.24.1 208 naturalPerson O 1.2.840.113549.1.9.24.2 210 pKCS7PDU A 1.2.840.113549.1.9.25.5 211 userPKCS12 A 2.16.840.1.113730.3.1.216 212 pKCS15Token A 1.2.840.113549.1.9.25.1 213 encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 215 e A 1.2.840.113549.1.9.1 217 unstructuredName A 1.2.840.113549.1.9.2 218 unstructuredAddress A 1.2.840.113549.1.9.8 220 dob A 1.3.6.1.5.5.7.9.1 221 dateOfBirth A 1.3.6.1.5.5.7.9.1 222 pob A 1.3.6.1.5.5.7.9.2 223 placeOfBirth A 1.3.6.1.5.5.7.9.2 224 g A 1.3.6.1.5.5.7.9.3 225 gender A 1.3.6.1.5.5.7.9.3 226 coc A 1.3.6.1.5.5.7.9.4 227 countryOfCitizenship A 1.3.6.1.5.5.7.9.4 228 cor A 1.3.6.1.5.5.7.9.5 229 countryOfResidence A 1.3.6.1.5.5.7.9.5 231 pnym A 2.5.4.65 233 contentType A 1.2.840.113549.1.9.3 234 messageDigest A 1.2.840.113549.1.9.4 235 signingTime A 1.2.840.113549.1.9.5 236 counterSignature A 1.2.840.113549.1.9.6 237 challengePassword A 1.2.840.113549.1.9.7 239 desc A 2.5.4.13 241 pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 242 signingTimeMatch M 1.2.840.113549.1.9.27.3 244 7.3. PKCS9String Syntax Registration 246 Subject: Request for LDAP Syntax Registration 247 Object Identifier: 1.2.840.113549.1.9.26.1 248 Description: PKCS9String 249 Person & email address to contact for further information: 250 Sean Leonard 251 Specification: draft-seantek-ldap-pkcs9 252 Author/Change Controller: IESG 253 Comments: 254 Identifies the PKCS #9 String syntax, which is 255 a CHOICE of IA5String and DirectoryString. 257 7.4. SigningTime Syntax Registration 259 Subject: Request for LDAP Syntax Registration 260 Object Identifier: 1.2.840.113549.1.9.26.2 261 Description: SigningTIme 262 Person & email address to contact for further information: 263 Sean Leonard 264 Specification: draft-seantek-ldap-pkcs9 265 Author/Change Controller: IESG 266 Comments: 267 Identifies the SigningTime syntax, which is Time, 268 which is a CHOICE of UTCTime and GeneralizedTime. 270 8. Acknowledgements 272 This document relies on PKCS #9, a product of RSA Laboratories. 274 9. References 276 9.1. Normative References 278 [PKCS9] Nystrom, M. and Kaliski, B., "PKCS #9: Selected Object 279 Classes and Attribute Types Version 2.0", RFC 2985, 280 November 2000. 282 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 283 (LDAP): Technical Specification Road Map", RFC 4510, June 284 2006. 286 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 287 (LDAP): Directory Information Models", RFC 4512, June 288 2006. 290 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 291 Considerations for the Lightweight Directory Access 292 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 294 [X.680] International Telecommunications Union, "Information 295 technology -- Abstract Syntax Notation One (ASN.1): 296 Specification of basic notation", ITU-T Recommendation 297 X.680, November 2008. 299 9.2. Informative References 301 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 302 Public Key Infrastructure: Qualified Certificates 303 Profile", RFC 3739, March 2004. 305 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 306 Housley, R., and W. Polk, "Internet X.509 Public Key 307 Infrastructure Certificate and Certificate Revocation List 308 (CRL) Profile", RFC 5280, May 2008. 310 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 311 Mail Extensions (S/MIME) Version 3.2 Certificate 312 Handling", RFC 5750, January 2010. 314 Appendix A. Acknowledgement of Non-Publication Proposal 316 This draft-03 is virtually unchanged from draft-02. However, the 317 prior Expert Reviewer for draft-02 privately suggested that the 318 descriptors of [PKCS9] could be registered per [RFC4520] without 319 publishing an RFC. This appendix acknowledges this possibility. 321 Author's Address 323 Sean Leonard 324 Penango, Inc. 325 5900 Wilshire Boulevard 326 21st Floor 327 Los Angeles, CA 90036 328 USA 330 EMail: dev+ietf@seantek.com 331 URI: http://www.penango.com/