idnits 2.17.1 draft-seantek-ldap-pkcs9-01.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 (October 26, 2014) is 3463 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 October 26, 2014 5 Expires: April 29, 2015 7 Lightweight Directory Access Protocol (LDAP) 8 Registrations for PKCS #9 9 draft-seantek-ldap-pkcs9-01.txt 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 14, 2015. 34 Copyright Notice 36 Copyright (c) 2014 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.1. 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.2. 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. General LDAP security 172 considerations [RFC4510] apply as well. 174 7. IANA Considerations 176 The IANA shall register an LDAP Object Identifier [RFC4520] for use 177 in this technical specification, and shall update the LDAP Descriptor 178 registry [RFC4520], as indicated below. 180 7.1. Object Identifier Registration 182 Subject: Request for LDAP OID Registration 183 Person & email address to contact for further information: 184 Sean Leonard 185 Specification: draft-seantek-ldap-pkcs9 186 Author/Change Controller: IESG 187 Comments: 188 Identifies the PKCS #9 schema elements registered in 189 the IANA LDAP Descriptor and Syntaxes registries via 190 this document. 192 7.2. Descriptor Registration 194 Subject: Request for LDAP Descriptor Registration 195 Descriptor (short name): see table 196 Object Identifier: see table 197 Person & email address to contact for further information: 198 Sean Leonard 199 Usage: see table 200 Specification: draft-seantek-ldap-pkcs9 201 Author/Change Controller: IESG 203 pkcsEntity O 1.2.840.113549.1.9.24.1 204 naturalPerson O 1.2.840.113549.1.9.24.2 206 pKCS7PDU A 1.2.840.113549.1.9.25.5 207 userPKCS12 A 2.16.840.1.113730.3.1.216 208 pKCS15Token A 1.2.840.113549.1.9.25.1 209 encryptedPrivateKeyInfo A 1.2.840.113549.1.9.25.2 211 e A 1.2.840.113549.1.9.1 213 unstructuredName A 1.2.840.113549.1.9.2 214 unstructuredAddress A 1.2.840.113549.1.9.8 216 dob A 1.3.6.1.5.5.7.9.1 217 dateOfBirth A 1.3.6.1.5.5.7.9.1 218 pob A 1.3.6.1.5.5.7.9.2 219 placeOfBirth A 1.3.6.1.5.5.7.9.2 220 g A 1.3.6.1.5.5.7.9.3 221 gender A 1.3.6.1.5.5.7.9.3 222 coc A 1.3.6.1.5.5.7.9.4 223 countryOfCitizenship A 1.3.6.1.5.5.7.9.4 224 cor A 1.3.6.1.5.5.7.9.5 225 countryOfResidence A 1.3.6.1.5.5.7.9.5 227 pnym A 2.5.4.65 229 contentType A 1.2.840.113549.1.9.3 230 messageDigest A 1.2.840.113549.1.9.4 231 signingTime A 1.2.840.113549.1.9.5 232 counterSignature A 1.2.840.113549.1.9.6 233 challengePassword A 1.2.840.113549.1.9.7 234 desc A 2.5.4.13 236 pkcs9CaseIgnoreMatch M 1.2.840.113549.1.9.27.1 237 signingTimeMatch M 1.2.840.113549.1.9.27.3 239 7.3. PKCS9String Syntax Registration 241 Subject: Request for LDAP Syntax Registration 242 Object Identifier: 1.2.840.113549.1.9.26.1 243 Description: PKCS9String 244 Person & email address to contact for further information: 245 Sean Leonard 246 Specification: draft-seantek-ldap-pkcs9 247 Author/Change Controller: IESG 248 Comments: 249 Identifies the PKCS #9 String syntax, which is 250 a CHOICE of IA5String and DirectoryString. 252 7.4. SigningTime Syntax Registration 254 Subject: Request for LDAP Syntax Registration 255 Object Identifier: 1.2.840.113549.1.9.26.2 256 Description: SigningTIme 257 Person & email address to contact for further information: 258 Sean Leonard 259 Specification: draft-seantek-ldap-pkcs9 260 Author/Change Controller: IESG 261 Comments: 262 Identifies the SigningTime syntax, which is Time, 263 which is a CHOICE of UTCTime and GeneralizedTime. 265 8. Acknowledgements 267 This document relies on PKCS #9, a product of RSA Laboratories. 269 9. References 271 9.1. Normative References 273 [PKCS9] Nystrom, M. and Kaliski, B., "PKCS #9: Selected Object 274 Classes and Attribute Types Version 2.0", RFC 2985, 275 November 2000. 277 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 278 (LDAP): Technical Specification Road Map", RFC 4510, June 279 2006. 281 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 282 (LDAP): Directory Information Models", RFC 4512, June 283 2006. 285 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 286 Considerations for the Lightweight Directory Access 287 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 289 [X.680] International Telecommunications Union, "Information 290 technology -- Abstract Syntax Notation One (ASN.1): 291 Specification of basic notation", ITU-T Recommendation 292 X.680, November 2008. 294 9.2. Informative References 296 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 297 Public Key Infrastructure: Qualified Certificates 298 Profile", RFC 3739, March 2004. 300 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 301 Housley, R., and W. Polk, "Internet X.509 Public Key 302 Infrastructure Certificate and Certificate Revocation List 303 (CRL) Profile", RFC 5280, May 2008. 305 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 306 Mail Extensions (S/MIME) Version 3.2 Certificate 307 Handling", RFC 5750, January 2010. 309 Author's Address 311 Sean Leonard 312 Penango, Inc. 313 5900 Wilshire Boulevard 314 21st Floor 315 Los Angeles, CA 90036 316 USA 318 EMail: dev+ietf@seantek.com 319 URI: http://www.penango.com/