Internet-Draft D.W.Chadwick PKIX WG University of Salford Intended Category: Standards Track Expires: 8 January 2001 8 July 2000 Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs 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. This Internet-Draft expires on 6 January 2001. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the PKIX working group discussion list: or directly to the author. ABSTRACT This document describes LDAP schema features in addition to RFC 2587 that are needed to support a Privilege Management Infrastructure and a Public Key Infrastructure. 1. Introduction RFC2587 [8] describes some of the subschema applicable to LDAPv2 servers [2], specifically the public key certificate related attribute types and object classes that MUST or MAY be supported. This [document/ID/standard] does not revoke any of the contents of RFC2587, but supplements them. RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2 servers and MUST be supported by LDAPv3 servers. Neither RFC2587 nor the user schema for LDAPv3 (RFC2256 [3]) nor the attribute syntax definitions for LDAPv3 (RFC2252 [7]) describe in detail the matching rules that should be supported by LDAP servers, nor do they describe how attribute value assertions for each matching rule should be encoded in filter items. Finally none of these documents mention attributeCertificates or any schema to support privilege management, since these concepts superseded the publishing of the RFCs. 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 which support extensible matching SHOULD publish the matching rules they support in the matchingRule and matchingRuleUse operational attributes. 3. Public Key Certificate Matching Rules X.509 [9] supports both equality and flexible certificate matching rules by the server, via the certificateExactMatch and certificateMatch MATCHING-RULEs respectively. (For example, a client may flexibly search for certificates with a particular validity time, key usage, policy or other field.) LDAPv3 servers MUST support the certificateExactMatch matching rule. Clients MAY support certificateExactMatch values for equalityMatch filters. LDAPv3 servers SHOULD support the certificateMatch matching rule. If the server does support flexible matching (either via certificateMatch or some other matching rule), then the extensibleMatch filter of the Search request MUST be supported. Clients MAY support the extensibleMatch filter and one or more of the optional elements of certificateMatch. Neither of the above matching rules are mentioned in the LDAPv3 standards [3 or 7], and only the equality matching rule is mentioned in [8], but nowhere is it defined for LDAP servers. It is expected that future revisions of the LDAPv3 documents will include these definitions, which are described below. 3.1 Certificate Exact Match Certificate exact match is defined in 11.3.1 of [9]. The string description of the certificateExactMatch matching rule is: ( 2.5.13.34 NAME 'certificateExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.x ) Note. x is still to be allocated The LDAP syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.x DESC 'Certificate Serial Number and Issuer' ) Values in this syntax are encoded as an integer, a dollar ($) separator and a string encoding of the distinguished name of the issuing CA. 3.2 Certificate Match Certificate match is defined in 11.3.2 of [9]. The string description of the certificateMatch matching rule is: ( 2.5.13.35 NAME 'certificateMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.y ) Note. y is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Certificate Assertion' ) The ASN.1 for certificateAssertion is defined in 11.3.2 of [9], as are the semantics of each of its component types. The LDAP string encoding of this is: - an optional integer representing the certificate serial number, - followed by a dollar separator ($), - followed by an optional string encoding of the distinguished name of the issuing CA, - followed by a dollar separator, - followed by an optional string encoding of the subject key identifier octet string using hex character encoding, - followed by a dollar separator, - followed by an optional string encoding of the authority key identifier octet string using hex character encoding, (Editor's note. This is a subset of the X.509 allowed values for authority key identifier. Is this the best choice to make?) - followed by a dollar separator, - followed by an optional string representation of the generalised time of the certificate validity (in the format yyyymmddhhmmssZ as specified in RFC 2252), - followed by a dollar separator, - followed by an optional string representation of the generalised time for the private key validity, - followed by a dollar separator - followed by an optional string encoding of the object identifier of the subject public key algorithm, - followed by a dollar separator, - followed by an optional string encoding of the key usage bit string according to RFC 2252 e.g. '0101111101'B. The first (left most) bit represents key usage digital signature (bit 0). Note that if less bits are present than defined in the keyUsage field it is assumed that those right most bits that are not present have the value 0, - followed by a dollar separator, - followed by an optional string encoding of the subjectAltName type using the following keywords "rfc822", "dns", "x400", "ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the object identifier the other name form type being sought if it is none of the above, - followed by a dollar separator, - followed by an optional string encoding of one or more object identifiers of certificate policies each separated by "+" character if there is more than one, - followed by a dollar separator, - followed by an optional string encoding of the distinguished name of the entity to which a certification path cannot be made - followed by a dollar separator, - followed by an optional string encoding of the distinguished name of the subject, - followed by a dollar separator, - followed by an optional string encoding of the name constraints as follows: the string "permitted" followed by a "+" followed by the type of name using one of the keywords "rfc822", "dns", "x400", "ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the object identifier the name type, followed by a "+" followed by a string encoding of the name, followed by "excluded", a "+", the type of name, a "+" and the string encoding of the name of the excluded subtree, Editor's note 1. With proper BNF for this we can miss out either the permitted or excluded components Editor's note 2. This is a subset of the allowed values of name contstraints (minimum and maximum are missing). Do we want to add these? - and finally ending with a dollar separator. Where any optional field is missing this is indicated by the presence of two contiguous dollar separators (or if the certificate serial number is missing a certificate assertion that starts with a dollar separator). Editors Notes. 1. We need to decide whether searching for cross certificates should be supported by this LDAPv3 profile or not. If we decide that this should be supported, then we will need to define the matching rules to be supported and the string encodings for the assertion syntaxes (in fact this is not too difficult since they are similar to certificate matching rules and AVAs). 2. We need to decide if userSMIMECertificates should also be supported as part of this profile or not. 4. Public Key Certificate Revocation List Matching Rules X.509[9] defines both equality and flexible matching rules for CRLs, via the certificateListExactMatch and certificateListMatch MATCHING- RULEs respectively. LDAPv3 servers MUST support the certificateListExactMatch matching rule. Clients MAY support certificateListExactMatch values for equalityMatch filters. LDAPv3 servers MAY support the certificateListMatch matching rule. If the server does support flexible matching (either via certificateListMatch or some other matching rule), then the extensibleMatch filter of the Search request MUST be supported. Clients MAY support the extensibleMatch filter and one or more of the optional elements of certificateListMatch. 4.1 Certificate List Exact Match Certificate List exact match is defined in 11.3.5 of [9]. The string description of the certificateListExactMatch matching rule is: ( 2.5.13.38 NAME 'certificateListExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.z ) Note. z is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.z DESC 'Issuer name, time and distribution point name' ) Values in this syntax are encoded as a string encoding of a distinguished name, a dollar ($) separator, a string representation of generalised time, a dollar separator and an optional string encoding of the distinguished name of the distribution point. (Editor's Note. The latter DN encoding for a distribution point name is a subset of the allowed variants, which can be a generalName or an RDN. Should this simplification be allowed?) 4.2 Certificate List Match Certificate List match is defined in 11.3.6 of [9]. The string description of the certificateListMatch matching rule is: ( 2.5.13.39 NAME 'certificateListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.w ) Note. w is still to be allocated The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' ) The ASN.1 for certificateListAssertion is defined in 11.3.6 of [9]. Values in this syntax are encoded as: - an optional string encoding of the distinguished name of the issuer, - followed by a dollar ($) separator, - followed by an optional string encoding of an integer representing the minimum CRL number, - followed by a dollar separator, - followed by an optional string encoding of an integer representing the maximum CRL number, - followed by a dollar separator, - followed by an optional string encoding of the reason flags bit string according to RFC 2252 e.g. '010111110'B. The first (left most) bit represents unused reason flag (bit 0). Note that if less bits are present than defined in the reason flags field it is assumed that those right most bits that are not present have the value 0, - followed by a dollar separator, - followed by an optional string representation of the generalised time for the CRL validity, - followed by an optional string encoding of the authority key identifier octet string using hex character encoding, (Editor's note. This is a subset of the X.509 allowed values for authority key identifier. Is this the best choice to make?) - and ending with a dollar separator. 5. Privilege Management Schema LDAP servers MAY store any type of attribute with the AttributeCertificate syntax, and LDAP clients MAY request them to be returned by adding them to the Search Request AttributeDescriptionList (either explicitly or implicity via requesting all attributes). LDAP servers that do 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. 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. For the convenience of the reader, some of the subchema definitions to support attribute certificates are produced below, but it is anticipated that these will be moved to a subsequent revision of the LDAPv3 standard. 5.1 PMI Attributes The attributeCertificateAttribute holds the privileges of a user. attributeCertificateAttribute ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) attributeCertificate(58) } The aAcertificate holds the privileges of an attribute authority aACertificate ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aACertificate(61} The attributeDescriptorCertificate is self signed by a source of authority and holds a description of the privilege and its delegation rules. attributeDescriptorCertificate ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING RULE attributeCertificateExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) attributeDescriptorCertificate (62) } The attributeCertificateRevocationList holds a list of attribute certificates that have been revoked. attributeCertificateRevocationList ATTRIBUTE ::= { WITH SYNTAX CertificateList EQUALITY MATCHING RULE certificateListExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } The attributeAuthorityList holds a list of AA certificates that have been revoked. attributeAuthorityRevocationList ATTRIBUTE ::= { WITH SYNTAX CertificateList EQUALITY MATCHING RULE certificateListExactMatch ID joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } 5.2 PMI Object Classes pmiUser OBJECT-CLASS ::= { -- a privilege holder SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {attributeCertificateAttribute} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24)} pmiAA OBJECT-CLASS ::= { -- an attribute authority SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {aACertificate | attributeCertificateRevocationList | attributeAuthorityRevocationList} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25)} pmiSOA OBJECT-CLASS ::= { -- a PMI Source of Authority SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {attributeCertificateRevocationList | attributeAuthorityRevocationList | attributeDescriptorCertificate} ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26)} 5.3 PMI Matching Rules 5.3.1 Attribute Certificate Exact Match The equality matching rule for all types of attribute with AttributeCertificate syntax is the attributeCertificateExactMatch, This is defined in 17.3.1 of [9]. It is reproduced below for the convenience of the reader. attributeCertificateExactMatch MATCHING-RULE ::= { SYNTAX AttributeCertificateExactAssertion ID joint-iso-ccitt(2) ds(5) mr (13) attributeCertificateExactMatch (45) } AttributeCertificateExactAssertion ::= SEQUENCE { serialNumber CertificateSerialNumber, issuer IssuerSerial } CertificateSerialNumber ::= INTEGER IssuerSerial ::= SEQUENCE { issuer GeneralNames, serial CertificateSerialNumber, issuerUID UniqueIdentifier OPTIONAL } UniqueIdentifier ::= BIT STRING The LDAP definition for the above matching rule is: ( 2.5.13.45 NAME 'attributeCertificateExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.m ) Note that the value of m is still to be allocated. The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.m DESC 'Attribute certificate serial number and public key issuer and serial number' ) Values in this syntax are encoded as a string encoding of an integer (the serial number of the attribute certificate), a dollar ($) separator, a string representation of the distinguished name of the CA of the issuer, a dollar separator, a string encoding of an integer (the serial number of the issuer's public key certificate), a dollar separator and optionally a string encoding of the unique identifier bit string according to RFC 2252 e.g. '010111110'B. Editors note. Issuer DN is a subset of the allowed GeneralNames. Do we wish to allow any type? 5.3.2 Attribute Certificate Match Attribute certificate matching rule is defined in section 17.3.2 of [9]. For the convenience of the reader it is reproduced below: attributeCertificateMatch MATCHING-RULE ::= { SYNTAX AttributeCertificateAssertion ID joint-iso-ccitt(2) ds(5) mr (13) attributeCertificateMatch (42) } AttributeCertificateAssertion ::= SEQUENCE { subject [0] CHOICE { baseCertificateID [0] IssuerSerial, subjectName [1] GeneralNames} OPTIONAL, issuer [1] GeneralNames OPTIONAL, attCertValidity [2] GeneralizedTime OPTIONAL, attType [3] SET OF AttributeType OPTIONAL} --At least one component of the sequence must be present The LDAP definition of the attributeCertificateMatch matching rule is: ( 2.5.13.42 NAME 'attributeCertificateMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.n ) Note that the value of n is still be assigned. The syntax definition is: ( 1.3.6.1.4.1.1466.115.121.1.n DESC 'Attribute Certificate Assertion' ) The LDAP string encoding of this is: - Optionally a string encoding of a distinguished name, optionally followed by a "+" and a string encoding of an integer, Note. If the optional + and integer are missing the distinguished name is the name of the holder of the attribute certificate, whereas if they are present it is the name of the issuer of the certificate and the integer is the serial number of the holder's certificate. Editors note. Distinguished names are a subset of the allowed types in General Name. Is this OK or too restrictive? - followed by a dollar ($) separator, - followed by an optional string encoding of the distinguished name of the issuer, Editor's Note. This is a subset of the allowed General Names. Is it sufficient? - followed by a dollar separator, - followed by an optional string representation of the generalised time of the certificate validity (in the format yyyymmddhhmmssZ as specified in RFC 2252), - followed by a dollar separator, - followed by an optional string encoding of one or more object identifiers of attribute types each separated by "+" character if there is more than one. Editor's Note. X.509 defines the following matching rules for matching on various extensions within an attribute certificate. Before any of them is defined for LDAP, we need to decide how many of them are really useful. 5.3.3 Holder Issuer Match 5.3.4 Delegation Path Match 5.3.5 Authority Attribute Identifier Match 5.3.6 Role Specification Certificate Identifier Match 5.3.7 Basic Attribute Constraints Match 5.3.8 Delegated Name Constraints Match 5.3.9 Time Specification Match 5.3.10 Acceptable Certificate Policies Match 5.3.11 Attribute Descriptor Match 5.3.12 Source of Authority Match Note. This rule has not been defined by X.509, but this is perhaps an omission that should be rectified. It is an easy matching rule to define since it has a null syntax i.e. we will be matching on present or not. 6. Security Considerations This [Internet Draft/Standard] describes the schema for the storage and matching of attribute certificates and revocation lists in an LDAP directory server. It does not address the protocol for the retrieval of this information. LDAP servers SHOULD use access control information to protect the information during its storage. In addition, clients MAY choose to encrypt the attributes in the attribute certificates before storing them in an LDAP server. 7 Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. References [1] Bradner, S. The Internet Standards Process -- Revision 3. RFC 2026 October 1996. [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access Protocol", RFC 1777, March 1995. [3] M.Wahl. "A Summary of the X.500(96) User Schema for use with LDAPv3" RFC 2256, Dec 1997 [4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Dec. 1997, RFC 2251 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC2253, December 1997. [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec 1997 [8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key Infrastructure, LDAPv2 Schema", RFC 2587, June 1999 [9] ITU-T Rec. X.509(2000) The Directory: Authentication Framework 9 Authors Address David Chadwick IS Institute University of Salford Salford England M5 4WT Email: d.w.chadwick@salford.ac.uk Internet-Draft PKIX Operational Protocols - LDAP Schema 8 July 2000