home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pkix-ipki2opp-03.txt < prev    next >
Text File  |  1997-09-18  |  19KB  |  671 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. PKIX Working Group                           Sharon Boeyen (Entrust)
  8. draft-ietf-pkix-ipki2opp-03.txt              Tim Howes (Netscape)
  9. Expires in 6 months                          Patrick Richard (Xcert)
  10.                                              September 1997
  11.  
  12.  
  13.                    Internet Public Key Infrastructure
  14.                       Operational Protocols - LDAP
  15.                    <draft-ietf-pkix-ipki2opp-03.txt>
  16.  
  17.  
  18.  
  19. 1.  Status of this Memo
  20.  
  21. This document is an Internet-Draft. Internet-Drafts  are  working  docu-
  22. ments  of the Internet Engineering Task Force (IETF), its areas, and its
  23. working groups. Note that other groups may also distribute working docu-
  24. ments as Internet-Drafts.
  25.  
  26. Internet-Drafts are draft documents valid for a maximum  of  six  months
  27. and  may  be  updated,  replaced, or obsoleted by other documents at any
  28. time. It is inappropriate to use Internet-Drafts as  reference  material
  29. or to cite them other than as "work in progress."
  30.  
  31. To learn the current status of  any  Internet-Draft,  please  check  the
  32. "1id-abstracts.txt"  listing  contained  in  the  Internet-Drafts Shadow
  33. Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
  34. munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
  35. ftp.isi.edu (US West Coast).
  36.  
  37. 2.  Abstract
  38.  
  39. The protocol described in this document is designed to satisfy  some  of
  40. the  operational requirements within the Internet Public Key Infrastruc-
  41. ture (IPKI).  Specifically, this document addresses requirements to pro-
  42. vide access to Public Key Infrastructure (PKI) repositories for the pur-
  43. poses of retrieving PKI information and managing that same  information.
  44. The  mechanism  described  in  this document is based on the Lightweight
  45. Directory Access Protocol (LDAP) version 2, defined  in  RFC  1777,  and
  46. defines  a  profile of that protocol for use within the IPKI. Additional
  47. mechanisms addressing PKIX  operational  requirements  are  specified  in
  48. separate documents.
  49.  
  50. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"  in
  51. this document are to be interpreted as described in RFC 2119.
  52.  
  53. Please send comments on this document to the  ietf-pkix@tandem.com  mail
  54. list.
  55.  
  56.  
  57.  
  58. Boeyen, Howes & Richard                                         [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65. INTERNET DRAFT                                            September 1997
  66.  
  67.  
  68. 3.  Introduction
  69.  
  70. This specification is part of a multi-part standard for development of a
  71. Public  Key  Infrastructure  (PKI)  for the Internet. This specification
  72. addresses requirements to provide retrieval of  X.509  PKI  information,
  73. including  certificates  and  CRLs from a repository. This specification
  74. also addresses requirements to add, delete and modify PKI information in
  75. a repository. A profile based on the LDAP version 2 protocol is provided
  76. to satisfy these requirements.
  77.  
  78. 4.  Model
  79.  
  80. The PKI components, as defined in PKIX Part 1,  which  are  involved  in
  81. PKIX operational protocol interactions include:
  82.  
  83.    -  End Entities
  84.    -  Certification Authorities (CA)
  85.    -  Repository
  86.  
  87. End entities and CAs using LDAPv2, retrieve  PKI  information  from  the
  88. repository using a subset of the LDAPv2 protocol.
  89.  
  90. CAs populate the repository with PKI information using a subset  of  the
  91. LDAPv2 protocol.
  92.  
  93. 5.  Lightweight Directory Access Protocol (LDAP)
  94.  
  95. The following sections examine the retrieval of PKI information  from  a
  96. repository  and management of PKI information in a repository. A profile
  97. of the LDAPv2 protocol is defined for providing these services.
  98.  
  99. Section 6 satisfies the requirement to retrieve PKI information (a  cer-
  100. tificate,  CRL,  or other information of interest)  from an entry in the
  101. repository, where the retrieving entity (either an end entity or  a  CA)
  102. has  knowledge  of  the  name  of  the entry. This is termed "repository
  103. read".
  104.  
  105. Section 7 satisfies the same requirement as 6 for  the  situation  where
  106. the  name  of the entry is not known, but some other related information
  107. which may optionally be used as a filter against  candidate  entries  in
  108. the repository, is known.  This is termed "repository search".
  109.  
  110. Section 8 satisfies the requirement of CAs to add, delete and modify PKI
  111. information  information  (a  certificate,  CRL, or other information of
  112. interest)in the repository. This is termed "repository modify".
  113.  
  114. The subset of LDAPv2 needed  to  support  each  of  these  functions  is
  115. described  below. Note that the repository search service  is a superset
  116.  
  117.  
  118.  
  119. Boeyen, Howes & Richard                                         [Page 2]
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126. INTERNET DRAFT                                            September 1997
  127.  
  128.  
  129. of the repository read service  in terms  of  the  LDAPv2  functionality
  130. needed.
  131.  
  132. Note  that all tags are implicit by default  in  the  ASN.1  definitions
  133. that follow.
  134.  
  135. 6.  LDAP Repository Read
  136.  
  137. To retrieve information from an entry corresponding to  the  subject  or
  138. issuer  name  of a certificate, requires a subset of the following three
  139. LDAP operations:
  140.  
  141.   BindRequest (and BindResponse)
  142.   SearchRequest (and SearchResponse)
  143.   UnbindRequest
  144.  
  145. The subset of each REQUIRED operation is given below.
  146.  
  147. 6.1.  Bind
  148.  
  149. 6.1.1.  Bind Request
  150.  
  151. The full LDAP v2 Bind Request is defined in RFC 1777.
  152.  
  153. An application providing a LDAP repository read service  MUST  implement
  154. the following subset of this operation:
  155.  
  156.    BindRequest ::=
  157.      [APPLICATION 0] SEQUENCE {
  158.         version      INTEGER (2),
  159.         name         LDAPDN, -- MUST accept NULL LDAPDN
  160.         simpleauth [0] OCTET STRING  -- MUST accept NULL simple
  161.         }
  162.  
  163. An application providing a LDAP repository read  service  MAY  implement
  164. other aspects of the BindRequest as well.
  165.  
  166. Different services may have different security requirements.  Some  ser-
  167. vices  may  allow  anonymous  search, others may require authentication.
  168. Those services allowing anonymous search may choose only to allow search
  169. based on certain criteria and not others.
  170.  
  171. A LDAP repository read service SHOULD implement some level of  anonymous
  172. search  access.  A  LDAP repository read service MAY implement authenti-
  173. cated search access.
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Boeyen, Howes & Richard                                         [Page 3]
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187. INTERNET DRAFT                                            September 1997
  188.  
  189.  
  190. 6.1.2.  Bind Response
  191.  
  192. The full LDAPv2 BindResponse is described in RFC 1777.
  193.  
  194. An application providing a LDAP repository read service  MUST  implement
  195. this  entire protocol element, though only the following error codes may
  196. be returned from a Bind operation:
  197.  
  198.   success                      (0),
  199.   operationsError              (1),
  200.   protocolError                (2),
  201.   authMethodNotSupported       (7),
  202.   noSuchObject                 (32),
  203.   invalidDNSyntax              (34),
  204.   inappropriateAuthentication  (48),
  205.   invalidCredentials           (49),
  206.   busy                         (51),
  207.   unavailable                  (52),
  208.   unwillingToPerform           (53),
  209.   other                        (80)
  210.  
  211. 6.2.  Search
  212.  
  213. 6.2.1.  Search Request
  214.  
  215. The full LDAPv2 SearchRequest is defined in RFC 1777.
  216.  
  217. An application providing a LDAP repository read service  MUST  implement
  218. the following subset of the SearchRequest.
  219.  
  220.    SearchRequest ::=
  221.      [APPLICATION 3] SEQUENCE {
  222.         baseObject     LDAPDN,
  223.         scope             ENUMERATED {
  224.                           baseObject   (0),
  225.                                      },
  226.         derefAliases   ENUMERATED {
  227.                           neverDerefAliases   (0),
  228.                                   },
  229.         sizeLimit      INTEGER (0),
  230.         timeLimit      INTEGER (0),
  231.         attrsOnly      BOOLEAN, -- FALSE only
  232.         filter         Filter,
  233.         attributes     SEQUENCE OF AttributeType
  234.                             }
  235.  
  236.    Filter ::=
  237.      CHOICE {
  238.  
  239.  
  240.  
  241. Boeyen, Howes & Richard                                         [Page 4]
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248. INTERNET DRAFT                                            September 1997
  249.  
  250.  
  251.        present        [7] AttributeType, -- "objectclass" only
  252.               }
  253.  
  254. This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"  opera-
  255. tion:  a  base  object search with a filter testing for the existence of
  256. the objectClass attribute.
  257.  
  258. An application providing a LDAP repository read  service  MAY  implement
  259. other aspects of the SearchRequest as well.
  260.  
  261. 6.2.2.
  262.  
  263. The full LDAPv2 SearchResponse is defined in RFC 1777.
  264.  
  265. An application providing a LDAP repository read service over LDAPv2 MUST
  266. implement the full SearchResponse.
  267.  
  268. 6.3.  Unbind
  269.  
  270. The full LDAPv2 UnbindRequest is defined in RFC 1777.
  271.  
  272. An application providing a LDAP repository read service  MUST  implement
  273. the full UnbindRequest.
  274.  
  275. 7.  LDAP Repository Search
  276.  
  277. To search ,using arbitrary criteria, for an entry in a  repository  con-
  278. taining a certificate, CRL, or other information of interest, requires a
  279. subset of the following three LDAP operations:
  280.  
  281.   BindRequest (and BindResponse)
  282.   SearchRequest (and SearchResponse)
  283.   UnbindRequest
  284.  
  285. The subset of each operation REQUIRED is given below.
  286.  
  287. 7.1.  Bind
  288.  
  289. The BindRequest and BindResponse subsets needed are the  same  as  those
  290. described in Section 6.1.
  291.  
  292. The full LDAP v2 Bind Request is defined in RFC 1777.
  293.  
  294. 7.2.  Search
  295.  
  296. 7.2.1.  Search Request
  297.  
  298. The full LDAPv2 SearchRequest is defined in RFC 1777.
  299.  
  300.  
  301.  
  302. Boeyen, Howes & Richard                                         [Page 5]
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309. INTERNET DRAFT                                            September 1997
  310.  
  311.  
  312. An application providing a LDAP repository search service MUST implement
  313. the following subset of the SearchRequest protocol unit.
  314.  
  315.    SearchRequest ::=
  316.      [APPLICATION 3] SEQUENCE {
  317.         baseObject     LDAPDN,
  318.         scope          ENUMERATED {
  319.                             baseObject     (0),
  320.                             singleLevel    (1),
  321.                             wholeSubtree   (2)
  322.                                   },
  323.         derefAliases   ENUMERATED {
  324.                             neverDerefAliases     (0),
  325.                                   },
  326.         sizeLimit      INTEGER (0 .. maxInt),
  327.         timeLimit      INTEGER (0 .. maxInt),
  328.         attrsOnly      BOOLEAN,  -- FALSE only
  329.         filter         Filter,
  330.         attributes     SEQUENCE OF AttributeType
  331.                              }
  332.  
  333. All aspects of the SearchRequest MUST be supported, except for the  fol-
  334. lowing:
  335.  
  336. - Only the neverDerefAliases value of derefAliases needs
  337.   to be supported
  338.  
  339. - Only the FALSE value for attrsOnly needs to be supported
  340.  
  341. This subset provides a more general search capability. It is a  superset
  342. of the SearchRequest subset defined in Section 6.2.1. The elements added
  343. to this service are:
  344.  
  345. - singleLevel and wholeSubtree scope needs to be supported
  346.  
  347. - sizeLimit is included
  348.  
  349. - timeLimit is included
  350.  
  351. - Enhanced filter capability
  352.  
  353. An application providing a LDAP repository search service MAY  implement
  354. other aspects of the SearchRequest as well.
  355.  
  356. 7.2.2.  Search Response
  357.  
  358. The full LDAPv2 SearchResponse is defined in RFC 1777.
  359.  
  360.  
  361.  
  362.  
  363. Boeyen, Howes & Richard                                         [Page 6]
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370. INTERNET DRAFT                                            September 1997
  371.  
  372.  
  373. An application providing a LDAP repository search  service  over  LDAPv2
  374. MUST implement the full SearchResponse.
  375.  
  376. 7.3.  Unbind
  377.  
  378. An application providing a LDAP repository search service MUST implement
  379. the full UnbindRequest.
  380.  
  381. 8.  LDAP Repository Modify
  382.  
  383. To add, delete and modify PKI information in  a  repository  requires  a
  384. subset of the following LDAP operations:
  385.  
  386.   BindRequest (and BindResponse)
  387.   ModifyRequest (and ModifyResponse)
  388.   AddRequest (and AddResponse)
  389.   DelRequest (and DelResponse
  390.   UnbindRequest
  391.  
  392. The subset of each operation REQUIRED is given below.
  393.  
  394. 8.1.  Bind
  395.  
  396. The full LDAP v2 Bind Request is defined in RFC 1777.
  397.  
  398. An application providing a LDAP repository modify service MUST implement
  399. the following subset of this operation:
  400.  
  401.    BindRequest ::=
  402.      [APPLICATION 0] SEQUENCE {
  403.         version      INTEGER (2),
  404.         name         LDAPDN,
  405.         simpleauth [0] OCTET STRING
  406.         }
  407.  
  408. A LDAP repository modify service MUST implement authenticated access.
  409.  
  410. The BindResponse subsets needed are the same as those described in  Sec-
  411. tion 6.1.2.
  412.  
  413. 8.2.  Modify
  414.  
  415. 8.2.1.  Modify Request
  416.  
  417. The full LDAPv2 ModifyRequest is defined in RFC 1777.
  418.  
  419. An application providing a LDAP repository modify service MUST implement
  420. the following subset of the ModifyRequest protocol unit.
  421.  
  422.  
  423.  
  424. Boeyen, Howes & Richard                                         [Page 7]
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431. INTERNET DRAFT                                            September 1997
  432.  
  433.  
  434.    ModifyRequest ::=
  435.      [APPLICATION 6] SEQUENCE {
  436.     object         LDAPDN,
  437.     modification   SEQUENCE OF SEQUENCE {
  438.                      operation     ENUMERATED {
  439.                                      add     (0),
  440.                                      delete  (1)
  441.                                    },
  442.                      modification  SEQUENCE {
  443.                                    type   AttributeType,
  444.                                    values SET OF
  445.                                           AttributeValue
  446.                                    }
  447.                    }
  448.      }
  449.  
  450. All aspects of the ModifyRequest MUST be supported, except for the  fol-
  451. lowing:
  452.  
  453. - Only the add and delete values of operation need to be supported
  454.  
  455. 8.2.2.  Modify Response
  456.  
  457. The full LDAPv2 ModifyResponse is defined in RFC 1777.
  458.  
  459. An application providing a LDAP repository modify service MUST implement
  460. the full ModifyResponse.
  461.  
  462. 8.3.  Add
  463.  
  464. 8.3.1.  Add Request
  465.  
  466. The full LDAPv2 AddRequest is defined in RFC 1777.
  467.  
  468. An application providing a LDAP repository modify service MUST implement
  469. the full AddRequest.
  470.  
  471. 8.3.2.  Add Response
  472.  
  473. The full LDAPv2 AddResponse is defined in RFC 1777.
  474.  
  475. An application providing a LDAP repository modify service MUST implement
  476. the full AddResponse.
  477.  
  478. 8.4.  Delete
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485. Boeyen, Howes & Richard                                         [Page 8]
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492. INTERNET DRAFT                                            September 1997
  493.  
  494.  
  495. 8.4.1.  Delete Request
  496.  
  497. The full LDAPv2 DelRequest is defined in RFC 1777.
  498.  
  499. An application providing a LDAP repository modify service MUST implement
  500. the full DelRequest.
  501.  
  502. 8.4.2.  Delete Response
  503.  
  504. The full LDAPv2 DelResponse is defined in RFC 1777.
  505.  
  506. An application providing a LDAP repository modify service MUST implement
  507. the full DelResponse.
  508.  
  509. 8.5.  Unbind
  510.  
  511. An application providing a LDAP repository modify service MUST implement
  512. the full UnbindRequest.
  513.  
  514. 9.  Non-standard attribute value encodings
  515.  
  516. When conveyed in LDAP requests and results, attributes defined in  X.500
  517. are  to be encoded using string representations defined in RFC 1778, The
  518. String Representation of  Standard  Attribute  Syntaxes.   These  string
  519. encodings  were  based  on  the  attribute definitions from X.500(1988).
  520. Thus, the string representations of the PKI information elements are for
  521. version  1  certificates  and  version  1  revocation lists.  Since this
  522. specification uses version  3  certificates  and  version  2  revocation
  523. lists,  as defined in X.509(1997), the RFC 1778 string encoding of these
  524. attributes is inappropriate.
  525.  
  526. For this reason, these attributes MUST be encoded using a syntax similar
  527. to the syntax  "Undefined" from section 2.1 of RFC 1778: values of these
  528. attributes are encoded as if they were values of  type  "OCTET  STRING",
  529. with  the  string  value  of  the encoding being the DER-encoding of the
  530. value itself.  For example, when writing a userCertificate to the  repo-
  531. sitory, the CA generates a DER-encoding of the certificate and uses that
  532. encoding as the value of  the  userCertificate  attribute  in  the  LDAP
  533. Modify  request.This  encoding  style  is  consistent  with the encoding
  534. scheme proposed for LDAPv3, which is now being defined within the IETF.
  535.  
  536. 10.  Transport
  537.  
  538. An application providing a LDAP repository read service, LDAP repository
  539. search  service,  or  LDAP repository modify service MUST support LDAPv2
  540. transport over TCP, as defined in Section 3.1 of RFC 1777.
  541.  
  542. An application providing a LDAP repository read service, LDAP repository
  543.  
  544.  
  545.  
  546. Boeyen, Howes & Richard                                         [Page 9]
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553. INTERNET DRAFT                                            September 1997
  554.  
  555.  
  556. search  service,  or  LDAP  repository modify service MAY support LDAPv2
  557. transport over other reliable transports as well.
  558.  
  559. 11.  Security Considerations
  560.  
  561. Since the elements of information which are key to the PKI service (cer-
  562. tificates  and CRLs) are both digitally signed pieces of information, no
  563. additional integrity service is REQUIRED.  As neither  information  ele-
  564. ment  need  be kept secret and anonymous access to such information, for
  565. retrieval purposes  is  generally  acceptable,  no  privacy  service  is
  566. REQUIRED.  As CAs may have access to information elements in the reposi-
  567. tory which anonymous users will not, it is RECOMMENDED that even  though
  568. anonymous  access  is  provided  to end entities, CAs should bind to the
  569. repository with a minimum of simple authentication.
  570.  
  571. For the LDAP repository modify service, profiled in section 8, there are
  572. some specific security considerations with respect to access control.
  573.  
  574. The CA MUST have access control permissions allowing it to:
  575.  
  576.   For CA entries:
  577.     - add, modify and delete all PKI attributes for its
  578.       own directory entry;
  579.     - add, modify and delete all values of these attributes.
  580.  
  581.   For CRL distribution point entries (if used):
  582.     - create, modify and delete entries of object class
  583.       cRLDistributionPoint immediately subordinate to its own
  584.       entry;
  585.     - add, modify and delete all attributes, and all values of
  586.       these attributes for these entries.
  587.  
  588.   For subscriber (end-entity) entries:
  589.     - add, modify and delete the attribute userCertificate and
  590.       all values of that attribute, issued by this CA
  591.       to/from these entries.
  592.  
  593.  The CA is the ONLY entity with these permissions.
  594.  
  595. An application providing LDAP repository read, LDAP  repository  search,
  596. or  LDAP  repository  modify service as defined in this specification is
  597. not REQUIRED to implement any additional security  features  other  than
  598. those described herein, however an implementation MAY do so.
  599.  
  600. 12.  References
  601.  
  602. [1]  Lightweight Directory Access  Protocol.  Y.  Yeong,  T.  Howes,  S.
  603.      Kille, RFC 1777, March 1995.
  604.  
  605.  
  606.  
  607. Boeyen, Howes & Richard                                        [Page 10]
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614. INTERNET DRAFT                                            September 1997
  615.  
  616.  
  617. [2]   The String  Representation  of  Standard  Attribute  Syntaxes.  T.
  618.      Howes, S. Kille, W. Yeong, C. Robbins, RFC 1778, March 1995.
  619.  
  620. [3]  Key Words for use  in  RFCs  to  Indicate  Requirement  Levels,  S.
  621.      Bradner, RFC 2119, March 1997.
  622.  
  623. 13.  Author's Address
  624.  
  625.  
  626.    Sharon Boeyen
  627.    Entrust Technologies Limited
  628.    750 Heron Road
  629.    Ottawa, Ontario
  630.    Canada K1V 1A7
  631.    boeyen@entrust.com
  632.  
  633.    Tim Howes
  634.    Netscape Communications Corp.
  635.    501 E. Middlefield Rd.
  636.    Mountain View, CA 94043
  637.    USA
  638.    howes@netscape.com
  639.  
  640.    Patrick Richard
  641.    Xcert Software Inc.
  642.    Suite 1001, 701 W. Georgia Street
  643.    P.O. Box 10145
  644.    Pacific Centre
  645.    Vancouver, B.C.
  646.    Canada V7Y 1C6
  647.    patr@xcert.com
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667. Boeyen, Howes & Richard                                        [Page 11]
  668.  
  669.  
  670.  
  671.