idnits 2.17.1 draft-ietf-pkix-ipki2opp-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 108 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...-Drafts are ...' == Line 15 has weird spacing: '...ay also distr...' == Line 19 has weird spacing: '... months and ...' == Line 20 has weird spacing: '...iate to use ...' == Line 21 has weird spacing: '...ference mater...' == (103 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 330 == Missing Reference: '0' is mentioned on line 333, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 3' on line 258 == Missing Reference: '7' is mentioned on line 196, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 6' on line 352 == Unused Reference: '1' is defined on line 511, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 514, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 517, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1778 (ref. '2') (Obsoleted by RFC 3494) Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Sharon Boeyen (Entrust) 3 draft-ietf-pkix-ipki2opp-07.txt Tim Howes (Netscape) 4 Expires in 6 months Patrick Richard (Xcert) 5 Updates RFC 1778 March 1998 7 Internet X.509 Public Key Infrastructure 8 Operational Protocols - LDAPv2 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other docu- 20 ments at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in pro- 22 gress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 2. Abstract 32 The protocol described in this document is designed to satisfy some 33 of the operational requirements within the Internet X.509 Public 34 Key Infrastructure (IPKI). Specifically, this document addresses 35 requirements to provide access to Public Key Infrastructure (PKI) 36 repositories for the purposes of retrieving PKI information and 37 managing that same information. The mechanism described in this 38 document is based on the Lightweight Directory Access Protocol 39 (LDAP) v2, defined in RFC 1777, defining a profile of that protocol 40 for use within the IPKI and updates encodings for certificates and 41 revocation lists from RFC 1778. Additional mechanisms addressing 42 PKIX operational requirements are specified in separate documents. 44 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and 45 "MAY" in this document are to be interpreted as described in RFC 46 2119. 48 Please send comments on this document to the ietf-pkix@tandem.com 49 mail list. 51 3. Introduction 53 This specification is part of a multi-part standard for development 54 of a Public Key Infrastructure (PKI) for the Internet. This specif- 55 ication addresses requirements to provide retrieval of X.509 PKI 56 information, including certificates and CRLs from a repository. 57 This specification also addresses requirements to add, delete and 58 modify PKI information in a repository. A profile based on the LDAP 59 version 2 protocol is provided to satisfy these requirements. 61 4. Model 63 The PKI components, as defined in PKIX Part 1, which are involved 64 in PKIX operational protocol interactions include: 66 - End Entities 67 - Certification Authorities (CA) 68 - Repository 70 End entities and CAs using LDAPv2, retrieve PKI information from 71 the repository using a subset of the LDAPv2 protocol. 73 CAs populate the repository with PKI information using a subset of 74 the LDAPv2 protocol. 76 5. Lightweight Directory Access Protocol (LDAP) 78 The following sections examine the retrieval of PKI information 79 from a repository and management of PKI information in a reposi- 80 tory. A profile of the LDAPv2 protocol is defined for providing 81 these services. 83 Section 6 satisfies the requirement to retrieve PKI information (a 84 certificate, CRL, or other information of interest) from an entry 85 in the repository, where the retrieving entity (either an end 86 entity or a CA) has knowledge of the name of the entry. This is 87 termed "repository read". 89 Section 7 satisfies the same requirement as 6 for the situation 90 where the name of the entry is not known, but some other related 91 information which may optionally be used as a filter against candi- 92 date entries in the repository, is known. This is termed "reposi- 93 tory search". 95 Section 8 satisfies the requirement of CAs to add, delete and 96 modify PKI information information (a certificate, CRL, or other 97 information of interest)in the repository. This is termed "reposi- 98 tory modify". 100 The subset of LDAPv2 needed to support each of these functions is 101 described below. Note that the repository search service is a 102 superset of the repository read service in terms of the LDAPv2 103 functionality needed. 105 Note that all tags are implicit by default in the ASN.1 defini- 106 tions that follow. 108 6. LDAP Repository Read 110 To retrieve information from an entry corresponding to the subject 111 or issuer name of a certificate, requires a subset of the following 112 three LDAP operations: 114 BindRequest (and BindResponse) 115 SearchRequest (and SearchResponse) 116 UnbindRequest 118 The subset of each REQUIRED operation is given below. 120 6.1. Bind 122 6.1.1. Bind Request 124 The full LDAP v2 Bind Request is defined in RFC 1777. 126 An application providing a LDAP repository read service MUST imple- 127 ment the following subset of this operation: 129 BindRequest ::= 130 [APPLICATION 0] SEQUENCE { 131 version INTEGER (2), 132 name LDAPDN, -- MUST accept NULL LDAPDN 133 simpleauth [0] OCTET STRING -- MUST accept NULL simple 134 } 136 An application providing a LDAP repository read service MAY imple- 137 ment other aspects of the BindRequest as well. 139 Different services may have different security requirements. Some 140 services may allow anonymous search, others may require authentica- 141 tion. Those services allowing anonymous search may choose only to 142 allow search based on certain criteria and not others. 144 A LDAP repository read service SHOULD implement some level of 145 anonymous search access. A LDAP repository read service MAY imple- 146 ment authenticated search access. 148 6.1.2. Bind Response 150 The full LDAPv2 BindResponse is described in RFC 1777. 152 An application providing a LDAP repository read service MUST imple- 153 ment this entire protocol element, though only the following error 154 codes may be returned from a Bind operation: 156 success (0), 157 operationsError (1), 158 protocolError (2), 159 authMethodNotSupported (7), 160 noSuchObject (32), 161 invalidDNSyntax (34), 162 inappropriateAuthentication (48), 163 invalidCredentials (49), 164 busy (51), 165 unavailable (52), 166 unwillingToPerform (53), 167 other (80) 169 6.2. Search 171 6.2.1. Search Request 173 The full LDAPv2 SearchRequest is defined in RFC 1777. 175 An application providing a LDAP repository read service MUST imple- 176 ment the following subset of the SearchRequest. 178 SearchRequest ::= 179 [APPLICATION 3] SEQUENCE { 180 baseObject LDAPDN, 181 scope ENUMERATED { 182 baseObject (0), 183 }, 184 derefAliases ENUMERATED { 185 neverDerefAliases (0), 186 }, 187 sizeLimit INTEGER (0), 188 timeLimit INTEGER (0), 189 attrsOnly BOOLEAN, -- FALSE only 190 filter Filter, 191 attributes SEQUENCE OF AttributeType 192 } 194 Filter ::= 195 CHOICE { 196 present [7] AttributeType, -- "objectclass" only 197 } 199 This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read" 200 operation: a base object search with a filter testing for the 201 existence of the objectClass attribute. 203 An application providing a LDAP repository read service MAY imple- 204 ment other aspects of the SearchRequest as well. 206 6.2.2. 208 The full LDAPv2 SearchResponse is defined in RFC 1777. 210 An application providing a LDAP repository read service over LDAPv2 211 MUST implement the full SearchResponse. 213 Note that in the case of multivalued attributes such as userCerti- 214 ficate a SearchResponse containing this attribute will include all 215 values, assuming the requester has sufficient access permissions. 216 The application/relying party may need to select an appropriate 217 value to be used. Also note that retrieval of a certificate from a 218 named entry does not guarantee that the certificate will include 219 that same Distinguished Name (DN) and in some cases the subject DN 220 in the certificate may be NULL. 222 6.3. Unbind 224 The full LDAPv2 UnbindRequest is defined in RFC 1777. 226 An application providing a LDAP repository read service MUST imple- 227 ment the full UnbindRequest. 229 7. LDAP Repository Search 231 To search ,using arbitrary criteria, for an entry in a repository 232 containing a certificate, CRL, or other information of interest, 233 requires a subset of the following three LDAP operations: 235 BindRequest (and BindResponse) 236 SearchRequest (and SearchResponse) 237 UnbindRequest 239 The subset of each operation REQUIRED is given below. 241 7.1. Bind 243 The BindRequest and BindResponse subsets needed are the same as 244 those described in Section 6.1. 246 The full LDAP v2 Bind Request is defined in RFC 1777. 248 7.2. Search 250 7.2.1. Search Request 252 The full LDAPv2 SearchRequest is defined in RFC 1777. 254 An application providing a LDAP repository search service MUST 255 implement the following subset of the SearchRequest protocol unit. 257 SearchRequest ::= 258 [APPLICATION 3] SEQUENCE { 259 baseObject LDAPDN, 260 scope ENUMERATED { 261 baseObject (0), 262 singleLevel (1), 263 wholeSubtree (2) 264 }, 265 derefAliases ENUMERATED { 266 neverDerefAliases (0), 267 }, 268 sizeLimit INTEGER (0 .. maxInt), 269 timeLimit INTEGER (0 .. maxInt), 270 attrsOnly BOOLEAN, -- FALSE only 271 filter Filter, 272 attributes SEQUENCE OF AttributeType 273 } 275 All aspects of the SearchRequest MUST be supported, except for the 276 following: 278 - Only the neverDerefAliases value of derefAliases needs 279 to be supported 281 - Only the FALSE value for attrsOnly needs to be supported 283 This subset provides a more general search capability. It is a 284 superset of the SearchRequest subset defined in Section 6.2.1. The 285 elements added to this service are: 287 - singleLevel and wholeSubtree scope needs to be supported 289 - sizeLimit is included 291 - timeLimit is included 292 - Enhanced filter capability 294 An application providing a LDAP repository search service MAY 295 implement other aspects of the SearchRequest as well. 297 7.2.2. Search Response 299 The full LDAPv2 SearchResponse is defined in RFC 1777. 301 An application providing a LDAP repository search service over 302 LDAPv2 MUST implement the full SearchResponse. 304 7.3. Unbind 306 An application providing a LDAP repository search service MUST 307 implement the full UnbindRequest. 309 8. LDAP Repository Modify 311 To add, delete and modify PKI information in a repository requires 312 a subset of the following LDAP operations: 314 BindRequest (and BindResponse) 315 ModifyRequest (and ModifyResponse) 316 AddRequest (and AddResponse) 317 DelRequest (and DelResponse 318 UnbindRequest 320 The subset of each operation REQUIRED is given below. 322 8.1. Bind 324 The full LDAP v2 Bind Request is defined in RFC 1777. 326 An application providing a LDAP repository modify service MUST 327 implement the following subset of this operation: 329 BindRequest ::= 330 [APPLICATION 0] SEQUENCE { 331 version INTEGER (2), 332 name LDAPDN, 333 simpleauth [0] OCTET STRING 334 } 336 A LDAP repository modify service MUST implement authenticated 337 access. 339 The BindResponse subsets needed are the same as those described in 340 Section 6.1.2. 342 8.2. Modify 344 8.2.1. Modify Request 346 The full LDAPv2 ModifyRequest is defined in RFC 1777. 348 An application providing a LDAP repository modify service MUST 349 implement the following subset of the ModifyRequest protocol unit. 351 ModifyRequest ::= 352 [APPLICATION 6] SEQUENCE { 353 object LDAPDN, 354 modification SEQUENCE OF SEQUENCE { 355 operation ENUMERATED { 356 add (0), 357 delete (1) 358 }, 359 modification SEQUENCE { 360 type AttributeType, 361 values SET OF 362 AttributeValue 363 } 364 } 365 } 367 All aspects of the ModifyRequest MUST be supported, except for the 368 following: 370 - Only the add and delete values of operation need to be supported 372 8.2.2. Modify Response 374 The full LDAPv2 ModifyResponse is defined in RFC 1777. 376 An application providing a LDAP repository modify service MUST 377 implement the full ModifyResponse. 379 8.3. Add 381 8.3.1. Add Request 383 The full LDAPv2 AddRequest is defined in RFC 1777. 385 An application providing a LDAP repository modify service MUST 386 implement the full AddRequest. 388 8.3.2. Add Response 390 The full LDAPv2 AddResponse is defined in RFC 1777. 392 An application providing a LDAP repository modify service MUST 393 implement the full AddResponse. 395 8.4. Delete 397 8.4.1. Delete Request 399 The full LDAPv2 DelRequest is defined in RFC 1777. 401 An application providing a LDAP repository modify service MUST 402 implement the full DelRequest. 404 8.4.2. Delete Response 406 The full LDAPv2 DelResponse is defined in RFC 1777. 408 An application providing a LDAP repository modify service MUST 409 implement the full DelResponse. 411 8.5. Unbind 413 An application providing a LDAP repository modify service MUST 414 implement the full UnbindRequest. 416 9. Non-standard attribute value encodings 418 When conveyed in LDAP requests and results, attributes defined in 419 X.500 are to be encoded using string representations defined in RFC 420 1778, The String Representation of Standard Attribute Syntaxes. 421 These string encodings were based on the attribute definitions from 422 X.500(1988). Thus, the string representations of the PKI informa- 423 tion elements are for version 1 certificates and version 1 revoca- 424 tion lists. Since this specification uses version 3 certificates 425 and version 2 revocation lists, as defined in X.509(1997), the RFC 426 1778 string encoding of these attributes is inappropriate. 428 For this reason, these attributes MUST be encoded using a syntax 429 similar to the syntax "Undefined" from section 2.1 of RFC 1778: 430 values of these attributes are encoded as if they were values of 431 type "OCTET STRING", with the string value of the encoding being 432 the DER-encoding of the value itself. For example, when writing a 433 userCertificate to the repository, the CA generates a DER-encoding 434 of the certificate and uses that encoding as the value of the user- 435 Certificate attribute in the LDAP Modify request.This encoding 436 style is consistent with the encoding scheme proposed for LDAPv3, 437 which is now being defined within the IETF. 439 Note that certificates and revocation lists will be transferred 440 using this mechanism rather than the string encodings in RFC 1778 441 and client systems which do not understand this encoding may 442 experience problems with these attributes. 444 10. Transport 446 An application providing a LDAP repository read service, LDAP repo- 447 sitory search service, or LDAP repository modify service MUST sup- 448 port LDAPv2 transport over TCP, as defined in Section 3.1 of RFC 449 1777. 451 An application providing a LDAP repository read service, LDAP repo- 452 sitory search service, or LDAP repository modify service MAY sup- 453 port LDAPv2 transport over other reliable transports as well. 455 11. Security Considerations 457 Since the elements of information which are key to the PKI service 458 (certificates and CRLs) are both digitally signed pieces of infor- 459 mation, additional integrity service is NOT REQUIRED. As neither 460 information element need be kept secret and anonymous access to 461 such information, for retrieval purposes is generally acceptable, 462 privacy service is NOT REQUIRED for information retrieval requests. 464 CAs have additional requirements, including modification of PKI 465 information. Simple authentication alone is not sufficient for 466 these purposes. It is RECOMMENDED that some stronger means of 467 authentication and/or (if simple authentication is used) some means 468 of protecting the privacy of the password is used, (e.g. accept 469 modifications only via physically secure networks, use IPsec, use 470 SSH or TLS or SSL tunnel). Without such authentication, it is pos- 471 sible that a denial-of-service attack could occur where the 472 attacker replaces valid certificates with bogus ones. 474 For the LDAP repository modify service, profiled in section 8, 475 there are some specific security considerations with respect to 476 access control. These controls apply to a repository which is under 477 the same management control as the CA. Organizations operating 478 directories are NOT REQUIRED to provide external CAs access permis- 479 sion to their directories. 481 The CA MUST have access control permissions allowing it to: 483 For CA entries: 485 - add, modify and delete all PKI attributes for its 486 own directory entry; 487 - add, modify and delete all values of these attributes. 489 For CRL distribution point entries (if used): 490 - create, modify and delete entries of object class 491 cRLDistributionPoint immediately subordinate to its own 492 entry; 493 - add, modify and delete all attributes, and all values of 494 these attributes for these entries. 496 For subscriber (end-entity) entries: 497 - add, modify and delete the attribute userCertificate and 498 all values of that attribute, issued by this CA 499 to/from these entries. 501 The CA is the ONLY entity with these permissions. 503 An application providing LDAP repository read, LDAP repository 504 search, or LDAP repository modify service as defined in this 505 specification is NOT REQUIRED to implement any additional security 506 features other than those described herein, however an implementa- 507 tion SHOULD do so. 509 12. References 511 [1] Lightweight Directory Access Protocol. Y. Yeong, T. Howes, S. 512 Kille, RFC 1777, March 1995. 514 [2] The String Representation of Standard Attribute Syntaxes. T. 515 Howes, S. Kille, W. Yeong, C. Robbins, RFC 1778, March 1995. 517 [3] Key Words for use in RFCs to Indicate Requirement Levels, S. 518 Bradner, RFC 2119, March 1997. 520 13. Author's Address 522 Sharon Boeyen 523 Entrust Technologies Limited 524 750 Heron Road 525 Ottawa, Ontario 526 Canada K1V 1A7 527 boeyen@entrust.com 529 Tim Howes 530 Netscape Communications Corp. 531 501 E. Middlefield Rd. 532 Mountain View, CA 94043 533 USA 534 howes@netscape.com 536 Patrick Richard 537 Xcert Software Inc. 538 Suite 1001, 701 W. Georgia Street 539 P.O. Box 10145 540 Pacific Centre 541 Vancouver, B.C. 542 Canada V7Y 1C6 543 patr@xcert.com