INTERNET-DRAFT D. W. Chadwick PKIX WG University of Salford Intended Category: Standards Track S. Legg Adacel Technologies Expires on 27 December 2002 27 June 2002 Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs Copyright (C) The Internet Society (2002). 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. ABSTRACT This 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 this document are to be interpreted as described in RFC 2119 [5]. 1. Introduction LDAPv3 [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 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. PMI Attributes and Syntaxes LDAP 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 Attribute The 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 Attribute The 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 Attribute The 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 Syntax The 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 Attribute The 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 Attribute The 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 Attribute The 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 AttributeCertificate The 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 Syntax The 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 Rules LDAP 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 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 (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 defined by [3] and - the simple encoding 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 CertificateSerialNumber acea-issuer = id-issuer msp AttCertIssuer id-serialNumber = %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; "serialNumber" id-issuer = %x69.73.73.75.65.72 ; "issuer" AttCertIssuer = "{" [ sp aci-issuerName ] [ sep sp aci-baseCertificateID ] [ sep sp aci-objectDigestInfo ] sp "}" At least one of , or MUST be present. aci-issuerName = id-issuerName msp GeneralNames aci-baseCertificateID = id-baseCertificateID msp IssuerSerial aci-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo id-issuerName = %x69.73.73.75.65.72.4E.61.6D.65 ; "issuerName" GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}" GeneralName = gn-otherName / gn-rfc822Name / gn-dNSName / gn-x400Address / gn-directoryName / gn-ediPartyName / gn-uniformResourceIdentifier / gn-iPAddress / gn-registeredID gn-otherName = id-otherName ":" OtherName gn-rfc822Name = id-rfc822Name ":" IA5String gn-dNSName = id-dNSName ":" IA5String gn-x400Address = id-x400Address ":" ORAddress gn-directoryName = id-directoryName ":" Name gn-ediPartyName = id-ediPartyName ":" EDIPartyName gn-iPAddress = id-iPAddress ":" OCTET-STRING gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER gn-uniformResourceIdentifier = id-uniformResourceIdentifier ":" IA5String id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; "otherName" id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; "rfc822Name" id-dNSName = %x64.4E.53.4E.61.6D.65 ; "dNSName" id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; "x400Address" id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65 ; "directoryName" id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65 ; "ediPartyName" id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; "iPAddress" id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64 ; "registeredId" id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75 %x72.63.65.49.64.65.6E.74.69.66.69.65 %x72 ; "uniformResourceIdentifier" gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44 ; "registeredID" OtherName = "{" sp on-type-id "," sp on-value sp "}" on-type-id = id-type-id msp OBJECT-IDENTIFIER on-value = id-value msp Value id-type-id = %x74.79.70.65.2D.69.64 ; "type-id" id-value = %x76.61.6C.75.65 ; "value" The rule is defined in [3]. EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}" nameAssigner = id-nameAssigner msp DirectoryString partyName = id-partyName msp DirectoryString id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72 ; "nameAssigner" id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; "partyName" id-objectDigestInfo = %x6F.62.6A.65.63.74.44.69.67.65.73.74.49.6E %x66.6F ; "objectDigestInfo" ObjectDigestInfo = "{" sp odi-digestedObjectType [ "," sp odi-otherObjectTypeID ] "," sp odi-digestAlgorithm "," sp odi-objectDigest sp "}" odi-digestedObjectType = id-digestedObjectType msp DigestedObjectType odi-otherObjectTypeID = id-otherObjectTypeID msp OBJECT-IDENTIFIER odi-digestAlgorithm = id-digestAlgorithm msp AlgorithmIdentifier odi-objectDigest = id-objectDigest msp BIT-STRING id-digestedObjectType = %x64.69.67.65.73.74.65.64.4F.62.6A.65.63.74 %x54.79.70.65 ; "digestedObjectType" id-otherObjectTypeID = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70 %x65.49.44 ; "otherObjectTypeID" id-digestAlgorithm = %x64.69.67.65.73.74.41.6C.67.6F.72.69.74.68 %x6D ; "digestAlgorithm" id-objectDigest = %x6F.62.6A.65.63.74.44.69.67.65.73.74 ; "objectDigest" DigestedObjectType = id-publicKey / id-publicKeyCert / id-otherObjectTypes id-publicKey = %x70.75.62.6C.69.63.4B.65.79 ; "publicKey" id-publicKeyCert = %x70.75.62.6C.69.63.4B.65.79.43.65.72.74 ; "publicKeyCert" id-otherObjectTypes = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70.65 %x73 ; "otherObjectTypes" AlgorithmIdentifier = "{" sp ai-algorithm [ "," sp ai-parameters ] sp "}" ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER ai-parameters = id-parameters msp Value id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; "algorithm" id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; "parameters" IssuerSerial = "{" sp is-issuer "," sp is-serial [ "," sp is-issuerUID ] sp "}" is-issuer = id-issuer msp GeneralNames is-serial = id-serial msp CertificateSerialNumber is-issuerUID = id-issuerUID msp UniqueIdentifier id-serial = %x73.65.72.69.61.6C ; "serial" id-issuerUID = %x69.73.73.75.65.72.55.49.44 ; "issuerUID" UniqueIdentifier = BIT-STRING 4.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 { holder [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.2.826.0.1.3344810.7.7 ) The syntax definition is: (1.2.826.0.1.3344810.7.7 DESC 'Attribute Certificate Assertion' ) The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: AttributeCertificateAssertion = "{" [ sp aca-holder ] [ sep sp aca-issuer ] [ sep sp aca-attCertValidity ] [ sep sp aca-attType ] sp "}" aca-holder = id-holder msp ACAHolder aca-issuer = id-issuer msp GeneralNames aca-attCertValidity = id-attCertValidity msp GeneralizedTime aca-attType = id-attType msp SETOFAttributeType ACAHolder = acah-baseCertificateID / acah-holderName acah-baseCertificateID = id-baseCertificateID ":" IssuerSerial acah-holderName = id-holderName ":" GeneralNames id-baseCertificateID = %x62.61.73.65.43.65.72.74.69.66.69.63.61.74 %x65.49.44 ; "baseCertificateID" id-holderName = %x68.6F.6C.64.65.72.4E.61.6D.65 ; "holderName" SETOFAttributeType = "{" sp AttributeType *( "," sp AttributeType ) sp "}" The rule is given in [6]. 5 AC Extensions Matching Rules X.509 defines the following matching rules for matching on various extensions within an attribute certificate. 5.1 Holder Issuer Match Holder Issuer Match is described in section 17.3.3 of [9]. The string description of the holderIssuerMatch matching rule is: ( 2.5.13.46 NAME 'holderIssuerMatch' SYNTAX 1.2.826.0.1.3344810.7.10) The syntax definition is: (1.2.826.0.1.3344810.7.10 DESC 'Holder Issuer Assertion' ) The ASN.1 for HolderIssuerAssertion is defined in 17.3.3 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: HolderIssuerAssertion = "{" [ sp hia-holder ] [ sep sp hia-issuer ] sp "}" hia-holder = id-holder msp Holder hia-issuer = id-issuer msp AttCertIssuer Holder = "{" [ sp h-baseCertificateID ] [ sep sp h-entityName ] [ sep sp h-objectDigestInfo ] sp "}" At least one of , or MUST be present. h-baseCertificateID = id-baseCertificateID msp IssuerSerial h-entityName = id-entityName msp GeneralNames h-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo id-entityName = %x65.6E.74.69.74.79.4E.61.6D.65 ; "entityName" 5.2 Delegation Path Match Delegation Path Match is described in section 17.3.4 of [9]. The string description of the delegationPathMatch matching rule is: ( 2.5.13.61 NAME 'delegationPathMatch' SYNTAX 1.2.826.0.1.3344810.7.10) The syntax definition is: (1.2.826.0.1.3344810.7.10 DESC 'DelMatchSyntax' ) The ASN.1 for DelMatchSyntax is defined in 17.3.4 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: DelMatchSyntax = "{" sp dms-firstIssuer "," sp dms-lastHolder sp "}" dms-firstIssuer = id-firstIssuer msp AttCertIssuer dms-lastHolder = id-lastHolder msp Holder id-firstIssuer = %x66.69.72.73.74.49.73.73.75.65.72 ; "firstIssuer" id-lastHolder = %x6C.61.73.74.48.6F.6C.64.65.72 ; "lastHolder" 5.3 Authority Attribute Identifier Match Authority Attribute Identifier Match is described in section 15.5.2.4.1 of [9]. The string description of the authAttIdMatch matching rule is: ( 2.5.13.53 NAME 'authAttIdMatch' SYNTAX 1.2.826.0.1.3344810.7.12) The syntax definition is: (1.2.826.0.1.3344810.7.12 DESC 'Authority Attribute Identifier Syntax' ) The ASN.1 for AuthorityAttributeIdentifierSyntax is defined in 15.5.2.4 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: AuthorityAttributeIdentifierSyntax = "{" sp AuthAttId *( "," sp AuthAttId ) sp "}" AuthAttId = IssuerSerial 5.4 Role Specification Certificate Identifier Match Role Specification Certificate Identifier match is described in section 15.4.2.1.1 of [9]. The string description of the roleSpecCertIdMatch Match matching rule is: ( 2.5.13.54 NAME 'roleSpecCertIdMatch ' SYNTAX 1.2.826.0.1.3344810.7.13) The syntax definition is: (1.2.826.0.1.3344810.7.13 DESC 'Role Specification Ceritificate Identifier Syntax' ) The ASN.1 for RoleSpecCertIdentifierSyntax is defined in 15.4.2.1 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: RoleSpecCertIdentifierSyntax = "{" sp RoleCertSpecIdentifier *( "," sp RoleCertSpecIdentifier ) sp "}" RoleCertSpecIdentifier = "{" sp rsci-roleName "," sp rsci-roleCertIssuer [ "," sp rsci-roleCertSerialNumber ] [ "," sp rsci-roleCertLocator ] sp "}" rsci-roleName = id-roleName msp GeneralName rsci-roleCertIssuer = id-roleCertIssuer msp GeneralName rsci-roleCertSerialNumber = id-roleCertSerialNumber msp CertificateSerialNumber rsci-roleCertLocator = id-roleCertLocator msp GeneralName id-roleName = %x72.6F.6C.65.4E.61.6D.65 ; "roleName" id-roleCertIssuer = %x72.6F.6C.65.43.65.72.74.49.73.73.75.65 %x72 ; "roleCertIssuer" id-roleCertSerialNumber = %x72.6F.6C.65.43.65.72.74.53.65.72.69.61 %x6C.4E.75.6D.62.65.72 ; "roleCertSerialNumber" id-roleCertLocator = %x72.6F.6C.65.43.65.72.74.4C.6F.63.61.74 %x6F.72 ; "roleCertLocator" 5.5 Basic Attribute Constraints Match Basic Attribute Constraints Match is described in section 15.5.2.1.1 of [9]. The string description of the holderIssuerMatch matching rule is: ( 2.5.13.55 NAME ' basicAttConstraintsMatch ' SYNTAX 1.2.826.0.1.3344810.7.14) The syntax definition is: (1.2.826.0.1.3344810.7.14 DESC 'Basic Attributes Constraints Syntax' ) The ASN.1 for BasicAttConstraintsSyntax is defined in 15.5.2.1 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: BasicAttConstraintsSyntax = "{" [ sp bacm-authority ] [ sep sp bacm-pathLenConstraint ] sp "}" bacm-authority = id-authority msp BOOLEAN bacm-pathLenConstraint = id-pathLenConstraint msp INTEGER-0-MAX id-authority = %x61.75.74.68.6F.72.69.74.79 ; "authority" id-pathLenConstraint = %x70.61.74.68.4C.65.6E.43.6F.6E.73.74.72.61 %x69.6E.74 ; "pathLenConstraint" The rule is given in [6]. 5.6 Delegated Name Constraints Match Delegated Name Constraints Match is described in section 15.5.2.2.1 of [9]. The string description of the holderIssuerMatch matching rule is: ( 2.5.13.56 NAME ' delegatedNameConstraintsMatch' SYNTAX 1.2.826.0.1.3344810.7.15) The syntax definition is: (1.2.826.0.1.3344810.7.15 DESC 'Name Constraints Syntax' ) The ASN.1 for NameConstraintsSyntax is defined in 8.4.2.2 of [9], and the semantics of its components when used for delegated name constraints are described in 15.5.2.2. The LDAP string encoding of an assertion value of this syntax is given in Section 4.2. 5.7 Time Specification Match Time Specification Match is described in section 15.1.2.1.1 of [9]. The string description of the timeSpecificationMatch matching rule is: ( 2.5.13.57 NAME ' timeSpecificationMatch ' SYNTAX 1.2.826.0.1.3344810.7.16) The syntax definition is: (1.2.826.0.1.3344810.7.16 DESC 'Time Specification' ) The ASN.1 for TimeSpecification is defined in 7.2 of [7], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: TimeSpecification = "{" sp ts-time [ "," sp ts-notThisTime ] [ "," sp ts-timeZone ] sp "}" ts-time = id-time msp TSTime ts-notThisTime = id-notThisTime msp BOOLEAN ts-timeZone = id-timeZone msp TimeZone id-time = %x74.69.6D.65 ; "time" id-notThisTime = %x6E.6F.74.54.68.69.73.54.69.6D.65 ; "notThisTime" id-timeZone = %x74.69.6D.65.5A.6F.6E.65 ; "timeZone" TSTime = tst-absolute / tst-periodic tst-absolute = id-absolute ":" AbsoluteTime tst-periodic = id-periodic ":" Periods AbsoluteTime = "{" [ sp at-startTime ] [ sep sp at-endTime ] sp "}" at-startTime = id-startTime msp GeneralizedTime at-endTime = id-endTime msp GeneralizedTime id-startTime = %x73.74.61.72.74.54.69.6D.65 ; "startTime" id-endTime = %x65.6E.64.54.69.6D.65 ; "endTime" Periods = "{" [ sp Period *( "," sp Period ) ] sp "}" Period = "{" [ sp p-timesOfDay ] [ sep sp p-days ] [ sep sp p-weeks ] [ sep sp p-months ] [ sep sp p-years ] sp "}" p-timesOfDay = id-timesOfDay msp DayTimeBands p-days = id-days msp Days p-weeks = id-weeks msp Weeks p-months = id-months msp Months p-years = id-years msp Years id-timesOfDay = %x74.69.6D.65.73.4F.66.44.61.79 ; "timesOfDay" id-days = %x64.61.79.73 ; "days" id-weeks = %x77.65.65.6B.73 ; "weeks" id-months = %x6D.6F.6E.74.68.73 ; "months" id-years = %x79.65.61.72.73 ; "years" DayTimeBands = "{" sp DayTimeBand *( "," sp DayTimeBand ) sp "}" DayTimeBand = "{" [ sp dtb-startDayTime ] [ sep sp dtb-endDayTime ] sp "}" dtb-startDayTime = id-startDayTime msp DayTime dtb-endDayTime = id-endDayTime msp DayTime id-startDayTime = %x73.74.61.72.74.44.61.79.54.69.6D.65 ; "startDayTime" id-endDayTime = %x65.6E.64.44.61.79.54.69.6D.65 ; "endDayTime" DayTime = "{" sp dt-hour [ "," sp dt-minute ] [ "," sp dt-second ] sp "}" dt-hour = id-hour msp INTEGER ; 0 to 23 dt-minute = id-minute msp INTEGER ; 0 to 59 dt-second = id-second msp INTEGER ; 0 to 59 id-hour = %x68.6F.75.72 ; "hour" id-minute = %x6D.69.6E.75.74.65 ; "minute" id-second = %x73.65.63.6F.6E.64 ; "second" Days = days-intDay / days-bitDay / days-dayOf days-intDay = id-intDay ":" SET-OF-INTEGER days-bitDay = id-bitDay ":" BitDay days-dayOf = id-dayOf ":" XDayOf id-intDay = %x69.6E.74.44.61.79 ; "intDay" id-bitDay = %x62.69.74.44.61.79 ; "bitDay" id-dayOf = %x64.61.79.4F.66 ; "dayOf" SET-OF-INTEGER = "{" [ sp INTEGER *( "," sp INTEGER ) ] "}" BitDay = BIT-STRING / day-bit-list day-bit-list = "{" [ sp day *( "," sp day ) ] sp "}" day = %x73.75.6E.64.61.79 ; "sunday" / %x6D.6F.6E.64.61.79 ; "monday" / %x74.75.65.73.64.61.79 ; "tuesday" / %x77.65.64.6E.65.73.64.61.79 ; "wednesday" / %x74.68.75.72.73.64.61.79 ; "thursday" / %x66.72.69.64.61.79 ; "friday" / %x73.61.74.75.72.64.61.79 ; "saturday" XDayOf = xdo-first / xdo-second / xdo-third / xdo-fourth / xdo-fifth xdo-first = id-first ":" NamedDay xdo-second = id-second ":" NamedDay xdo-third = id-third ":" NamedDay xdo-fourth = id-fourth ":" NamedDay xdo-fifth = id-fifth ":" NamedDay NamedDay = nd-intNamedDays / nd-bitNamedDays nd-intNamedDays = id-intNamedDays ":" day nd-bitNamedDays = id-bitNamedDays ":" ( BIT-STRING / day-bit-list ) id-intNamedDays = %x69.6E.74.4E.61.6D.65.64.44.61.79.73 ; "intNamedDays" id-bitNamedDays = %x62.69.74.4E.61.6D.65.64.44.61.79.73 ; "bitNamedDays" Weeks = weeks-allWeeks / weeks-intWeek / weeks-bitWeek weeks-allWeeks = id-allWeeks ":" NULL weeks-intWeek = id-intWeek ":" SET-OF-INTEGER weeks-bitWeek = id-bitWeek ":" BitWeek id-allWeeks = %x61.6C.6C.57.65.65.6B.73 ; "allWeeks" id-intWeek = %x69.6E.74.57.65.65.6B ; "intWeek" id-bitWeek = %x62.69.74.57.65.65.6B ; "bitWeek" BitWeek = BIT-STRING / week-bit-list week-bit-list = "{" [ sp week-bit *( "," sp week-bit ) ] sp "}" week-bit = %x77.65.65.6B.31 ; "week1" / %x77.65.65.6B.32 ; "week2" / %x77.65.65.6B.33 ; "week3" / %x77.65.65.6B.34 ; "week4" / %x77.65.65.6B.35 ; "week5" Months = months-allMonths / months-intMonth / months-bitMonth months-allMonths = id-allMonths ":" NULL months-intMonth = id-intMonth ":" SET-OF-INTEGER months-bitMonth = id-bitMonth ":" BitMonth id-allMonths = %x61.6C.6C.4D.6F.6E.74.68.73 ; "allMonths" id-intMonth = %x69.6E.74.4D.6F.6E.74.68 ; "intMonth" id-bitMonth = %x62.69.74.4D.6F.6E.74.68 ; "bitMonth" BitMonth = BIT-STRING / month-bit-list month-bit-list = "{" [ sp month-bit *( "," sp month-bit ) ] sp "}" month-bit = %x6A.61.6E.75.61.72.79 ; "january" / %x66.65.62.72.75.61.72.79 ; "february" / %x6D.61.72.63.68 ; "march" / %x61.70.72.69.6C ; "april" / %x6D.61.79 ; "may" / %x6A.75.6E.65 ; "june" / %x6A.75.6C.79 ; "july" / %x61.75.67.75.73.74 ; "august" / %x22.73.65.70.74.65.6D.62.65.72 ; "september" / %x6F.63.74.6F.62.65.72 ; "october" / %x6E.6F.76.65.6D.62.65.72 ; "november" / %x64.65.63.65.6D.62.65.72 ; "december" Years = "{" [ sp Year *( "," sp Year ) ] sp "}" Year = INTEGER ; must be >= 1000 TimeZone = INTEGER ; -12 to 12 The rule is given in [6]. 5.8 Acceptable Certificate Policies Match Acceptable Certificate Policies Match is described in section 15.5.2.3.1 of [9]. The string description of the acceptableCertPoliciesMatch matching rule is: ( 2.5.13.59 NAME 'acceptableCertPoliciesMatch' SYNTAX 1.2.826.0.1.3344810.7.17) The syntax definition is: (1.2.826.0.1.3344810.7.17 DESC 'Acceptable Certificate Policies Syntax) The ASN.1 for AcceptableCertPoliciesSyntax is defined in 15.5.2.3 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: AcceptableCertPoliciesSyntax = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}" 5.9 Attribute Descriptor Match Attribute Descriptor Match is described in section 15.3.2.2.1 of [9]. The string description of the attDescriptor matching rule is: ( 2.5.13.58 NAME 'attDescriptor' SYNTAX 1.2.826.0.1.3344810.7.18) The syntax definition is: (1.2.826.0.1.3344810.7.18 DESC 'Attribute Descriptor Syntax') The ASN.1 for AttributeDescriptorSyntax is defined in 15.3.2.2 of [9], as are the semantics of its components. The LDAP string encoding of an assertion value of this syntax is given by the following ABNF: AttributeDescriptorSyntax = "{" sp ads-identifier "," sp ads-attributeSyntax [ "," sp ads-name ] [ "," sp ads-description ] "," sp ads-dominationRule sp "}" ads-identifier = id-identifier msp AttributeIdentifier ads-attributeSyntax = id-attributeSyntax msp AttributeSyntax ads-name = id-name msp AttributeName ads-description = id-description msp AttributeDescription ads-dominationRule = id-dominationRule msp PrivilegePolicyIdentifier id-identifier = %x69.64.65.6E.74.69.66.69.65.72 ; "identifier" id-attributeSyntax = %x61.74.74.72.69.62.75.74.65.53.79.6E.74.61.78 ; "attributeSyntax" id-name = %x6E.61.6D.65 ; "name" id-description = %x64.65.73.63.72.69.70.74.69.6F.6E ; "description" id-dominationRule = %x64.6F.6D.69.6E.61.74.69.6F.6E.52.75.6C.65 ; "dominationRule" AttributeSyntax = OCTET-STRING ; an empty string is not allowed AttributeIdentifier = AttributeType AttributeName = UTF8String ; an empty string is not allowed AttributeDescription = UTF8String ; an empty string is not allowed PrivilegePolicyIdentifier = "{" sp ppi-privilegePolicy "," sp ppi-privPolSyntax sp "}" ppi-privilegePolicy = id-privilegePolicy msp PrivilegePolicy ppi-privPolSyntax = id-privPolSyntax msp InfoSyntax id-privilegePolicy = %x70.72.69.76.69.6C.65.67.65.50.6F.6C.69.63.79 ; "privilegePolicy" id-privPolSyntax = %x70.72.69.76.50.6F.6C.53.79.6E.74.61.78 ; "privPolSyntax" PrivilegePolicy = OBJECT-IDENTIFIER InfoSyntax = is-content / is-pointer is-content = id-content ":" DirectoryString is-pointer = id-pointer ":" InfoSyntaxPointer id-content = %x63.6F.6E.74.65.6E.74 ; "content" id-pointer = %x70.6F.69.6E.74.65.72 ; "pointer" InfoSyntaxPointer = "{" sp isp-name [ "," sp isp-hash ] sp "}" isp-name = id-name msp GeneralNames isp-hash = id-hash msp HASH id-hash = %x68.61.73.68 ; "hash" HASH = "{" sp h-algorithmIdentifier "," sp h-hashValue sp "}" h-algorithmIdentifier = id-algorithmIdentifier msp AlgorithmIdentifier h-hashValue = id-hashValue msp BIT-STRING id-algorithmIdentifier = %x61.6C.67.6F.72.69.74.68.6D.49.64.65.6E.74 %x69.66.69.65.72 ; "algorithmIdentifier" id-hashValue = %x68.61.73.68.56.61.6C.75.65 ; "hashValue" The rule is given in [6]. 5.10 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 whether the extension is present or not. Source of Authority Match returns TRUE if an attribute certificate contains an SOA Identifier extension. The SOA Identifier extension is described in section 15.3.2.1 of [9]. The string description of the sOAIdentifierMatch matching rule is: ( 2.5.13.x NAME 'sOAIdentifierMatch' SYNTAX 1.2.36.79672281.1.5.1) The syntax definition of 1.2.36.79672281.1.5.1 (NULL) is given in [3]. 6 PMI Object Classes The definitions of the PMI directory object classes can be found in section 17.1 of [9]. They are repeated here for the convenience of the reader. 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) } } attCertCRLDistributionPt OBJECT-CLASS ::= { -- an AC CRL distribution point SUBCLASS OF {top} KIND auxiliary MAY CONTAIN { attributeCertificateRevocationList | attributeAuthorityRevocationList } ID { joint-iso-ccitt(2) ds(5) objectClass(6) attCertCRLDistributionPts (27) } } pmiDelegationPath OBJECT-CLASS ::= { -- an object that may contain a delegation path SUBCLASS OF {top} KIND auxiliary MAY CONTAIN { delegationPath } ID { joint-iso-ccitt(2) ds(5) objectClass(6) delegationPath (33) } } privilegePolicy OBJECT-CLASS ::= { -- an object that may contain privilege policy information SUBCLASS OF {top} KIND auxiliary MAY CONTAIN {privPolicy } ID { joint-iso-ccitt(2) ds(5) objectClass(6) privilegePolicy (32) } } 7. Filter Examples The following examples are written using the string representation of Search filters defined in [14]. Line-breaks have been added as an aid to readability. i) To exactly match one attribute certificate using equalityMatch with attributeCertificateExactMatch and GSERAttributeCertificateExactAssertion (attributeCertificateAttribute={serialNumber 12345 , issuer { issuerName { directoryName rdnSequence:"O=truetrust ltd, C=GB" }) ii) To exactly match one attribute certificate using equalityMatch with attributeCertificateExactMatch and SimpleCertificateExactAssertion (attributeCertificateAttribute=12345$O=truetrust ltd, C=GB) iii) To match on the serial number of an attribute certificate using extensibleMatch with component matching [13] (attributeCertificateAttribute:componentFilterMatch:= item:{ component "serialNumber", rule integerMatch, value 12345 }) iv) To exactly match one attribute certificate using extensibleMatch with component matching (attributeCertificateAttribute:componentFilterMatch:=and:{ item:{ component "serialNumber", rule integerMatch, value 12345 } item:{ component "issuer.issuerName.directoryName.rdnSequence", rule distinguishedNameMatch, value "O=truetrust ltd, C=GB" } }) v) To match attribute certificates containing a certain role To Be Worked Out Later# 8. Security Considerations This [Internet Draft/Standard] describes the schema for the storage and matching of PMI attributes (attribute certificates, revocation lists etc.) in an LDAP directory server. It does not address the protocol for the retrieval of this information. LDAP servers SHOULD use authentication and access control methods to protect this information during its storage from unauthorised modification and retrieval. In addition, clients MAY choose to encrypt the attributes in the attribute certificates before storing them in an LDAP server to ensure their confidentiality. 9. References Normative [1] Bradner, S. The Internet Standards Process -- Revision 3. RFC 2026 October 1996. [2] Chadwick, D.W., Legg, S. "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PKIs" , June 2002 [3] S. Legg, "Generic String Encoding Rules", , March 2002, a work in progress [4] J. Sermersheim "Lightweight Directory Access Protocol (v3)" July 2001 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] S. Legg, "Common Elements of GSER Encodings", , March 2002, a work in progress [7] ITU-T Rec. X.520(2000) The Directory: Selected Attribute Types [9] ITU-T Rec. X.509(2000) The Directory: Authentication Framework [10] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 Informative [13] S. Legg, "LDAP & X.500 Component Matching Rules", , November 2001, a work in progress [14] Howes, T. "The String Representation of LDAP Search Filters". RFC 2254, December 1997. 10. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Copyright Copyright (C) The Internet Society (2002). 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. 12. Authors' Addresses David Chadwick IS Institute University of Salford Salford England M5 4WT Email: d.w.chadwick@salford.ac.uk Steven Legg Adacel Technologies Ltd. 405-409 Ferntree Gully Road, Mount Waverley, Victoria, 3149 Australia Email: steven.legg@adacel.com.au 13. Changes >From Version 00 i) Added ABNF notation for all of the syntaxes. ii) Removed the restriction on the syntax of Distribution Point Names. iii) Removed constraints on IssuerSerial. iv) Bug detected in X.509 AttributeCertificateExactMatch that will need resolving. v) Changed the string encodings for non-exact matches to keywords for each component instead of $ separators. >From Version 01 i) Added and corrected all X.509 PKI schema definitions, since these have been removed from RFC2252-bis. ii) Changed assertion syntaxes to use the syntax defined by Component Matching Rules iii) Included all the matching rules for AC extensions >From Version 02 of i) PKI and PMI schema has been split into separate IDs ii) Example have been added iii) Text has been added to mandate that servers must store and retrieve syntaxes containing digital signatures exactly as given. iv) Text has been removed concerning the use of the ;binary encoding option, as per the decision of the LDAPBIS group. 14. Outstanding Issues i. There is still a bug in the X.509 AttributeCertificateExactAssertion. It reads: AttributeCertificateExactAssertion ::= SEQUENCE { serialNumber CertificateSerialNumber OPTIONAL, issuer IssuerSerial } OPTIONAL should be removed from the serialNumber. IssuerSerial should be replaced by AttCertIssuer. This ID has assumed that the change will be made. ii. Should the AttributeType in Attribute Certificate Match allow the LDAP encoding option for describing attribute type OIDs (i.e. user friendly names instead of object identifiers)? Note that attribute names are not guaranteed to be unique, whereas OIDs are. iii. The Source of Authority Match is not defined in X.509. Do we prefer compatibility with X.509 and remove it, or get X.509 to add it. 15. Table of Contents 1. Introduction 1 2. Subschema Publishing 2 3. PMI Attributes and Syntaxes 2 3.1 Attribute Certificate Attribute 2 3.2 Attribute Authority Certificate Attribute 2 3.3 Attribute Descriptor Certificate Attribute 3 3.4 Attribute Certificate Syntax 3 3.5 Attribute Certificate Revocation List Attribute 3 3.6 Attribute Authority Certificate Revocation List Attribute 4 3.7 Delegation Path Attribute 4 3.8 Delegation Path Syntax 4 4 PMI Matching Rules 5 4.1 Attribute Certificate Exact Match 5 4.2 Attribute Certificate Match 9 5 AC Extensions Matching Rules 10 5.1 Holder Issuer Match 10 5.2 Delegation Path Match 10 5.3 Authority Attribute Identifier Match 11 5.4 Role Specification Certificate Identifier Match 11 5.5 Basic Attribute Constraints Match 12 5.6 Delegated Name Constraints Match 12 5.7 Time Specification Match 13 5.8 Acceptable Certificate Policies Match 16 5.9 Attribute Descriptor Match 16 5.10 Source of Authority Match 17 6 PMI Object Classes 18 7. Filter Examples 19 8. Security Considerations 19 9. References 20 Normative 20 Informative 20 10. Intellectual Property Notice 20 11. Copyright 21 12. Authors' Addresses 21 13. Changes 22 14. Outstanding Issues 22 15. Table of Contents 23