draft-ietf-pkix-ldap-pki-schema-00.txt

PKIX的RFC英文文档

INTERNET-DRAFT                                            D. W. Chadwick
PKIX WG                       		         University of Salford      
Intended Category: Standards Track                               S. Legg         
                                                     Adacel Technologies
                                                            26 June 2002


                 Internet X.509 Public Key Infrastructure
                    LDAP Schema and Syntaxes for PKIs
                <draft-ietf-pkix-ldap-pki-schema-00.txt>


Copyright (C) The Internet Society (2001). All Rights Reserved.

STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026 [1].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents 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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Comments and suggestions on this document are encouraged. Comments on 
this document should be sent to the PKIX working group discussion list
<[e-mail]> or directly to the authors.

This Internet-Draft expires on 26 December 2002.


ABSTRACT

This document describes LDAP schema features that are needed to support 
X.509 Public Key Infrastructures. Specifically, X.509 attribute types, 
object classes, matching rules, attribute value syntaxes and attribute 
value assertion syntaxes needed for PKIs are defined.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].


1. Introduction

RFC2587 [8] describes some of the PKI subschema applicable to LDAPv2 [2] 
servers, specifically the public key certificate related attribute types 
and object classes that MUST or MAY be supported. RFC 2256 [17] 
describes some of the PKI related subschema elements for LDAPv3 [4] 
servers. This [document/ID/standard] supercedes both RFC2587 and RFC 
2256 and provides the complete PKI subschema for LDAP v3 [4] servers.


2. Subschema Publishing

LDAPv3 allows the subschema supported by a server to be published in a 
subschema subentry. Clients following this profile which support the 
Search operation containing an extensible matching rule SHOULD use the 
subschemaSubentry attribute in the root DSE to find the 
subschemaSubentry, and SHOULD use the matchingRule and matchingRuleUse 
operational attributes in the subschema subentry in order to determine 
whether the server supports the various matching rules described below. 
Servers that support extensible matching SHOULD publish the matching 
rules they support in the matchingRule and matchingRuleUse operational 
attributes.


3. PKI Attributes and Syntaxes

3.1  userCertificate Attribute

