git.sur5r.net Git - openldap/blob - doc/rfc/rfc2559.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      S. Boeyen
   8 Request for Comments: 2559                                   Entrust
   9 Updates: 1778                                               T. Howes
  10 Category: Standards Track                                   Netscape
  11                                                           P. Richard
  12                                                                Xcert
  13                                                           April 1999
  14
  15
  16                 Internet X.509 Public Key Infrastructure
  17                      Operational Protocols - LDAPv2
  18
  19 Status of this Memo
  20
  21    This document specifies an Internet standards track protocol for the
  22    Internet community, and requests discussion and suggestions for
  23    improvements.  Please refer to the current edition of the "Internet
  24    Official Protocol Standards" (STD 1) for the standardization state
  25    and status of this protocol.  Distribution of this memo is unlimited.
  26
  27 Copyright Notice
  28
  29    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  30
  31 1.  Abstract
  32
  33    The protocol described in this document is designed to satisfy some
  34    of the operational requirements within the Internet X.509 Public Key
  35    Infrastructure (IPKI).  Specifically, this document addresses
  36    requirements to provide access to Public Key Infrastructure (PKI)
  37    repositories for the purposes of retrieving PKI information and
  38    managing that same information.  The mechanism described in this
  39    document is based on the Lightweight Directory Access Protocol (LDAP)
  40    v2, defined in RFC 1777, defining a profile of that protocol for use
  41    within the IPKI and updates encodings for certificates and revocation
  42    lists from RFC 1778. Additional mechanisms addressing PKIX
  43    operational requirements are specified in separate documents.
  44
  45    The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
  46    in this document are to be interpreted as described in RFC 2119.
  47
  48 2.  Introduction
  49
  50    This specification is part of a multi-part standard for development
  51    of a Public Key Infrastructure (PKI) for the Internet. This
  52    specification addresses requirements to provide retrieval of X.509
  53    PKI information, including certificates and CRLs from a repository.
  54    This specification also addresses requirements to add, delete and
  55
  56
  57
  58 Boeyen, et al.              Standards Track                     [Page 1]
  59 \f
  60 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  61
  62
  63    modify PKI information in a repository. A profile based on the LDAP
  64    version 2 protocol is provided to satisfy these requirements.
  65
  66 3.  Model
  67
  68    The PKI components, as defined in PKIX Part 1, which are involved in
  69    PKIX operational protocol interactions include:
  70
  71       -  End Entities
  72       -  Certification Authorities (CA)
  73       -  Repository
  74
  75    End entities and CAs using LDAPv2, retrieve PKI information from the
  76    repository using a subset of the LDAPv2 protocol.
  77
  78    CAs populate the repository with PKI information using a subset of
  79    the LDAPv2 protocol.
  80
  81 4.  Lightweight Directory Access Protocol (LDAP)
  82
  83    The following sections examine the retrieval of PKI information from
  84    a repository and management of PKI information in a repository. A
  85    profile of the LDAPv2 protocol is defined for providing these
  86    services.
  87
  88    Section 5 satisfies the requirement to retrieve PKI information (a
  89    certificate, CRL, or other information of interest) from an entry in
  90    the repository, where the retrieving entity (either an end entity or
  91    a CA) has knowledge of the name of the entry. This is termed
  92    "repository read".
  93
  94    Section 6 satisfies the same requirement as 5 for the situation where
  95    the name of the entry is not known, but some other related
  96    information which may optionally be used as a filter against
  97    candidate entries in the repository, is known.  This is termed
  98    "repository search".
  99
 100    Section 7 satisfies the requirement of CAs to add, delete and modify
 101    PKI information information (a certificate, CRL, or other information
 102    of interest)in the repository. This is termed "repository modify".
 103
 104    The subset of LDAPv2 needed to support each of these functions is
 105    described below.  Note that the repository search service is a
 106    superset of the repository read service in terms of the LDAPv2
 107    functionality needed.
 108
 109    Note that all tags are implicit by default in the ASN.1 definitions
 110    that follow.
 111
 112
 113
 114 Boeyen, et al.              Standards Track                     [Page 2]
 115 \f
 116 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 117
 118
 119 5.  LDAP Repository Read
 120
 121    To retrieve information from an entry corresponding to the subject or
 122    issuer name of a certificate, requires a subset of the following
 123    three LDAP operations:
 124
 125      BindRequest (and BindResponse)
 126      SearchRequest (and SearchResponse)
 127      UnbindRequest
 128
 129    The subset of each REQUIRED operation is given below.
 130
 131 5.1.  Bind
 132
 133 5.1.1.  Bind Request
 134
 135    The full LDAP v2 Bind Request is defined in RFC 1777.
 136
 137    An application providing a LDAP repository read service MUST
 138    implement the following subset of this operation:
 139
 140       BindRequest ::=
 141         [APPLICATION 0] SEQUENCE {
 142            version      INTEGER (2),
 143            name         LDAPDN, -- MUST accept NULL LDAPDN
 144            simpleauth [0] OCTET STRING  -- MUST accept NULL simple
 145            }
 146
 147    An application providing a LDAP repository read service MAY implement
 148    other aspects of the BindRequest as well.
 149
 150    Different services may have different security requirements.  Some
 151    services may allow anonymous search, others may require
 152    authentication. Those services allowing anonymous search may choose
 153    only to allow search based on certain criteria and not others.
 154
 155    A LDAP repository read service SHOULD implement some level of
 156    anonymous search access. A LDAP repository read service MAY implement
 157    authenticated search access.
 158
 159 5.1.2.  Bind Response
 160
 161    The full LDAPv2 BindResponse is described in RFC 1777.
 162
 163    An application providing a LDAP repository read service MUST
 164    implement this entire protocol element, though only the following
 165    error codes may be returned from a Bind operation:
 166
 167
 168
 169
 170 Boeyen, et al.              Standards Track                     [Page 3]
 171 \f
 172 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 173
 174
 175        success                      (0),
 176        operationsError              (1),
 177        protocolError                (2),
 178        authMethodNotSupported       (7),
 179        noSuchObject                 (32),
 180        invalidDNSyntax              (34),
 181        inappropriateAuthentication  (48),
 182        invalidCredentials           (49),
 183        busy                         (51),
 184        unavailable                  (52),
 185        unwillingToPerform           (53),
 186        other                        (80)
 187
 188 5.2.  Search
 189
 190 5.2.1.  Search Request
 191
 192    The full LDAPv2 SearchRequest is defined in RFC 1777.
 193
 194    An application providing a LDAP repository read service MUST
 195    implement the following subset of the SearchRequest.
 196
 197       SearchRequest ::=
 198         [APPLICATION 3] SEQUENCE {
 199            baseObject     LDAPDN,
 200            scope             ENUMERATED {
 201                              baseObject   (0),
 202                                         },
 203            derefAliases   ENUMERATED {
 204                              neverDerefAliases   (0),
 205                                      },
 206            sizeLimit      INTEGER (0),
 207            timeLimit      INTEGER (0),
 208            attrsOnly      BOOLEAN, -- FALSE only
 209            filter         Filter,
 210            attributes     SEQUENCE OF AttributeType
 211                                }
 212
 213       Filter ::=
 214         CHOICE {
 215           present        [7] AttributeType, -- "objectclass" only
 216                  }
 217
 218    This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
 219    operation: a base object search with a filter testing for the
 220    existence of the objectClass attribute.
 221
 222
 223
 224
 225
 226 Boeyen, et al.              Standards Track                     [Page 4]
 227 \f
 228 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 229
 230
 231    An application providing a LDAP repository read service MAY implement
 232    other aspects of the SearchRequest as well.
 233
 234 5.2.2.
 235
 236    The full LDAPv2 SearchResponse is defined in RFC 1777.
 237
 238    An application providing a LDAP repository read service over LDAPv2
 239    MUST implement the full SearchResponse.
 240
 241    Note that in the case of multivalued attributes such as
 242    userCertificate a SearchResponse containing this attribute will
 243    include all values, assuming the requester has sufficient access
 244    permissions.  The application/relying party may need to select an
 245    appropriate value to be used. Also note that retrieval of a
 246    certificate from a named entry does not guarantee that the
 247    certificate will include that same Distinguished Name (DN) and in
 248    some cases the subject DN in the certificate may be NULL.
 249
 250 5.3.  Unbind
 251
 252    The full LDAPv2 UnbindRequest is defined in RFC 1777.
 253
 254    An application providing a LDAP repository read service MUST
 255    implement the full UnbindRequest.
 256
 257 6.  LDAP Repository Search
 258
 259    To search, using arbitrary criteria, for an entry in a repository
 260    containing a certificate, CRL, or other information of interest,
 261    requires a subset of the following three LDAP operations:
 262
 263      BindRequest (and BindResponse)
 264      SearchRequest (and SearchResponse)
 265      UnbindRequest
 266
 267    The subset of each operation REQUIRED is given below.
 268
 269 6.1.  Bind
 270
 271    The BindRequest and BindResponse subsets needed are the same as those
 272    described in Section 5.1.
 273
 274    The full LDAP v2 Bind Request is defined in RFC 1777.
 275
 276
 277
 278
 279
 280
 281
 282 Boeyen, et al.              Standards Track                     [Page 5]
 283 \f
 284 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 285
 286
 287 6.2.  Search
 288
 289 6.2.1.  Search Request
 290
 291    The full LDAPv2 SearchRequest is defined in RFC 1777.
 292
 293    An application providing a LDAP repository search service MUST
 294    implement the following subset of the SearchRequest protocol unit.
 295
 296       SearchRequest ::=
 297         [APPLICATION 3] SEQUENCE {
 298            baseObject     LDAPDN,
 299            scope          ENUMERATED {
 300                                baseObject     (0),
 301                                singleLevel    (1),
 302                                wholeSubtree   (2)
 303                                      },
 304            derefAliases   ENUMERATED {
 305                                neverDerefAliases     (0),
 306                                      },
 307            sizeLimit      INTEGER (0 .. maxInt),
 308            timeLimit      INTEGER (0 .. maxInt),
 309            attrsOnly      BOOLEAN,  -- FALSE only
 310            filter         Filter,
 311            attributes     SEQUENCE OF AttributeType
 312                                 }
 313
 314    All aspects of the SearchRequest MUST be supported, except for the
 315    following:
 316
 317    - Only the neverDerefAliases value of derefAliases needs to be
 318      supported
 319
 320    - Only the FALSE value for attrsOnly needs to be supported
 321
 322    This subset provides a more general search capability.  It is a
 323    superset of the SearchRequest subset defined in Section 5.2.1. The
 324    elements added to this service are:
 325
 326    - singleLevel and wholeSubtree scope needs to be supported
 327
 328    - sizeLimit is included
 329
 330    - timeLimit is included
 331
 332    - Enhanced filter capability
 333
 334
 335
 336
 337
 338 Boeyen, et al.              Standards Track                     [Page 6]
 339 \f
 340 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 341
 342
 343    An application providing a LDAP repository search service MAY
 344    implement other aspects of the SearchRequest as well.
 345
 346 6.2.2.  Search Response
 347
 348    The full LDAPv2 SearchResponse is defined in RFC 1777.
 349
 350    An application providing a LDAP repository search service over LDAPv2
 351    MUST implement the full SearchResponse.
 352
 353 6.3.  Unbind
 354
 355    An application providing a LDAP repository search service MUST
 356    implement the full UnbindRequest.
 357
 358 7.  LDAP Repository Modify
 359
 360    To add, delete and modify PKI information in a repository  requires a
 361    subset of the following LDAP operations:
 362
 363      BindRequest (and BindResponse)
 364      ModifyRequest (and ModifyResponse)
 365      AddRequest (and AddResponse)
 366      DelRequest (and DelResponse
 367      UnbindRequest
 368
 369    The subset of each operation REQUIRED is given below.
 370
 371 7.1.  Bind
 372
 373    The full LDAP v2 Bind Request is defined in RFC 1777.
 374
 375    An application providing a LDAP repository modify service MUST
 376    implement the following subset of this operation:
 377
 378       BindRequest ::=
 379         [APPLICATION 0] SEQUENCE {
 380            version      INTEGER (2),
 381            name         LDAPDN,
 382            simpleauth [0] OCTET STRING
 383            }
 384
 385    A LDAP repository modify service MUST implement authenticated access.
 386
 387    The BindResponse subsets needed are the same as those described in
 388    Section 5.1.2.
 389
 390
 391
 392
 393
 394 Boeyen, et al.              Standards Track                     [Page 7]
 395 \f
 396 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 397
 398
 399 7.2.  Modify
 400
 401 7.2.1.  Modify Request
 402
 403    The full LDAPv2 ModifyRequest is defined in RFC 1777.
 404
 405    An application providing a LDAP repository modify service MUST
 406    implement the following subset of the ModifyRequest protocol unit.
 407
 408       ModifyRequest ::=
 409         [APPLICATION 6] SEQUENCE {
 410        object         LDAPDN,
 411        modification   SEQUENCE OF SEQUENCE {
 412                         operation     ENUMERATED {
 413                                         add     (0),
 414                                         delete  (1)
 415                                       },
 416                         modification  SEQUENCE {
 417                                       type   AttributeType,
 418                                       values SET OF
 419                                              AttributeValue
 420                                       }
 421                       }
 422         }
 423
 424    All aspects of the ModifyRequest MUST be supported, except for the
 425    following:
 426
 427    - Only the add and delete values of operation need to be supported
 428
 429 7.2.2.  Modify Response
 430
 431    The full LDAPv2 ModifyResponse is defined in RFC 1777.
 432
 433    An application providing a LDAP repository modify service MUST
 434    implement the full ModifyResponse.
 435
 436 7.3.  Add
 437
 438 7.3.1.  Add Request
 439
 440    The full LDAPv2 AddRequest is defined in RFC 1777.
 441
 442    An application providing a LDAP repository modify service MUST
 443    implement the full AddRequest.
 444
 445
 446
 447
 448
 449
 450 Boeyen, et al.              Standards Track                     [Page 8]
 451 \f
 452 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 453
 454
 455 7.3.2.  Add Response
 456
 457    The full LDAPv2 AddResponse is defined in RFC 1777.
 458
 459    An application providing a LDAP repository modify service MUST
 460    implement the full AddResponse.
 461
 462 7.4.  Delete
 463
 464 7.4.1.  Delete Request
 465
 466    The full LDAPv2 DelRequest is defined in RFC 1777.
 467
 468    An application providing a LDAP repository modify service MUST
 469    implement the full DelRequest.
 470
 471 7.4.2.  Delete Response
 472
 473    The full LDAPv2 DelResponse is defined in RFC 1777.
 474
 475    An application providing a LDAP repository modify service MUST
 476    implement the full DelResponse.
 477
 478 7.5.  Unbind
 479
 480    An application providing a LDAP repository modify service MUST
 481    implement the full UnbindRequest.
 482
 483 8.  Non-standard attribute value encodings
 484
 485    When conveyed in LDAP requests and results, attributes defined in
 486    X.500 are to be encoded using string representations defined in RFC
 487    1778, The String Representation of Standard Attribute Syntaxes.
 488    These string encodings were based on the attribute definitions from
 489    X.500(1988).  Thus, the string representations of the PKI information
 490    elements are for version 1 certificates and version 1 revocation
 491    lists.  Since this specification uses version 3 certificates and
 492    version 2 revocation lists, as defined in X.509(1997), the RFC 1778
 493    string encoding of these attributes is inappropriate.
 494
 495    For this reason, these attributes MUST be encoded using a syntax
 496    similar to the syntax "Undefined" from section 2.1 of RFC 1778:
 497    values of these attributes are encoded as if they were values of type
 498    "OCTET STRING", with the string value of the encoding being the DER-
 499    encoding of the value itself.  For example, when writing a
 500    userCertificate to the repository, the CA generates a DER-encoding of
 501    the certificate and uses that encoding as the value of the
 502    userCertificate attribute in the LDAP Modify request.This encoding
 503
 504
 505
 506 Boeyen, et al.              Standards Track                     [Page 9]
 507 \f
 508 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 509
 510
 511    style is consistent with the encoding scheme proposed for LDAPv3,
 512    which is now being defined within the IETF.
 513
 514    Note that certificates and revocation lists will be transferred using
 515    this mechanism rather than the string encodings in RFC 1778 and
 516    client systems which do not understand this encoding may experience
 517    problems with these attributes.
 518
 519 9.  Transport
 520
 521    An application providing a LDAP repository read service, LDAP
 522    repository search service, or LDAP repository modify service MUST
 523    support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
 524    1777.
 525
 526    An application providing a LDAP repository read service, LDAP
 527    repository search service, or LDAP repository modify service MAY
 528    support LDAPv2 transport over other reliable transports as well.
 529
 530 10.  Security Considerations
 531
 532    Since the elements of information which are key to the PKI service
 533    (certificates and CRLs) are both digitally signed pieces of
 534    information, additional integrity service is NOT REQUIRED.  As
 535    neither information element need be kept secret and anonymous access
 536    to such information, for retrieval purposes is generally acceptable,
 537    privacy service is NOT REQUIRED for information retrieval requests.
 538
 539    CAs have additional requirements, including modification of PKI
 540    information.  Simple authentication alone is not sufficient for these
 541    purposes. It is RECOMMENDED that some stronger means of
 542    authentication and/or (if simple authentication is used) some means
 543    of protecting the privacy of the password is used, (e.g.  accept
 544    modifications only via physically secure networks, use IPsec, use SSH
 545    or TLS or SSL tunnel). Without such authentication, it is possible
 546    that a denial-of-service attack could occur where the attacker
 547    replaces valid certificates with bogus ones.
 548
 549    For the LDAP repository modify service, profiled in section 7, there
 550    are some specific security considerations with respect to access
 551    control. These controls apply to a repository which is under the same
 552    management control as the CA. Organizations operating directories are
 553    NOT REQUIRED to provide external CAs access permission to their
 554    directories.
 555
 556
 557
 558
 559
 560
 561
 562 Boeyen, et al.              Standards Track                    [Page 10]
 563 \f
 564 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 565
 566
 567    The CA MUST have access control permissions allowing it to:
 568
 569       For CA entries:
 570          - add, modify and delete all PKI attributes for its own
 571            directory entry;
 572          - add, modify and delete all values of these attributes.
 573
 574       For CRL distribution point entries (if used):
 575          - create, modify and delete entries of object class
 576            cRLDistributionPoint immediately subordinate to its own
 577            entry;
 578          - add, modify and delete all attributes, and all values of
 579            these attributes for these entries.
 580
 581       For subscriber (end-entity) entries:
 582          - add, modify and delete the attribute userCertificate and all
 583            values of that attribute, issued by this CA to/from these
 584            entries.
 585
 586    The CA is the ONLY entity with these permissions.
 587
 588    An application providing LDAP repository read, LDAP repository
 589    search, or LDAP repository modify service as defined in this
 590    specification is NOT REQUIRED to implement any additional security
 591    features other than those described herein, however an implementation
 592    SHOULD do so.
 593
 594 11.  References
 595
 596    [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
 597         Protocol", RFC 1777, March 1995.
 598
 599    [2]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
 600         Representation of Standard Attribute Syntaxes", RFC 1778, March
 601         1995.
 602
 603    [3]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
 604         Levels", BCP 14, RFC 2119, March 1997.
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Boeyen, et al.              Standards Track                    [Page 11]
 619 \f
 620 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 621
 622
 623 12.  Authors' Addresses
 624
 625    Sharon Boeyen
 626    Entrust Technologies Limited
 627    750 Heron Road
 628    Ottawa, Ontario
 629    Canada K1V 1A7
 630
 631    EMail: sharon.boeyen@entrust.com
 632
 633
 634    Tim Howes
 635    Netscape Communications Corp.
 636    501 E. Middlefield Rd.
 637    Mountain View, CA 94043
 638    USA
 639
 640    EMail: howes@netscape.com
 641
 642
 643    Patrick Richard
 644    Xcert Software Inc.
 645    Suite 1001, 701 W. Georgia Street
 646    P.O. Box 10145
 647    Pacific Centre
 648    Vancouver, B.C.
 649    Canada V7Y 1C6
 650
 651    EMail: patr@xcert.com
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Boeyen, et al.              Standards Track                    [Page 12]
 675 \f
 676 RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
 677
 678
 679 13.  Full Copyright Statement
 680
 681    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 682
 683    This document and translations of it may be copied and furnished to
 684    others, and derivative works that comment on or otherwise explain it
 685    or assist in its implementation may be prepared, copied, published
 686    and distributed, in whole or in part, without restriction of any
 687    kind, provided that the above copyright notice and this paragraph are
 688    included on all such copies and derivative works.  However, this
 689    document itself may not be modified in any way, such as by removing
 690    the copyright notice or references to the Internet Society or other
 691    Internet organizations, except as needed for the purpose of
 692    developing Internet standards in which case the procedures for
 693    copyrights defined in the Internet Standards process must be
 694    followed, or as required to translate it into languages other than
 695    English.
 696
 697    The limited permissions granted above are perpetual and will not be
 698    revoked by the Internet Society or its successors or assigns.
 699
 700    This document and the information contained herein is provided on an
 701    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 702    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 703    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 704    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 705    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Boeyen, et al.              Standards Track                    [Page 13]
 731 \f