[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 03 04 05 06 07 08 RFC 2559

PKIX Working Group                           Sharon Boeyen (Entrust)
draft-ietf-pkix-ipki2opp-03.txt              Tim Howes (Netscape)
Expires in 6 months                          Patrick Richard (Xcert)
                                             September 1997


                   Internet Public Key Infrastructure
                      Operational Protocols - LDAP
                   <draft-ietf-pkix-ipki2opp-03.txt>



1.  Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working  docu-
ments  of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working docu-
ments as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as  reference  material
or to cite them other than as "work in progress."

To learn the current status of  any  Internet-Draft,  please  check  the
"1id-abstracts.txt"  listing  contained  in  the  Internet-Drafts Shadow
Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
ftp.isi.edu (US West Coast).

2.  Abstract

The protocol described in this document is designed to satisfy  some  of
the  operational requirements within the Internet Public Key Infrastruc-
ture (IPKI).  Specifically, this document addresses requirements to pro-
vide access to Public Key Infrastructure (PKI) repositories for the pur-
poses of retrieving PKI information and managing that same  information.
The  mechanism  described  in  this document is based on the Lightweight
Directory Access Protocol (LDAP) version 2, defined  in  RFC  1777,  and
defines  a  profile of that protocol for use within the IPKI. Additional
mechanisms addressing PKIX  operational  requirements  are  specified  in
separate documents.

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"  in
this document are to be interpreted as described in RFC 2119.

Please send comments on this document to the  ietf-pkix@tandem.com  mail
list.



Boeyen, Howes & Richard                                         [Page 1]


INTERNET DRAFT                                            September 1997


3.  Introduction

This specification is part of a multi-part standard for development of a
Public  Key  Infrastructure  (PKI)  for the Internet. This specification
addresses requirements to provide retrieval of  X.509  PKI  information,
including  certificates  and  CRLs from a repository. This specification
also addresses requirements to add, delete and modify PKI information in
a repository. A profile based on the LDAP version 2 protocol is provided
to satisfy these requirements.

4.  Model

The PKI components, as defined in PKIX Part 1,  which  are  involved  in
PKIX operational protocol interactions include:

   -  End Entities
   -  Certification Authorities (CA)
   -  Repository

End entities and CAs using LDAPv2, retrieve  PKI  information  from  the
repository using a subset of the LDAPv2 protocol.

CAs populate the repository with PKI information using a subset  of  the
LDAPv2 protocol.

5.  Lightweight Directory Access Protocol (LDAP)

The following sections examine the retrieval of PKI information  from  a
repository  and management of PKI information in a repository. A profile
of the LDAPv2 protocol is defined for providing these services.

Section 6 satisfies the requirement to retrieve PKI information (a  cer-
tificate,  CRL,  or other information of interest)  from an entry in the
repository, where the retrieving entity (either an end entity or  a  CA)
has  knowledge  of  the  name  of  the entry. This is termed "repository
read".

Section 7 satisfies the same requirement as 6 for  the  situation  where
the  name  of the entry is not known, but some other related information
which may optionally be used as a filter against  candidate  entries  in
the repository, is known.  This is termed "repository search".

Section 8 satisfies the requirement of CAs to add, delete and modify PKI
information  information  (a  certificate,  CRL, or other information of
interest)in the repository. This is termed "repository modify".

The subset of LDAPv2 needed  to  support  each  of  these  functions  is
described  below. Note that the repository search service  is a superset



Boeyen, Howes & Richard                                         [Page 2]


INTERNET DRAFT                                            September 1997


of the repository read service  in terms  of  the  LDAPv2  functionality
needed.

Note  that all tags are implicit by default  in  the  ASN.1  definitions
that follow.

6.  LDAP Repository Read

To retrieve information from an entry corresponding to  the  subject  or
issuer  name  of a certificate, requires a subset of the following three
LDAP operations:

  BindRequest (and BindResponse)
  SearchRequest (and SearchResponse)
  UnbindRequest

The subset of each REQUIRED operation is given below.

6.1.  Bind

6.1.1.  Bind Request

The full LDAP v2 Bind Request is defined in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
the following subset of this operation:

   BindRequest ::=
     [APPLICATION 0] SEQUENCE {
        version      INTEGER (2),
        name         LDAPDN, -- MUST accept NULL LDAPDN
        simpleauth [0] OCTET STRING  -- MUST accept NULL simple
        }

An application providing a LDAP repository read  service  MAY  implement
other aspects of the BindRequest as well.

Different services may have different security requirements.  Some  ser-
vices  may  allow  anonymous  search, others may require authentication.
Those services allowing anonymous search may choose only to allow search
based on certain criteria and not others.

A LDAP repository read service SHOULD implement some level of  anonymous
search  access.  A  LDAP repository read service MAY implement authenti-
cated search access.






Boeyen, Howes & Richard                                         [Page 3]


INTERNET DRAFT                                            September 1997


6.1.2.  Bind Response

The full LDAPv2 BindResponse is described in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
this  entire protocol element, though only the following error codes may
be returned from a Bind operation:

  success                      (0),
  operationsError              (1),
  protocolError                (2),
  authMethodNotSupported       (7),
  noSuchObject                 (32),
  invalidDNSyntax              (34),
  inappropriateAuthentication  (48),
  invalidCredentials           (49),
  busy                         (51),
  unavailable                  (52),
  unwillingToPerform           (53),
  other                        (80)

6.2.  Search

6.2.1.  Search Request

The full LDAPv2 SearchRequest is defined in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
the following subset of the SearchRequest.

   SearchRequest ::=
     [APPLICATION 3] SEQUENCE {
        baseObject     LDAPDN,
        scope             ENUMERATED {
                          baseObject   (0),
                                     },
        derefAliases   ENUMERATED {
                          neverDerefAliases   (0),
                                  },
        sizeLimit      INTEGER (0),
        timeLimit      INTEGER (0),
        attrsOnly      BOOLEAN, -- FALSE only
        filter         Filter,
        attributes     SEQUENCE OF AttributeType
                            }

   Filter ::=
     CHOICE {



Boeyen, Howes & Richard                                         [Page 4]


INTERNET DRAFT                                            September 1997


       present        [7] AttributeType, -- "objectclass" only
              }

This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"  opera-
tion:  a  base  object search with a filter testing for the existence of
the objectClass attribute.

An application providing a LDAP repository read  service  MAY  implement
other aspects of the SearchRequest as well.

6.2.2.

The full LDAPv2 SearchResponse is defined in RFC 1777.

An application providing a LDAP repository read service over LDAPv2 MUST
implement the full SearchResponse.

6.3.  Unbind

The full LDAPv2 UnbindRequest is defined in RFC 1777.

An application providing a LDAP repository read service  MUST  implement
the full UnbindRequest.

7.  LDAP Repository Search

To search ,using arbitrary criteria, for an entry in a  repository  con-
taining a certificate, CRL, or other information of interest, requires a
subset of the following three LDAP operations:

  BindRequest (and BindResponse)
  SearchRequest (and SearchResponse)
  UnbindRequest

The subset of each operation REQUIRED is given below.

7.1.  Bind

The BindRequest and BindResponse subsets needed are the  same  as  those
described in Section 6.1.

The full LDAP v2 Bind Request is defined in RFC 1777.

7.2.  Search

7.2.1.  Search Request

The full LDAPv2 SearchRequest is defined in RFC 1777.



Boeyen, Howes & Richard                                         [Page 5]


INTERNET DRAFT                                            September 1997


An application providing a LDAP repository search service MUST implement
the following subset of the SearchRequest protocol unit.

   SearchRequest ::=
     [APPLICATION 3] SEQUENCE {
        baseObject     LDAPDN,
        scope          ENUMERATED {
                            baseObject     (0),
                            singleLevel    (1),
                            wholeSubtree   (2)
                                  },
        derefAliases   ENUMERATED {
                            neverDerefAliases     (0),
                                  },
        sizeLimit      INTEGER (0 .. maxInt),
        timeLimit      INTEGER (0 .. maxInt),
        attrsOnly      BOOLEAN,  -- FALSE only
        filter         Filter,
        attributes     SEQUENCE OF AttributeType
                             }

All aspects of the SearchRequest MUST be supported, except for the  fol-
lowing:

- Only the neverDerefAliases value of derefAliases needs
  to be supported

- Only the FALSE value for attrsOnly needs to be supported

This subset provides a more general search capability. It is a  superset
of the SearchRequest subset defined in Section 6.2.1. The elements added
to this service are:

- singleLevel and wholeSubtree scope needs to be supported

- sizeLimit is included

- timeLimit is included

- Enhanced filter capability

An application providing a LDAP repository search service MAY  implement
other aspects of the SearchRequest as well.

7.2.2.  Search Response

The full LDAPv2 SearchResponse is defined in RFC 1777.




Boeyen, Howes & Richard                                         [Page 6]


INTERNET DRAFT                                            September 1997


An application providing a LDAP repository search  service  over  LDAPv2
MUST implement the full SearchResponse.

7.3.  Unbind

An application providing a LDAP repository search service MUST implement
the full UnbindRequest.

8.  LDAP Repository Modify

To add, delete and modify PKI information in  a  repository  requires  a
subset of the following LDAP operations:

  BindRequest (and BindResponse)
  ModifyRequest (and ModifyResponse)
  AddRequest (and AddResponse)
  DelRequest (and DelResponse
  UnbindRequest

The subset of each operation REQUIRED is given below.

8.1.  Bind

The full LDAP v2 Bind Request is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the following subset of this operation:

   BindRequest ::=
     [APPLICATION 0] SEQUENCE {
        version      INTEGER (2),
        name         LDAPDN,
        simpleauth [0] OCTET STRING
        }

A LDAP repository modify service MUST implement authenticated access.

The BindResponse subsets needed are the same as those described in  Sec-
tion 6.1.2.

8.2.  Modify

8.2.1.  Modify Request

The full LDAPv2 ModifyRequest is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the following subset of the ModifyRequest protocol unit.



Boeyen, Howes & Richard                                         [Page 7]


INTERNET DRAFT                                            September 1997


   ModifyRequest ::=
     [APPLICATION 6] SEQUENCE {
    object         LDAPDN,
    modification   SEQUENCE OF SEQUENCE {
                     operation     ENUMERATED {
                                     add     (0),
                                     delete  (1)
                                   },
                     modification  SEQUENCE {
                                   type   AttributeType,
                                   values SET OF
                                          AttributeValue
                                   }
                   }
     }

All aspects of the ModifyRequest MUST be supported, except for the  fol-
lowing:

- Only the add and delete values of operation need to be supported

8.2.2.  Modify Response

The full LDAPv2 ModifyResponse is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full ModifyResponse.

8.3.  Add

8.3.1.  Add Request

The full LDAPv2 AddRequest is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full AddRequest.

8.3.2.  Add Response

The full LDAPv2 AddResponse is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full AddResponse.

8.4.  Delete






Boeyen, Howes & Richard                                         [Page 8]


INTERNET DRAFT                                            September 1997


8.4.1.  Delete Request

The full LDAPv2 DelRequest is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full DelRequest.

8.4.2.  Delete Response

The full LDAPv2 DelResponse is defined in RFC 1777.

An application providing a LDAP repository modify service MUST implement
the full DelResponse.

8.5.  Unbind

An application providing a LDAP repository modify service MUST implement
the full UnbindRequest.

9.  Non-standard attribute value encodings

When conveyed in LDAP requests and results, attributes defined in  X.500
are  to be encoded using string representations defined in RFC 1778, The
String Representation of  Standard  Attribute  Syntaxes.   These  string
encodings  were  based  on  the  attribute definitions from X.500(1988).
Thus, the string representations of the PKI information elements are for
version  1  certificates  and  version  1  revocation lists.  Since this
specification uses version  3  certificates  and  version  2  revocation
lists,  as defined in X.509(1997), the RFC 1778 string encoding of these
attributes is inappropriate.

For this reason, these attributes MUST be encoded using a syntax similar
to the syntax  "Undefined" from section 2.1 of RFC 1778: values of these
attributes are encoded as if they were values of  type  "OCTET  STRING",
with  the  string  value  of  the encoding being the DER-encoding of the
value itself.  For example, when writing a userCertificate to the  repo-
sitory, the CA generates a DER-encoding of the certificate and uses that
encoding as the value of  the  userCertificate  attribute  in  the  LDAP
Modify  request.This  encoding  style  is  consistent  with the encoding
scheme proposed for LDAPv3, which is now being defined within the IETF.

10.  Transport

An application providing a LDAP repository read service, LDAP repository
search  service,  or  LDAP repository modify service MUST support LDAPv2
transport over TCP, as defined in Section 3.1 of RFC 1777.

An application providing a LDAP repository read service, LDAP repository



Boeyen, Howes & Richard                                         [Page 9]


INTERNET DRAFT                                            September 1997


search  service,  or  LDAP  repository modify service MAY support LDAPv2
transport over other reliable transports as well.

11.  Security Considerations

Since the elements of information which are key to the PKI service (cer-
tificates  and CRLs) are both digitally signed pieces of information, no
additional integrity service is REQUIRED.  As neither  information  ele-
ment  need  be kept secret and anonymous access to such information, for
retrieval purposes  is  generally  acceptable,  no  privacy  service  is
REQUIRED.  As CAs may have access to information elements in the reposi-
tory which anonymous users will not, it is RECOMMENDED that even  though
anonymous  access  is  provided  to end entities, CAs should bind to the
repository with a minimum of simple authentication.

For the LDAP repository modify service, profiled in section 8, there are
some specific security considerations with respect to access control.

The CA MUST have access control permissions allowing it to:

  For CA entries:
    - add, modify and delete all PKI attributes for its
      own directory entry;
    - add, modify and delete all values of these attributes.

  For CRL distribution point entries (if used):
    - create, modify and delete entries of object class
      cRLDistributionPoint immediately subordinate to its own
      entry;
    - add, modify and delete all attributes, and all values of
      these attributes for these entries.

  For subscriber (end-entity) entries:
    - add, modify and delete the attribute userCertificate and
      all values of that attribute, issued by this CA
      to/from these entries.

 The CA is the ONLY entity with these permissions.

An application providing LDAP repository read, LDAP  repository  search,
or  LDAP  repository  modify service as defined in this specification is
not REQUIRED to implement any additional security  features  other  than
those described herein, however an implementation MAY do so.

12.  References

[1]  Lightweight Directory Access  Protocol.  Y.  Yeong,  T.  Howes,  S.
     Kille, RFC 1777, March 1995.



Boeyen, Howes & Richard                                        [Page 10]


INTERNET DRAFT                                            September 1997


[2]   The String  Representation  of  Standard  Attribute  Syntaxes.  T.
     Howes, S. Kille, W. Yeong, C. Robbins, RFC 1778, March 1995.

[3]  Key Words for use  in  RFCs  to  Indicate  Requirement  Levels,  S.
     Bradner, RFC 2119, March 1997.

13.  Author's Address


   Sharon Boeyen
   Entrust Technologies Limited
   750 Heron Road
   Ottawa, Ontario
   Canada K1V 1A7
   boeyen@entrust.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   howes@netscape.com

   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6
   patr@xcert.com



















Boeyen, Howes & Richard                                        [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/