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