INTERNET-DRAFT                                            D. W. ChadwickPKIX WG                       		         University of Salford      Intended Category: Standards Track                               S. Legg                                                              Adacel TechnologiesExpires on 27 December 2002                                 27 June 2002                 Internet X.509 Public Key Infrastructure                    LDAP Schema and Syntaxes for PMIs                 <draft-ietf-pkix-ldap-pmi-schema-00.txt>Copyright (C) The Internet Society (2002). All Rights Reserved.STATUS OF THIS MEMOThis document is an Internet-Draft and is in full conformance withall the provisions of Section 10 of RFC2026 [1].Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.The list of Internet-Draft Shadow Directories can be accessed athttp://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<ietf-pkix@imc.org> or directly to the authors.ABSTRACTThis document describes LDAP schema features that are needed to support X.509 Privilege Management Infrastructures. Specifically, X.509 attribute types, object classes, matching rules, attribute value syntaxes and attribute value assertion syntaxes needed for PMIs are defined.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in thisdocument are to be interpreted as described in RFC 2119 [5].1. IntroductionLDAPv3 [4] servers are a natural repository for X.509 PMI components e.g. attribute certificate attributes, attribute certificate revocation lists and attribute authority entries. This [document/ID/standard] defines the LDAP subschema needed for storing X.509 PMI information in LDAPv3 servers and for accessing this information e.g. searching for it, updating it, and perform comparisons on it.2. Subschema PublishingLDAPv3 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. PMI Attributes and SyntaxesLDAP servers MAY store any type of PMI attribute, and LDAP clients MAY request them to be returned by adding them to the Search Request AttributeDescriptionList (either explicitly or implicity via requesting all user attributes). 3.1 Attribute Certificate AttributeThe attributeCertificateAttribute is defined in 17.2.1 of [9]. It is used to hold the attribute certificates of a user. The LDAPspecific encoding for values of this attribute is described in section 3.4.      attributeCertificateAttribute  ATTRIBUTE ::= {	WITH SYNTAX		AttributeCertificate	EQUALITY MATCHING RULE	attributeCertificateExactMatch	ID { joint-iso-ccitt(2) ds(5) attributeType(4)		attributeCertificate(58) } }The corresponding LDAP description is      ( 2.5.4.58 NAME 'attributeCertificateAttribute'      EQUALITY attributeCertificateExactMatch      SYNTAX 1.2.826.0.1.3344810.7.5 )3.2 Attribute Authority Certificate AttributeThe attribute authority attribute certificate is defined in 17.2.2 of [9]. The aAcertificate attribute holds the privileges of an attribute authority. The LDAPspecific encoding for values of this attribute is described in section 3.4.      aACertificate  ATTRIBUTE ::= {	WITH SYNTAX		AttributeCertificate	EQUALITY MATCHING RULE	attributeCertificateExactMatch	ID { joint-iso-ccitt(2) ds(5) attributeType(4)		aACertificate(61) } }The corresponding LDAP description is      ( 2.5.4.61 NAME 'aACertificate'      EQUALITY attributeCertificateExactMatch      SYNTAX 1.2.826.0.1.3344810.7.5 )3.3 Attribute Descriptor Certificate AttributeThe attributeDescriptorCertificate attribute is defined in 17.2.3 of [9]. The certificate is self signed by a source of authority and holds a description of the privilege and its delegation rules. The LDAPspecific encoding for values of this attribute is described in section 3.4.      attributeDescriptorCertificate  ATTRIBUTE ::= {	WITH SYNTAX		AttributeCertificate 	EQUALITY MATCHING RULE	attributeCertificateExactMatch 	ID { joint-iso-ccitt(2) ds(5) attributeType(4)		attributeDescriptorCertificate (62) } }The corresponding LDAP description is      ( 2.5.4.62 NAME 'attributeDescriptorCertificate'      EQUALITY attributeCertificateExactMatch      SYNTAX 1.2.826.0.1.3344810.7.5 )3.4 Attribute  Certificate SyntaxThe LDAP-specific encoding for a certificate value is the octet string that results from BER/DER-encoding an X.509 attribute certificate.  The following string states the OID assigned to this syntax:      (1.2.826.0.1.3344810.7.5 DESC 'Attribute Certificate' )Servers MUST preserve values in this syntax exactly as given when storing and retrieving them. Transformation of these values between storage and retrieval MUST NOT take place.3.5 Attribute Certificate Revocation List AttributeThe attributeCertificateRevocationList attribute is defined in section 17.2.4 of [9]. It holds a list of attribute certificates that have been revoked. The LDAP-specific encoding for values of this attribute is described in [2].      attributeCertificateRevocationList  ATTRIBUTE ::= {	WITH SYNTAX		CertificateList	EQUALITY MATCHING RULE	certificateListExactMatch	ID { joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } }The corresponding LDAP description is      ( 2.5.4.59 NAME 'attributeCertificateRevocationList'      EQUALITY certificateListExactMatch      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )3.6 Attribute Authority Certificate Revocation List AttributeThe attribute authority certificate revocation list attribute is defined in section 17.2.5 of [9]. It holds a list of AA certificates that have been revoked. The LDAP-specific encoding for values of this attribute is described in [2].      attributeAuthorityRevocationList  ATTRIBUTE ::= {	WITH SYNTAX		CertificateList	EQUALITY MATCHING RULE 	certificateListExactMatch	ID { joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } }The corresponding LDAP description is      ( 2.5.4.63 NAME 'attributeAuthorityRevocationList'      EQUALITY certificateListExactMatch      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )3.7 Delegation Path AttributeThe delegation path attribute contains delegation paths, each consisting of a sequence of attribute certificates      delegationPath	ATTRIBUTE	::= {	WITH SYNTAX	AttCertPath	ID ( joint-iso-ccitt(2) ds(5) attributeType(4) delPath (73) } )      AttCertPath	::=	SEQUENCE OF AttributeCertificateThe corresponding LDAP description is      ( 2.5.4.73 NAME 'delegationPath'      SYNTAX 1.2.826.0.1.3344810.7.21 )The following description is copied from X.509 (2000) [9]. "This attribute can be stored in the AA directory entry and would contain some delegation paths from that AA to other AAs. This attribute, if used, enables more efficient retrieval of delegated attribute certificates that form frequently used delegation 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 is unlikely to represent the complete set of delegation paths for any given AA."3.8 Delegation Path SyntaxThe LDAP-specific encoding for a delegation path value is the octet string that results from the BER/DER-encoding of a sequence of attribute certificates.  The following string states the OID assigned to this syntax:      ( 1.2.826.0.1.3344810.7.21 DESC 'Attribute certificate delegation        path' )Servers MUST preserve values in this syntax exactly as given when storing and retrieving them.4 PMI Matching RulesLDAP servers that support the storage of attributes with the AttributeCertificate syntax MUST support searching for entries containing specific attribute certificates, via the attributeCertificateExactMatch matching rule. LDAPv3Servers MAY support flexible matching for any attributes with the AttributeCertificate syntax via the attributeCertificateMatch matching rule or any of the matching rules defined for the certificate extensions. LDAPv3 servers SHOULD publish the matching rules that they do support in the matchingRule and matchingRuleUse operational attributes of the subschema subentry. If the server does support flexible matching (either via attributeCertificateMatch or some other matching rule), then the extensibleMatch filter of the Search request MUST be supported.  LDAPv3 clients MAY support the extensibleMatch filter of the Search operation, along one or more of the optional elements of attributeCertificateMatch or any of the certificate extension matching rules.The LDAP-specific (i.e. string) encodings for the assertion syntaxes defined in this document are specified by the Generic String Encoding Rules (GSER) [3]. The ABNF in this document for these assertion syntaxes is provided only as a convenience and is equivalent to the encoding specified by the application of [3]. (The only exception to this is the alternative simple endoding for attributeCertificatExactMatch.) Since the associated ASN.1 types for the assertion syntaxes described here may be extended in future editions of X.509 [9], the provided ABNF should be regarded as a snapshot in time. The LDAP-specific encoding for any extension to a syntax's underlying ASN.1 type can be determined from [3]. In the event that there is a discrepancy between the ABNF in this document and the encoding determined by [3], [3] is to be taken as definitive. 4.1 Attribute Certificate Exact MatchThe equality matching rule for all types of attribute withAttributeCertificate syntax is the attributeCertificateExactMatch,This is defined in 17.3.1 of [9]. It is reproduced below for theconvenience of the reader (but see Outstanding Issues).      attributeCertificateExactMatch  MATCHING-RULE ::= {	SYNTAX	AttributeCertificateExactAssertion	ID	{ joint-iso-ccitt(2) ds(5) mr (13)		    attributeCertificateExactMatch (45) } }      AttributeCertificateExactAssertion ::= SEQUENCE {	serialNumber	CertificateSerialNumber,	issuer		AttCertIssuer }      CertificateSerialNumber	::= INTEGER      AttCertIssuer ::= 	[0]	SEQUENCE {       issuerName			GeneralNames  OPTIONAL,      baseCertificateID	[0]	IssuerSerial  OPTIONAL,      objectDigestInfo	[1]	ObjectDigestInfo  OPTIONAL }  -- At least one component shall be present      IssuerSerial  ::=  SEQUENCE {	issuer		GeneralNames,	serial		CertificateSerialNumber,	issuerUID		UniqueIdentifier OPTIONAL }      UniqueIdentifier ::= BIT STRING      ObjectDigestInfo    ::= SEQUENCE {	digestedObjectType  ENUMERATED {		publicKey       		(0),		publicKeyCert        	(1),		otherObjectTypes     	(2) },	otherObjectTypeID   	OBJECT IDENTIFIER  OPTIONAL,	digestAlgorithm     	AlgorithmIdentifier,	objectDigest        	BIT STRING }The LDAP definition for the above matching rule is:        ( 2.5.13.45 NAME 'attributeCertificateExactMatch'         SYNTAX 1.2.826.0.1.3344810.7.6)The syntax definition is:         (1.2.826.0.1.3344810.7.6 DESC 'Attribute certificate exact          assertion (serial number and issuer details)' )The LDAP-specific encoding of an assertion value of this syntax is a choice between - the GSER encoding <GSERAttributeCertificateExactAssertion> defined by [3] and - the simple encoding <SimpleCertificateExactAssertion> defined in [2]. The full syntax is described by the following Augmented BNF [10]:AttributeCertificateExactAssertion =                             GSERAttributeCertificateExactAssertion /                            SimpleCertificateExactAssertion GSERAttributeCertificateExactAssertion = "{" sp acea-serialNumber ","                                         sp acea-issuer                                         sp "}"acea-serialNumber  = id-serialNumber msp CertificateSerialNumberacea-issuer        = id-issuer       msp AttCertIssuer