The userCertificate attribute type contains the public-key certificates 
a user has obtained from one or more CAs. The LDAPspecific encoding for 
values of this attribute is described in section 3.3. 

    ( 2.5.4.36 NAME 'userCertificate'
      EQUALITY certificateExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

3.2  cACertificate Attribute

The cACertificate attribute of a CA's directory entry shall be used to 
store self-issued certificates (if any) and certificates issued to this 
CA by CAs in the same realm as this CA. The LDAP-specific encoding for 
values of this attribute is described in section 3.3. 

    ( 2.5.4.37 NAME 'cACertificate'
EQUALITY certificateExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

3.3  Certificate Syntax

The LDAP-specific encoding for a certificate value is the octet string 
that results from the BER and/or DER-encoding of an X.509 public key 
certificate.  The following string states the OID assigned to this 
syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'A BER and/or DER encoded 
public key certificate' )

Servers MUST preserve values in this syntax exactly as given to them by 
the client, when storing and retrieving certificates. Transformation of 
these values between storage and retrieval MUST NOT take place.

Note. The BNF notation in RFC 1778 [12] for "User Certificate" MUST NOT 
be used. Values in this syntax MUST be transferred as BER and/or DER 
encoded octets.

3.4 authorityRevocationList Attribute

A value of this attribute is a list of CA certificates that are no 
longer valid.  The LDAP-specific encoding for values of this attribute 
is described in section 3.7. 

    ( 2.5.4.38 NAME 'authorityRevocationList'
EQUALITY certificateListExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

3.5 certificateRevocationList Attribute

A value of this attribute is a list of user certificates that are no 
longer valid.  The LDAP-specific encoding for values of this attribute 
is described in section 3.7.

    ( 2.5.4.39 NAME 'certificateRevocationList'
EQUALITY certificateListExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

3.6 deltaRevocationList Attribute

This attribute contains a list of revoked certificates (user or CA) that 
is an addition to a previous certificate revocation list.  The LDAP-
specific encoding for values of this attribute is described in section 
3.7.  

    ( 2.5.4.53 NAME 'deltaRevocationList'
EQUALITY certificateListExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

3.7 Certificate List Syntax

The LDAP-specific encoding for a certificate list value is the octet 
string that results from BER/DER-encoding an X.509 certificate 
revocation list.  The following string states the OID assigned to this 
syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )

Servers MUST preserve values in this syntax exactly as given when 
storing and retrieving them. The BNF notation in RFC 1778 [12] for 
"Authority Revocation List" MUST NOT be used.

3.8 crossCertificatePair Attribute

The following definition is taken from X.509(2000) [9]. The term forward 
was used in earlier editions of X.509 for issuedToThisCA and the term 
reverse was used in earlier editions for issuedByThisCA.

The issuedToThisCA elements of the crossCertificatePair attribute of a CA's 
directory entry shall be used to store all, except self-issued 
certificates, issued to this CA.  Optionally, the issuedByThisCA elements 
of the crossCertificatePair attribute, of a CA's directory entry may contain 
a subset of certificates issued by this CA to other CAs. If a CA issues 
a certificate to another CA, and the subject CA is not a subordinate to 
the issuer CA in a hierarchy, then the issuer CA shall place that 
certificate in the issuedByThisCA element of the crossCertificatePair attribute 
of its own directory entry.  When both the issuedToThisCA and the 
issuedByThisCA elements are present in a single attribute value, issuer 
name in one certificate shall match the subject name in the other and 
vice versa, and the subject public key in one certificate shall be 
capable of verifying the digital signature on the other certificate and 
vice versa. 

The LDAP-specific encoding for values of this attribute is described in 
section 3.9. 

    ( 2.5.4.40 NAME 'crossCertificatePair'
EQUALITY certificatePairExactMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )

3.9	 Certificate Pair Syntax

The LDAP-specific encoding for a certificate pair value is the octet 
string that results from the BER/DER-encoding an X.509 public key 
certificate pair.  The following string states the OID assigned to this 
syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )

Servers MUST preserve values in this syntax exactly as given when 
storing and retrieving them. The BNF notation in RFC 1778 [12] for 
"Certificate Pair" MUST NOT be used. Servers must preserve values in 
this syntax exactly as given when storing and retrieving them.

3.10	PKI Path Attribute

The PKI path attribute is used to store certification paths, each 
consisting of a sequence of cross-certificates. The LDAP-specific 
encoding for values of this attribute is described in section 3.11.  


( 2.5.4.70 NAME 'pkiPath'
      SYNTAX 1.2.826.0.1.3344810.7.19)

The following description is copied from X.509 (2000) [9]. 

"This attribute can be stored in the CA directory entry and would 
contain some certification paths from that CA to other CAs. This 
attribute, if used, enables more efficient retrieval of cross-
certificates that form frequently used certification paths. As 
such there are no specific requirements for this attribute to be 
used and the set of values that are stored in the attribute will 
likely not represent the complete set of forward certification 
paths for any given CA." 


3.11  PKI Path Syntax

The LDAP-specific encoding for a PKI path value is the octet string that 
results from the BER/DER-encoding of a sequence of cross certificates.  
The following string states the OID assigned to this syntax:

      ( 1.2.826.0.1.3344810.7.19 DESC 'PKI Path' )

Servers MUST preserve values in this syntax exactly as given when 
storing and retrieving them.

3.12  CPS Attribute 

The CPS attribute is used to store a certification authority's 
certification practice statement. 

(1.2.826.0.1.3344810.1.1.31 NAME 'cps'
SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

3.13  CPS Pointer Attribute

The CPS pointer attribute is used to store a pointer to a certification 
authority's certification practice statement in the form of a URI. 

(1.2.826.0.1.3344810.1.1.32 NAME 'cpsPointer'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

3.14 Certificate Policy Attribute 

The certificatePolicy attribute is used to store information about a 
certification authority's certificate policy (either directly or 
indirectly). The LDAP-specific encoding for values of this attribute is 
described in section 3.15.

( 2.5.4.69 NAME 'certificatePolicy'
EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.2.826.0.1.3344810.7.20)

3.15 Certificate Policy Syntax

The LDAP-specific encoding for a certificate policy value is the octet 
string that results from the BERencoding of a sequence of the policy 
object identifier and policy information.  The following string states 
the OID assigned to this syntax:

      ( 1.2.826.0.1.3344810.7.20 DESC 'CA certificate policy' )

3.16  Certificate Policy Pointer Attribute

The CP pointer attribute is used to store a pointer to a certification 
authority's certificate policy in the form of a URI. 

(1.2.826.0.1.3344810.1.1.33 NAME 'cpPointer'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

3.17  Supported Algorithms Attribute

This attribute is used to support the selection of an algorithm for use 
when communicating with a remote end entity using certificates. The 
LDAP-specific encoding for values of this attribute is described in 
section 3.17.

    ( 2.5.4.52 NAME 'supportedAlgorithms'
EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )

3.18 Supported Algorithm Syntax

The LDAP-specific encoding for a supported algorithm value is the octet 
string that results from the BER encoding of a SupportedAlgorithm ASN.1 
value.  The following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )