INTERNET-DRAFT D. W. Chadwick PKIX WG University of Salford Intended Category: Standards Track S. Legg Adacel Technologies 8 September 2000 Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs Copyright (C) The Internet Society (2000). 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 or directly to the authors. This Internet-Draft expires on 8 March 2001. 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Chadwick & Legg Expires 8 March 2001 [Page 1] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 document are to be interpreted as described in RFC 2119 [5]. 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 Chadwick & Legg Expires 8 March 2001 [Page 2] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 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. 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' ) The LDAP string encoding of an assertion value of this syntax is given by the following Augmented BNF [10]: CertificateExactAssertion = CertificateSerialNumber "$" ; certificate serial number Name ; certificate issuer CertificateSerialNumber = 1*DIGIT DIGIT = "0" / NON-ZERO-DIGIT NON-ZERO-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" Name = DQUOTE ldapdn DQUOTE ; rdnSequence DQUOTE = %x22 ; " (double quote) ldapdn = *SafeUTF8Character SafeUTF8Character = %x01-21 / %x23-7F / Chadwick & Legg Expires 8 March 2001 [Page 3] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 ; ASCII minus DQUOTE DQUOTE DQUOTE / ; escaped double quote %xCO-DF %x80-BF / ; 2 byte UTF8 char %xEO-EF 2(%x80-BF) / ; 3 byte UTF8 char %xFO-F7 3(%x80-BF) / ; 4 byte UTF8 char %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 char %xFC-FD 5(%x80-BF) ; 6 byte UTF8 char The rule encodes the rdnSequence component (a distinguished name) as an LDAPDN character string between double quotes. The character string is first derived according to the rule in Section 3 of [6], and then any embedded double quotes are escaped by repeating the double quotes character. This resulting string is output between double quotes. 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 an assertion value of this syntax is given by the following ABNF: CertificateAssertion = "(" sp ["NUMBER" sp CertificateSerialNumber sp] ; optional certificate serial number ["ISSUER" sp Name sp] ; optional certificate issuer name ["SKEYID" sp SubjectKeyIdentifier sp] Chadwick & Legg Expires 8 March 2001 [Page 4] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 ; optional subject key identifier ["AKEYID" sp AuthorityKeyIdentifier sp] ; optional authority key identifier ["TIME" sp Time sp] ; optional certificate validity time ["PKTIME" sp GeneralizedTime sp] ; optional private key validity time ["ALGOID" sp numericoid sp] ; optional subject public ; key algorithm object identifier ["USE" sp KeyUsage sp] ; optional key usage bits ; 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 ["ALTNAMETYPE" sp AltNameType sp] ; optional subject alternative name type ["POLICIES" sp CertPolicySet sp] ; optional set of certificate policy ; object identifiers ["TO" sp PathToName sp] ; optional name that must not be ; prohibited from having a ; certification path constructed to it ; via a Name Constraints extension ["SUBJECT" sp Name sp] ; optional subject name ["CONSTRAINTS" sp NameConstraintsSyntax sp] ; optional subject name constraints ")" sp = " " SubjectKeyIdentifier = KeyIdentifier AuthorityKeyIdentifier = KeyIdentifier ; authority key identifier ; For simplicity, authorityCertIssuer and ; authorityCertSerialNumber are omitted. KeyIdentifier = h2string h2string = "'" *(2HEXDIG) "'H" KeyUsage = bstring bstring = "'" *BIT "'B" AltNameType = builtinNameForm / ; one of the X.509 built in ; Name Forms being sought numericoid Chadwick & Legg Expires 8 March 2001 [Page 5] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 ; or the OID of another ; (privately defined) Name Form builtinNameForm = "rfc822" / ; rfc822Name "dns" / ; dNSName "x400" / ; x400Address "ldapdn" / ; directoryName "edi" / ; ediPartyName "uri" / ; uniformResourceIdentifier "ip" / ; iPAddress "oid" ; registeredId CertPolicySet = CertPolicyId *( "+" CertPolicyId ) CertPolicyId = numericoid PathToName = Name Time = GeneralizedTime ; generalizedTime ; Note that utcTime is encoded as a ; GeneralizedTime by assuming the year ; ranges from 1950 to 2049 GeneralizedTime = 10DIGIT *2(2DIGIT) fraction [ "Z" | differential ] fraction = ( "." / "," ) 1*DIGIT differential = ( "-" / "+" ) *2(2DIGIT) NameConstraintsSyntax = [ "permitted" GeneralSubtrees] ; permitted namespaces for a name [ "excluded" GeneralSubtrees] ; excluded namespaces for a name GeneralSubtrees = 1*( "+" GeneralSubtree ) GeneralSubtree = GeneralName ; base only at present ; minimum and maximum omitted ; for simplification Editors' note. The rule permits only a subset of the allowed values of name constraints (minimum and maximum are missing). Do we want to add these? GeneralName = "rfc822 +" IA5String / Chadwick & Legg Expires 8 March 2001 [Page 6] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 ; rfc822Name "dns +" IA5String / ; dNSName "x400 +" ORAddress / ; x400Address "ldapdn +" Name / ; directoryName "edi +" EDIPartyName / ; ediPartyName "uri +" IA5String / ; uniformResourceIdentifier "ip +" h2string / ; iPAddress "oid +" numericoid / ; registeredId numericoid "+" OpenType ; otherName IA5String = DQUOTE *SafeIA5Character DQUOTE ORAddress = DQUOTE *SafeIA5Character DQUOTE SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus DQUOTE DQUOTE DQUOTE ; escaped double quote EDIPartyName = [DirectoryString] "+" ; name Assigner DirectoryString ; party Name DirectoryString = DQUOTE *SafeUTF8Character DQUOTE OpenType = h2string numericoid = ObjIdComponent *( "." ObjIdComponent ) ObjIdComponent = "0" / ( NON-ZERO-DIGIT *DIGIT ) HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" BIT = "0" / "1" The rule encodes an OCTET STRING key identifier as a hexadecimal character string. Each octet is represented by a pair of hexadecimal characters. The rule encodes the Chadwick & Legg Expires 8 March 2001 [Page 7] INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000 subject key. The rule encodes the KeyIdentifier component of the AuthorityKeyIdentifier ASN.1 type. Editors' note. For simplification, the rule permits only a subset of the X.509 allowed values for authority key identifier. Specifically authority issuer name and authority certificate serial number are missing. Is this the best choice to make? The rule represents the key usage bit string rendered as a binary number between quotes. The first (left most) bit represents key usage digitalSignature (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 and have the value 0. The rule encodes a GeneralizedTime string as a printable string as specified in [7]. The