>INTERNET-DRAFT D. W. Chadwick >PKIX WG M. V. Sahalayev >Intended Category: Informational University of Salford >Expires on 25 April 2005 25 October 2004 > > Internet X.509 Public Key Infrastructure > LDAP Schema for X.509 CRLs > > >Copyright (C) The Internet Society (2003). This document is subject to the >rights, licenses and restrictions contained in BCP 78, and except as set forth >therein, the authors retain all their right. > >"This document and the information contained herein are >provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET >ENGINEERING TASK FORCE DISCLAIM 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." > >"By submitting this Internet-Draft, we certify that any applicable patent or >other IPR claims of which we are aware have been disclosed, or will be >disclosed, and any of which we become aware will be disclosed, in accordance >with RFC 3668 [22]." > >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 an LDAP schema for X.509 CRLs. Each CRL is broken down >into a set of attribute types. These attributes can then be stored in a CRL >entry, or set of entries. Object classes are defined for these CRL entries. Each >attribute type uses an existing LDAP syntax, so that no new matching rules need >to be defined. Spell out LDAP and CRL on first use in Abstract. >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 [2]. This paragraph should be moved into the body. > 1. Introduction > >It currently isn't possible to search LDAP servers for X.509 [6] attributes >(public key certificates, CRLs etc.) as no matching rules have been defined for >them. Spell out LDAP and CRL on first use. This statement is misleading. These rules were defined for use in X.500 and while current LDAP TS did not specify descriptions for their use in LDAP, the X.500 rules are still widely available in LDAP. LDAPBIS is correcting the LDAP descriptions. >A couple of Internet Drafts [9,10] have been specified, but implementation >of them is complex. Both [9] and [10] are expired. I note that draft-zeilenga-ldap-x509 provides LDAP descriptions for X.509/X.521 certificate-related schema elements. I do not consider implementation of draft-zeilenga-ldap-x509 to be complex given the wide available of certificate parsing libraries and ASN.1 compilers. This schema has implemented in OpenLDAP for years, with matching rule support. As this is open source software, there should be little to no impairment for vendors to provide full support for draft-zeilenga-ldap-x509. >Component matching [19] defines a mechanism for matching >against complex syntaxes, by defining generic matching rules that can match >against any user selected component parts in an attribute value of any >arbitrarily complex attribute syntax. This might prove to be the proper way to >solve LDAP search problems in the longer term, but it will take a long time >until such ASN.1 based mechanisms are implemented in all LDAP servers and >clients. Even when this has happened the mechanism proposed in this document >will still be useful to some applications such as CIP [20]. > >A simple and easy to implement mechanism is needed today to search for X.509 >attributes. >Rather than search for an X.509 attribute in an entry, it suggests the directory >administrative user creates an entry (in the case of pubic key and attribute >certificates) or a subtree (in the case of CRLs) from the X.509 attribute. The >attributes of these new entries will be created from fields of the X.509 >attribute (e.g. the issuer field), and if these new attributes are defined using >existing LDAP syntaxes and matching rules, then it will be possible to use >existing LDAP server technology to search for fields in X.509 attributes. What if the application needs to match on a component of the subject or issuer DN? >This document is one of a set comprising: >i) the LDAP schema for X.509 public key certificates [7] >ii) the LDAP schema for X.509 attribute certificates [8] >iii) the LDAP schema for X.509 CRLs (this document) > >Schema definitions are provided using LDAPv3 description formats from RFC2252 >[3]. Definitions provided here are formatted (line wrapped) for readability. >The specifications use the augmented Backus-Naur Form (ABNF) as described in >RFC2234 [4]. > > 2. DIT Structure and Naming > >If the schema presented in this document is used to store information about CRLs >in a directory, each CRL entry SHOULD be stored as a direct subordinate of the >CRL issuer's entry, unless a crlScope Extension or issuingDistributionPoint >Extension is present in the CRL. In the latter cases the CRL MUST be stored as >indicated in those extensions. The CRL entry is named using the >x509CRLThisUpdate attribute, using one of the following name forms: > > (1.2.826.0.1.3344810.1.3.0 > NAME 'x509CRLNameForm' > OC x509CRL > MUST x509CRLThisUpdate ) > > (1.2.826.0.1.3344810.1.3.7 > NAME 'x509ARLNameForm' > OC x509CRL > MUST x509CRLThisUpdate ) > > (1.2.826.0.1.3344810.1.3.8 > NAME 'x509deltaRLNameForm' > OC x509CRL > MUST x509CRLThisUpdate ) > >x509CRLNameForm is used to name CRL entries. >x509ARLNameForm is used to name Authority Revocation List entries. >x509deltaRLNameForm is used to name delta CRL entries. > >Subordinate to the entry for the CRL, the user MAY create an entry for each >revoked certificate. Each revoked certificate entry is named with the serial >number of the revoked certificate, unless the CRL is an indirect CRL, in which >case it is named with a combination of the serial number and issuer's DN i.e. a >multi-valued RDN. For those LDAP servers that do not support multi-valued RDNs, >an alternative name form is defined in which the serial number and issuer DN are >concatenated together into one attribute value. This is expressed in the >following name forms: > > (1.2.826.0.1.3344810.1.3.1 > NAME 'x509CRLentryNameForm' > OC x509CRLentry > MUST x509serial ) > > (1.2.826.0.1.3344810.1.3.2 > NAME 'x509CRLindirectEntryNameForm' > OC x509CRLentry > MUST ( x509serialNumber $ x509issuer ) ) > > (1.2.826.0.1.3344810.1.3.6 > NAME 'x509CRLindirectEntryAltNameForm' > OC x509AC > MUST ( x509issuerSerial ) ) > >When encoding DNs that contain an x509issuer field, the string representation >must be made according to [13]. These strings contain RFC2253 special >characters and must therefore be escaped. For example, the issuer name in a >certificate may be: > > x509issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign Inc. - > For authorized use only,OU=Class 1 Public Primary Certification Au > thority - G2,O=VeriSign Inc.,C=US > >When used in the x509issuerSerial attribute of a DN, this may appear as: > > dn: x509issuerSerial=123456\,OU\=VeriSign Trust Network \,OU > \=(c) 1998 VeriSign Inc. - For authorized use only\,OU\=Class 1 Public > Primary Certification Authority - G2\,O\=VeriSign Inc.\2cC\3dUS > > 3. X.509 Schema Object Classes > >The object classes have been designed to form a logical set and be extensible in >an orderly way as new PKC/CRL/AC extensions are defined. The methodology is as >follows. Every X.509 entry (for a PKC, CRL or AC) is of the x509base abstract >object class. There is then an additional abstract object class for each, >derived from x509base, which holds the attributes extracted from the basic >PKC/AC/CRL ASN.1 structure (excluding all extensions). Further, there is an >auxiliary object class for the extensions defined in X.509 [6], and an >additional auxiliary object class (if needed) for extensions defined in existing >Internet RFCs. As new extensions are defined, then new auxiliary object classes >and attributes will need to be defined to cater for the attributes to be >extracted from these. Finally there are several structural object classes for >each, which allow the X.509 DER encoded attribute to be stored in the entry. > > 3.1 X509 base object class > >The x509base object class is defined in [7]. > > 3.2 X.509 CRL object class > >The x509CRL object class is the abstract object class used for storing the >searchable attributes extracted from the basic fields of a CRL (excluding >extensions). It is the superior of the revocation list structural object >classes. > > (1.2.826.0.1.3344810.1.0.14 > NAME 'x509CRL' > SUP x509base > ABSTRACT > MUST ( x509CRLThisUpdate $ > x509signatureAlgorithm $ > x509issuer ) > MAY ( x509CRLNextUpdate )) > > 3.3 X509 CRL extensions object class > >The x509CRLext auxiliary object class is used to hold the attributes extracted >from the extensions defined in the X.509 standard [6] and profiled in [5]. Note >that the freshest CRL extension is not included since this was originally >forbidden from appearing in CRLs by X.509. > >Note. If a CRL holds additional extensions to these, then another auxiliary >object class and supporting attributes will need to be defined. > >(1.2.826.0.1.3344810.1.0.23 > NAME 'x509CRLext' > AUXILIARY > MAY ( x509authorityKeyIdentifier $ > x509authorityCertIssuer $ > x509authorityCertSerialNumber $ > x509issuerRfc822Name $ > x509issuerDNSName $ > x509issuerDirectoryName $ > x509issuerUniformResourceIdentifier $ > x509issuerIPAddress $ > x509issuerRegisteredID $ > x509CRLNumber $ > x509CRLDPRfc822Name $ > x509CRLDPDNSName $ > x509CRLDPDN $ > x509CRLDPURI $ > x509CRLDPIPAddress $ > x509CRLDPRegisteredID $ > x509CRLDPOnlyUserCerts $ > x509CRLDPOnlyCACerts $ > x509CRLDPOnlySomeReasons $ > x509CRLDPOnlyAttCerts $ > x509CRLDPindirect $ > x509CRLDeltaIndicator ) ) > > 3.4 X.509 certificate revocation list object class > >This object class is the structural object class used to hold certificate >revocation list entries. > > (1.2.826.0.1.3344810.1.0.19 > NAME 'x509certificateRevocationList' > SUP x509CRL > MUST certificateRevocationList ) > > 3.4 X.509 authority revocation list object class > >This object class is the structural object class used to hold authority >revocation list entries. > > (1.2.826.0.1.3344810.1.0.20 > NAME 'x509authorityRevocationList' > SUP x509CRL > MUST authorityRevocationList ) > > 3.5 X.509 delta revocation list object class > >This object class is the structural object class used to hold delta revocation >list entries. > > (1.2.826.0.1.3344810.1.0.21 > NAME 'x509deltaRevocationList' > SUP x509CRL > MUST deltaRevocationList ) > > 3.6 X.509 revoked certificate object class > >The x509CRLentry object class is the structural object class used for storing >revoked certificate entries. > > (1.2.826.0.1.3344810.1.0.15 > NAME 'x509CRLentry' > SUP x509base > MUST ( x509serialNumber $ > x509CRLCertRevocationDate ) > MAY ( x509CRLCertInvalidityDate $ > x509CRLCertReasonCode $ > x509CRLCertHoldInstructionCode $ > x509CRLCertIssuerRfc822Name $ > x509CRLCertIssuerDnsName $ > x509CRLCertIssuerDN $ > x509CRLCertIssuerURI $ > x509CRLCertIssuerIpAddress $ > x509CRLCertIssuerRegisteredID ) ) > > 4. Common X.509 Attribute Types > >The following attribute types defined in [7] are used to hold the corresponding >fields of CRLs: > > - x509serialNumber - used to hold the serial number(s) of the revoked > certifictate(s) > - x509version - used to hold the version of the CRL > - x509signatureAlgorithm - used to hold the OID of the algorithm used to > sign the CRL > - x509issuer - used to hold the DN of the CRL issuer > - x509issuerRfc822Name - used to hold the email address of the CRL issuer > - x509issuerDnsName - used to hold the DNS name of the CRL issuer > - x509issuerDirectoryName - used to hold an alternative DN for the > CRL issuer > - x509issuerURI - used to hold a URI for the CRL issuer > - x509issuerIpAddress - used to hold the IP address of the CRL issuer > - x509issuerRegisteredID - used to hold a registered OID of the CRL issuer > - x509authorityKeyIdentifier - used to hold the identifier of the key used > to sign the CRL > - x509authorityCertIssuer - used in conjunction with > x509authorityCertSerialNumber to identify the certificate of the issuer > - x509authorityCertSerialNumber - used in conjunction with > x509authorityCertIssuer to identify the certificate of the issuer > > 5. Attribute Types for CRL Specific Fields > >The following attribute types may be used to store basic fields of a CRL. The >following basic fields are supported: > - this update > - next update > > 5.1 This update > >This attribute may be used to hold the thisUpdate field of the CRL. > > (1.2.826.0.1.3344810.1.1.37 > NAME 'x509CRLThisUpdate' > DESC 'Date at which this revocation list was issued - see RFC3280 5.1.2.4' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE ) > >Note that the field in the CRL may be in UTC or GeneralizedTime format. If in >UTC format, the creator of this attribute MUST convert the UTC time into >GeneralisedTime format when creating the attribute value. > >5.2 Next update > >This attribute may be used to hold the nextUpdate field of the CRL. > > (1.2.826.0.1.3344810.1.1.38 > NAME 'x509CRLNextUpdate' > DESC 'Date by which the next revocation list in this series > will be issued, see - RFC3280 5.1.2.5' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE ) > >Note that the field in the CRL may be in UTC or GeneralizedTime format. If in >UTC format, the creator of this attribute MUST convert the UTC time into >GeneralisedTime format when creating the attribute value. > > 6. Attributes for Selected CRL Extensions > >In line with the CRL profile RFC 3280 [5], the following CRL extensions are >supported: > - CRL Number (defined here) > - Issuing Distribution Point (defined here) > - Authority Key Identifier (defined in [7]) > - Issuer Alternative Name (defined in [7]) > - Delta CRL Indicator (defined here) > >The following extension is not included: > - freshest CRL (see 5.2.6 of RFC 3280 [5]) > >6.1 CRL number extension > >This attribute may be used to store the sequence number of the CRL. > > (1.2.826.0.1.3344810.1.1.102 > NAME 'x509CRLNumber' > DESC 'sequence number of issued CRL - see RFC3280 5.2.3' > EQUALITY integerMatch > ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > SINGLE-VALUE ) > >6.2 Issuing distribution point > >The issuing distribution point comprises the general name of the issuing CA, >plus some codes that indicate the contents of this CRL. Separate attribute types >are defined for all choices of the ASN.1 type "GeneralName" except for >"otherName", "x400Address" and "ediPartyName". > > 6.2.1 Issuing distribution point RFC 822 name > > (1.2.826.0.1.3344810.1.1.48 > NAME 'x509CRLDPRfc822Name' > DESC 'Internet electronic mail address of the issuing > distribution point, see RFC3280 5.2.5' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded according to the syntax given in RFC >822 [11]. > > 6.2.2 Issuing distribution point DNS name > > (1.2.826.0.1.3344810.1.1.49 > NAME 'x509CRLDPDnsName' > DESC 'Internet domain name of the issuing distribution point, see > RFC3280 5.2.5' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded as Internet domain names in accordance >with RFC1035 [12]. > > 6.2.3 Issuing distribution point directory name > > (1.2.826.0.1.3344810.1.1.50 > NAME 'x509CRLDPDN' > DESC 'Distinguished name of the issuing distribution point, see > RFC3280 5.2.5' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > >Values of this attribute type must be encoded according to the syntax given in >RFC2253 [13]. > > 6.2.4 Issuing distribution point uniform resource identifier > > (1.2.826.0.1.3344810.1.1.51 > NAME 'x509CRLDPURI' > DESC 'Uniform Resource Identifier of the issuing distribution > point, see RFC3280 5.2.5' > EQUALITY caseExactIA5Match > SUBSTR caseExactIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded according to the syntax given in >RFC2396 [14]. > > 6.2.5 Issuing distribution point IP address > > (1.2.826.0.1.3344810.1.1.52 > NAME 'x509CRLDPIpAddress' > DESC 'Internet Protocol address, of the issuing distribution point, see > RFC3280 5.2.5' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute type must be stored in the syntax given in Appendix B >of RFC2373 [16]. > > 6.2.6 Issuing distribution point registered ID > > (1.2.826.0.1.3344810.1.1.53 > NAME 'x509CRLDPRegisteredID' > DESC 'Any registered OID of the certificate issuer, see > RFC3280 5.2.5' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > >registeredID is an identifier of any registered object assigned in accordance >with ITU-T Rec. X.660. [17] > > 6.2.7 Issuing distribution point only contains user certs > >This attribute may be used to indicate if the CRL only contains revocations for >end-entity certificates. > > (1.2.826.0.1.3344810.1.1.54 > NAME 'x509CRLDPOnlyUserCerts' > DESC 'If true, the CRL only contains revocations for end-entity certs, see > RFC3280 5.2.5' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > > 6.2.8 Issuing distribution point only contains CA certs > >This attribute may be used to indicate if the CRL only contains revocations for >CA certificates. > > (1.2.826.0.1.3344810.1.1.55 > NAME 'x509CRLDPOnlyCACerts' > DESC 'If true, the CRL only contains revocations for CA certs, see > RFC3280 5.2.5' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > > 6.2.9 Issuing distribution point only contains some reasons > >This attribute may be used to indicate if the CRL only contains some revocation >reason codes. > > (1.2.826.0.1.3344810.1.1.56 > NAME 'x509CRLDPOnlySomeReasons' > DESC 'If true, the CRL only contains some revocation reason codes, see > RFC3280 5.2.5' > EQUALITY bitStringMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) > > 6.2.10 Issuing distribution point only contains attribute certs > >This attribute may be used to indicate if the CRL only contains revocations for >attribute certificates. > > (1.2.826.0.1.3344810.1.1.57 > NAME 'x509CRLDPOnlyAttCerts' > DESC 'If true, the CRL only contains revocations for attribute certs, see > RFC3280 5.2.5' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > > 6.2.11 Issuing distribution point is indirect > >This attribute may be used to indicate if the CRL is an indirect CRL and holds >revocations of certificates issued by authorities other than the CRL issuer. > > (1.2.826.0.1.3344810.1.1.58 > NAME 'x509CRLDPindirect' > DESC 'If true, the CRL is an indirect CRL, see > RFC3280 5.2.5' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > >6.3 Delta CRL Indicator > >This attribute may be used to indicate if the CRL is a delta CRL. > > (1.2.826.0.1.3344810.1.1.59 > NAME 'x509CRLDeltaIndicator' > DESC 'Indicates this is a delta CRL, and the value points to the > sequence number of the issued base CRL to which this is a delta > - see RFC3280 5.2.4' > EQUALITY integerMatch > ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > SINGLE-VALUE ) > > 7. Attributes for CRL Revoked Certificate Fields > >The serial number attribute is as defined in [7]. > >7.1 Revocation date > >This attribute may be used to hold the revocationDate field of a CRL entry. > > (1.2.826.0.1.3344810.1.1.39 > NAME 'x509CRLCertRevocationDate' > DESC 'Date/time the CA actually revoked the certificate, > see - RFC3280 5.1.2.6' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE ) > >Note that the field in the CRL may be in UTC or GeneralizedTime format. If in >UTC format, the creator of this attribute MUST convert the UTC time into >GeneralisedTime format when creating the attribute value. > > 8. Attributes for Selected CRL Entry Extensions > >In line with the CRL profile RFC 3280 [5], the following CRL entry extensions >are supported: > - Invalidity date (defined here) > - Certificate issuer (defined here) > - Reason code (defined here) > - Hold instruction code (defined here) > > 8.1 Invalidity date extension > >This attribute may be used to hold the invalidity date of a certificate. > > (1.2.826.0.1.3344810.1.1.40 > NAME 'x509CRLCertInvalidityDate' > DESC 'date at which it is known or suspected that the private > key was compromised, see RFC3280 5.3.3' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE ) > > 8.2 Certificate issuer extension > >The certificate issuer extension is used in indirect CRLs to identify the issuer >of the certificate that is revoked. Separate attribute types are defined for all >choices of the ASN.1 type "GeneralName" except for "otherName", "x400Address" >and "ediPartyName". > > 8.2.1 Certificate issuer RFC 822 name > > (1.2.826.0.1.3344810.1.1.41 > NAME 'x509CRLCertIssuerRfc822Name' > DESC 'Internet electronic mail address of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded according to the syntax given in RFC >822 [11]. > > 8.2.2 Certificate issuer DNS name > > (1.2.826.0.1.3344810.1.1.42 > NAME 'x509CRLCertIssuerDnsName' > DESC 'Internet domain name of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded as Internet domain names in accordance >with RFC1035 [12]. > > 8.2.3 Certificate issuer directory name > > (1.2.826.0.1.3344810.1.1.43 > NAME 'x509CRLCertIssuerDN' > DESC 'Distinguished name of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > >Values of this attribute type must be encoded according to the syntax given in >RFC2253 [13]. > > 8.2.4 Certificate issuer uniform resource identifier > > (1.2.826.0.1.3344810.1.1.44 > NAME 'x509CRLCertIssuerURI' > DESC 'Uniform Resource Identifier of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY caseExactIA5Match > SUBSTR caseExactIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute must be encoded according to the syntax given in >RFC2396 [14]. > > 8.2.5 Certificate issuer IP address > > (1.2.826.0.1.3344810.1.1.45 > NAME 'x509CRLCertIssuerIpAddress' > DESC 'Internet Protocol address, of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >Values of this attribute type must be stored in the syntax given in Appendix B >of RFC2373 [16]. > > 8.2.6 Certificate issuer registered ID > > (1.2.826.0.1.3344810.1.1.46 > NAME 'x509CRLCertIssuerRegisteredID' > DESC 'Any registered OID of the certificate issuer, see > RFC3280 5.3.4' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > >registeredID is an identifier of any registered object assigned in accordance >with ITU-T Rec. X.660. [17] > > 8.3 Revocation reason code > >This field may be used to hold the coded reason for the revocation > > (1.2.826.0.1.3344810.1.1.47 > NAME 'x509CRLCertReasonCode' > DESC 'An integer code indicating the reason for the revocation, see > RFC3280 5.3.1' > EQUALITY integerMatch > ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) > > 8.4 Hold instruction code > >This attribute may be used to store the hold instruction code for the >certificate on the CRL. > > (1.2.826.0.1.3344810.1.1.103 > NAME 'x509CRLCertHoldInstructionCode' > DESC 'Any registered OID indicating a hold instruction, see > RFC3280 5.3.2' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > 9. Security Considerations > >This [Internet Draft/Standard] describes the subschema for the storage >and matching of PKI attributes derived from CRLs. It does not address the >protocol for the storage and retrieval of this information. s/subschema/schema/ >LDAP servers SHOULD use authentication and access control mechanisms to protect >the information during its storage and retrieval. > > 10. IANA Considerations > >This document uses the OID branch 1.2.826.0.1.3344810 to identify new LDAP >attribute types and object classes. A register of all OIDs allocated under this >branch is kept by the registered holder. This branch has been assigned to >TrueTrust Ltd, under its BSI assigned English/Welsh Registered Company number >[18]. > > 11. References > > Normative > >[1] Bradner, S. The Internet Standards Process -- Revision 3. RFC >2026 October 1996. > >[2] S.Bradner. "Key words for use in RFCs to Indicate Requirement >Levels", RFC 2119, March 1997. > >[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory >Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. > >[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", >RFC 2234, November 1997. > >[5] Housley, R., Polk, T., Ford, W. and D. Solo, "Internet X.509 Public Key >Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. > >[6] ITU, "Information Technology - Open Systems Interconnection - The >Directory: Public-key and attribute certificate frameworks", ITU-T >Recommendation X.509, March 2000. > >[7] Gietz, P., Klasen, N. "Internet X.509 Public Key Infrastructure Lightweight >Directory Access Protocol Schema for X.509 Certificates", >, July 2004 > >[11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD >11, RFC 822, August 1982. > >[12] Mockapetris, P., "Domain names - implementation and specification", STD 13, >RFC 1035, November 1987. > >[13] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol >(v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December >1997. > >[14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource >Identifiers (URI): Generic Syntax", RFC 2396, August 1998. > >[15] Hodges, J. and RL. Morgan, "Lightweight Directory Access Protocol (v3): >Technical Specification", RFC 3377, September 2002. > >[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC >2373, July 1998. > >[17] CCITT Recommendation X.660 (1992) | ISO/IEC 9834-1:1993, Information >technology - Open Systems Interconnection - Procedures for the operation of OSI >Registration Authorities: General procedures. > >[18] BRITISH STANDARD BS 7453 Part 1. Procedures for UK Registration for Open >System Standards Part 1: Procedures for the UK Name Registration Authority. > > Informative > >[8] Chadwick, D.W., Sahalayev, M. V. "Internet X.509 Public Key Infrastructure >LDAP Schema for X.509 Attribute Certificates", 02.txt>, October 2004 > >[9] Chadwick, D.W., Legg, S. "Internet X.509 Public Key Infrastructure - LDAP >Schema for PKIs " , July 2002 > >[10] Chadwick, D.W., Legg, S. "Internet X.509 Public Key Infrastructure - LDAP >Schema for PMIs" , July 2002 > >[19] S. Legg. "Lightweight Directory Access Protocol (LDAP) and X.500 Component >Matching Rules" RFC 3687, February 2004 > >[20] J. Allen, M. Mealling. "The Architecture of the Common Indexing Protocol >(CIP)". RFC 2651. August 1999. > > 12. 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. > > 13. Acknowledgments > >The authors would like to thank Peter Gietz for his help and co-operation, and >in particular his willingness to align [7] with this document. > >The authors would also like to thank TERENA, CESNET, SURFnet, UNINETT, RedIRIS >and SWITCH, who jointly partially funded this work, and without whose support >this work would not have been possible. > > 14. Copyright > >Copyright (C) The Internet Society (2001). This document is subject to the >rights, licenses and restrictions contained in BCP 78, and except as set forth >therein, the authors retain all their right. > >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. > > 15. Authors' Addresses > >David Chadwick, Mikhail Sahalayev >IS Institute >University of Salford >Salford >England >M5 4WT > >Email: d.w.chadwick@salford.ac.uk > M.Sahalayev@pgr.salford.ac.uk > > 16. Changes > >Changes since version 00. > >1. An alternative name form for revoked certificate entries has been added for >those LDAP servers that don't support multiple valued RDNs. >2. Name forms for delta CRL entries and authority revocation list entries have >been added >3. x509CRL object class has been changed to ABSTRACT and three new STRUCTURAL >object classes have been added for CRLs, ARLs and delta CRLs. >4. Corrected some OID assignments >5. Minor editorial corrections > >Changes since version 01 > >1. The object class structure has been re-vamped and x509base has been >transferred to the certificate schema ID [7] >2. Minor editorial corrections >3. Changed from Standards Track to Informational after discussions with area and >WP leaders. >4. Inserted IANA considerations section and Acknowledgement section > >Changes since version 01 > >1. Updated references