Network Working Group N. Klasen Internet-Draft P. Gietz Expires: August 28, 2002 DAASI International GmbH February 27, 2002 An LDAPv3 Schema for X.509 Certificates draft-klasen-x509certificate-schema Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 will expire on August 28, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes an LDAP schema which can be used to implement a certificate store for X.509 certificates. Specifically, a structural object class for a X.509 certificate is defined. Key fields of a certificate are stored as normal attributes so that applications can easily retrieve the certficates needed for encryption or chain building by using basic LDAP search filters. Multiple certificates for a single entity can be stored and retrieved Conventions used in this document Klasen, et al. Expires August 28, 2002 [Page 1] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 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 [RFC2119]. The following syntax specifications use the augmented Backus-Naur Form (ABNF) as described in [RFC2234]. Schema definitions are provided using LDAPv3 description formats [RFC2252]. Definitions provided here are formatted (line wrapped) for readability. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Comparison with Values Return Filter Control . . . . . . . 5 3. The x509certificate object class and its attribute types . 6 3.1 Attributes for mandatory fields of an X.509 certificate . 6 3.1.1 x509version . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 serialNumber . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 6 3.1.4 issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.5 validity . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.6 subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.7 subjectPublicKeyInfoAlgorithm . . . . . . . . . . . . . . 8 3.2 Attributes for selected extensions . . . . . . . . . . . . 8 3.2.1 Subject key identifier extension . . . . . . . . . . . . . 9 3.2.2 Key usage extension . . . . . . . . . . . . . . . . . . . 9 3.2.3 Policy information identifier extension . . . . . . . . . 9 3.2.4 Subject alternative name extension . . . . . . . . . . . . 10 3.2.4.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4.2 DnsName . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4.3 DirectoryName . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4.4 UniformResourceIdentifier . . . . . . . . . . . . . . . . 11 3.2.4.5 IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Isssuer alternatvie name extension . . . . . . . . . . . . 12 3.2.5.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5.2 DnsName . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5.3 DirectoryName . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5.4 UniformResourceIdentifier . . . . . . . . . . . . . . . . 13 3.2.5.5 IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.6 Extended key usage extension . . . . . . . . . . . . . . . 14 3.2.7 CRL distribution points extension . . . . . . . . . . . . 14 3.3 Additional attributes . . . . . . . . . . . . . . . . . . 15 3.3.1 Email addresses . . . . . . . . . . . . . . . . . . . . . 15 3.4 x509certificate object class . . . . . . . . . . . . . . . 15 4. DIT Structure and Naming . . . . . . . . . . . . . . . . . 17 Klasen, et al. Expires August 28, 2002 [Page 2] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 5. Security Considerations . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23 A. Sample directory entries . . . . . . . . . . . . . . . . . 24 B. Sample searches . . . . . . . . . . . . . . . . . . . . . 27 Full Copyright Statement . . . . . . . . . . . . . . . . . 28 Klasen, et al. Expires August 28, 2002 [Page 3] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 1. Introduction A key component in the wide-spread adoption of a PKI infrastructure is the general availabilty of public key and their certificates. Today, certificates are often published in an X.500 compliant directory service. These directories are accessed by applications using the LDAP v2 [RFC1777] or v3 [RFC2251] protocol. [RFC2559] defines a subset of LDAP v2 operations required for Internet X.509 Public Key Infrastructure. An LDAPv2 schema to PKI repository objects is specified in [RFC2587], were a set of attribute types and auxiliary object classes are defined. For stroring certficates, the "userCertficate" attribute type is used. All certificates of an entity are stored as values in a multi-valued attribute. This solution has a serious drawback. In LDAP, the smallest granularity of data access is the attribute. It is not possible to request a specific value of an attribute (see also [matchedval]). The directory server will therefore always return the full list of certficates of an entry to applications dealing with certificates. If the number of certficates for a entity is large this will result in considerable overhead. This document proposes the use of the x509certificate structural object class for storing certficates. Each certficate will be stored in a separate entry in the directory. Fields of certificates, which are needed to identify a certificate and those which are often used in searching for an appropriate certificate, are extracted from the certificate and stored as attributes of the entry. Applications can thus search for specific certficates with simple LDAP filters. The use of simple attributes also makes a large scale widely distributed certificate repository service possible by using an indexing service based on the Common Indexing Protocol [RFC2651]. Klasen, et al. Expires August 28, 2002 [Page 4] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 2. Comparison with Values Return Filter Control In [matchedval] a control has been defined that allows for only certain values of a specified attribute to be returned from a matching entry. In this section, this approach is compared with the one proposed in this document. The major benefit of the Values Return Filter Control is that it does not require any changes to the DIT. If a customer has deployed certificate information in such a way that individual entries have numerous certificates attached to them then the Values Return Filter Control is useful. While it is a simple matter to modify the DIT in such a way that all certificate information is removed from the entries, and placed in the container directly beneath the entries according to the definitions of this specification, it is less simple to simultaneously modify all of the applications that depend on certificates being stored in the entry. Thus, it may be desirable to duplicate the certificate information, by having it appear in the entry, as well as in the container beneath the entry for a short period of time, in order to allow for migration of the applications to the new LDAP schema. As in any situation in which information is duplicated, great care must be taken in order to insure the integrity of the information. There are several advantages in using the x509certificate object class. No special matching rules are needed to retrieve a specific certificate. Any field in the certificate can be used in the search filter. Even information that doesn't appear in the certificate can be used in a search filter. It is easier to remove certificates from the DIT, since the entire certificate DER encoding does not have to be supplied in the modify operation. Searches that don't need extensible matching rules and Values Return Filter Control will perform faster. Another advantage of the solution proposed here is that it will not necessary to modify existing server implementations to support this schema. The extended matching rules proposed in [pkix-ldap-schema] would require substantial changes the servers' indexing mechanisms. In contrast, servers implementing the x509certificate schema can easily levarage their indexing support for standard LDAPv3 syntaxes. Klasen, et al. Expires August 28, 2002 [Page 5] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3. The x509certificate object class and its attribute types 3.1 Attributes for mandatory fields of an X.509 certificate 3.1.1 x509version Version of the encoded certificate. ( 1.3.6.1.4.1.10126.1.5.3.1 NAME 'x509version' DESC 'Version of the certificate, X.509(2000) 7, RFC2459 4.1.2= =2E1' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) Values of this attribute may either be 0, 1 or 2 correspoding to X.509 v1, v2 or v3. 3.1.2 serialNumber The serial number is an integer assigned by the CA to each certificate. It is unique for each certificate issued by a given CA (i.e., the issuer name and serial number uniquely identify a certificate). ( 1.3.6.1.4.1.10126.1.5.3.2 NAME 'x509serialNumber' DESC 'Unique integer for each cerfiticate issued by a particular CA, X.509(2000) 7, RFC2459 4.1.2.2' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) 3.1.3 signatureAlgorithm OID identifying the algorithm and hash function used by the CA in signing the certificate. ( 1.3.6.1.4.1.10126.1.5.3.3 NAME 'x509signatureAlgorithm' DESC 'OID of the algorithm and hash function used by the CA in signing the certificate, X.509(2000) 7, RFC2459 4.1.2.3' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) Klasen, et al. Expires August 28, 2002 [Page 6] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.1.4 issuer String representation of the issuer's distinguished name. ( 1.3.6.1.4.1.10126.1.5.3.4 NAME 'x509issuer' DESC 'Distinguished name of the entity who has signed and issued the certificate, X.509(2000) 7, RFC2459 4.1.2.4' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) Values of this attribute type must be encoded according to the syntax given in [RFC2253]. 3.1.5 validity The "validity" attribute in an X.509 certficate consists of an ASN.1 sequence of two timestamps, which define the begin and end of the certficate's validity period. This sequence has been split up into two seperate attributes "x509validityNotBefore" and "x509validityNotAfter". The times are represented in string form as defined in [RFC2252]. ( 1.3.6.1.4.1.10126.1.5.3.5 NAME 'x509validityNotBefore' DESC 'Date on which the certificate validity period begins, X.509(2000) 7, RFC2459 4.1.2.5' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 1.3.6.1.4.1.10126.1.5.3.6 NAME 'x509validityNotAfter' DESC 'Date on which the certificate validity period ends, X.509(2000) 7, RFC2459 4.1.2.5' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 3.1.6 subject String representation of the subject's distinguished name. Klasen, et al. Expires August 28, 2002 [Page 7] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 ( 1.3.6.1.4.1.10126.1.5.3.7 NAME 'x509subject' DESC 'Distinguished name of the entity associated with this public-key, X.509(2000) 7, RFC2459 4.1.2.6' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) Values of this attribute type must be encoded according to the syntax given in [RFC2253]. 3.1.7 subjectPublicKeyInfoAlgorithm OID of the algorithm of which the certified public key is an instance of. ( 1.3.6.1.4.1.10126.1.5.3.8 NAME 'x509subjectPublicKeyInfoAlgorithm' DESC 'OID of the algorithm which this public key is an instance of, X.509(2000) 7, RFC2459 4.1.2.7' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) 3.2 Attributes for selected extensions As this specification intends to only facilitate applications in finding certficates, only those extensions have to be defined that might be searched for. Thus the following extensions described in [RFC2459] are not dealt with here: o authority key identifier extension o private key usage period extension o policy mappings extension o subject directory attributes extension o pathLenConstraint of basic constraints extension o name contraints extensions o policy contraints extensions o inhibit any policy extension Klasen, et al. Expires August 28, 2002 [Page 8] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.2.1 Subject key identifier extension This attribute identifies the public key being certified. It enables distinct keys used by the same subject to be differentiated. ( 1.3.6.1.4.1.10126.1.5.3.14 NAME 'x509subjectKeyIdentifier' DESC 'Key identifier which must be unique with respect to all key identifiers for the subject, X.509(2000) 8.2.2.2, RFC2459 4.2.1.2' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) 3.2.2 Key usage extension This attribute defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. ( 1.3.6.1.4.1.10126.1.5.3.15 NAME 'x509keyUsage' DESC 'Purpose for which the certified public key is used, X.509(2000) 8.2.2.3, RFC2459 4.2.1.3' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Values of this type are encoded according to the following BNF, so that each value corresponds to the respective bit in the ASN.1 "KeyUsage" bitstring: x509keyUsage-value =3D"digitalSignature" / "nonRepudiation" / "keyEncipherment" / "dataEncipherment" / "keyAgreement" / "keyCertSign" / "cRLSign" / "encipherOnly" / "decipherOnly" 3.2.3 Policy information identifier extension This attribute contains OIDs which indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. Klasen, et al. Expires August 28, 2002 [Page 9] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 ( 1.3.6.1.4.1.10126.1.5.3.16 NAME 'x509policyInformationIdentifier' DESC 'OID which indicates the policy under which the certificate has been issued and the purposes for which the certificate may be used, X.509(2000) 8.2.2.6, RFC2459 4.2.1.5' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) 3.2.4 Subject alternative name extension The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Separate attribute types are defined for all choices of the ASN.1 type "GeneralName" exept for "otherName", "x400Address" and "ediPartyName". 3.2.4.1 Rfc822Name ( 1.3.6.1.4.1.10126.1.5.3.17 NAME 'x509subjectAltNameRfc822Name' DESC 'Internet electronic mail address, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Values of this attribute must be encoded accroding to the syntax given in [RFC0822]. 3.2.4.2 DnsName ( 1.3.6.1.4.1.10126.1.5.3.18 NAME 'x509subjectAltNameDnsName' DESC 'Internet domain name, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 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]. Klasen, et al. Expires August 28, 2002 [Page 10] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.2.4.3 DirectoryName ( 1.3.6.1.4.1.10126.1.5.3.19 NAME 'x509subjectAltNameDirectoryName' DESC 'Distinguished name, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' 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]. 3.2.4.4 UniformResourceIdentifier ( 1.3.6.1.4.1.10126.1.5.3.20 NAME 'x509subjectAltNameUniformResourceIdentifier' DESC 'Uniform Resource Identifier for the World-Wide Web, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch 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]. 3.2.4.5 IpAddress ( 1.3.6.1.4.1.10126.1.5.3.21 NAME 'x509subjectAltNameIpAddress' DESC 'Internet Protocol address, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 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]. Klasen, et al. Expires August 28, 2002 [Page 11] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.2.4.6 RegisteredID ( 1.3.6.1.4.1.10126.1.5.3.22 NAME 'x509subjectAltNameRegisteredID' DESC 'OID of any registered object, X.509(2000) 8.3.2.1, RFC2459 4.2.1.7' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 3.2.5 Isssuer alternatvie name extension The issuer alternative names extension allows additional identities to be bound to the subject of the certificate. Separate attribute types are defined for all choices of the ASN.1 type "GeneralName" exept for "otherName", "x400Address" and "ediPartyName". 3.2.5.1 Rfc822Name ( 1.3.6.1.4.1.10126.1.5.3.23 NAME 'x509isssuerAltNameRfc822Name' DESC 'Internet electronic mail address, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Values of this attribute must be encoded accroding to the syntax given in [RFC0822]. 3.2.5.2 DnsName ( 1.3.6.1.4.1.10126.1.5.3.24 NAME 'x509isssuerAltNameDnsName' DESC 'Internet domain name, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 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]. Klasen, et al. Expires August 28, 2002 [Page 12] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.2.5.3 DirectoryName ( 1.3.6.1.4.1.10126.1.5.3.25 NAME 'x509isssuerAltNameDirectoryName' DESC 'Distinguished name, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' 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]. 3.2.5.4 UniformResourceIdentifier ( 1.3.6.1.4.1.10126.1.5.3.26 NAME 'x509isssuerAltNameUniformResourceIdentifier' DESC 'Uniform Resource Identifier for the World-Wide Web, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch 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]. 3.2.5.5 IpAddress ( 1.3.6.1.4.1.10126.1.5.3.27 NAME 'x509isssuerAltNameIpAddress' DESC 'Internet Protocol address, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 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]. Klasen, et al. Expires August 28, 2002 [Page 13] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.2.5.6 RegisteredID ( 1.3.6.1.4.1.10126.1.5.3.28 NAME 'x509isssuerAltNameRegisteredID' DESC 'OID of any registered object, X.509(2000) 8.3.2.2, RFC2459 4.2.1.8' 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. 3.2.6 Extended key usage extension This attribute indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the "x509keyUsage" attribute. These purposes are identified by their OID. ( 1.3.6.1.4.1.10126.1.5.3.30 NAME 'x509extKeyUsage' DESC 'Purposes for which the certified public key may be used (identified by OID), X.509(2000) 8.2.2.4, RFC2459 4.2.1.13' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 3.2.7 CRL distribution points extension This attribute identifies how CRL information for this certifacte can be obtained. ( 1.3.6.1.4.1.10126.1.5.3.31 NAME 'x509cRLDistributionPointURI' DESC 'DistributionPointName of type URI, X.509(2000) 8.6.2.1, RFC2459= 4.2.1.13' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) In this specification, only the "uniformResourceIdentifier" choice of "distributionPoint.fullName" field is supported. If this attribute exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be absent from the certificate, i.e. the CRL distributed by the distribution point contains revocations for all revocation reasons and the CRL issuer is identical to the certificate issuer. Values of this attribute must be encoded accroding to the URI syntax given in [RFC2396]. Klasen, et al. Expires August 28, 2002 [Page 14] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 3.3 Additional attributes 3.3.1 Email addresses The "mail" (0.9.2342.19200300.100.1.3) attribute from [RFC2798] is used to store the subject's email address. This attribute MUST be populated with the values from a subject alternative name extension of type rfc822Name if such an extension is present. Legacy applications conforming to [RFC2312] include an "EmailAddress" (1.2.840.113549.1.9.1) attribute in the subject's distinguished name. If the subject alternative name extension is absent from the certificate, this value MUST be used to populate the "mail" attribute. 3.4 x509certificate object class This structural object class contains the fields of an X.509 certificate that are used in searches as attributes. ( 1.3.6.1.4.1.10126.1.5.4.2.1 NAME 'x509certificate' STRUCTURAL MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $ x509validityNotBefore $ x509validityNotAfter $ x509subject $ x509subjectPublicKeyInfoAlgorithm ) MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier $ x509keyUsage $ x509policyInformationIdentifier $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID $ x509basicConstraintsCa $ x509extKeyUsage $ x509cRLDistributionPoint ) ) Entries of this structural object class MUST also have one of the one of the following auxiliary object classes: "pkiUser" or "pkiCA". This way the entry can contain the binary certificate in the "userCertificate" or "caCertficate" attribute. These object classes and attribute types are chosen to allow interoperability with older clients. As defined in [X.509-2000] the "pkiUser" and "pkiCA" object classes include the "userCertificate" and respectivly "caCertficate" attributes as optional attribute. Furthermore, both attributes are multi-valued. For the purpose of Klasen, et al. Expires August 28, 2002 [Page 15] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 this specification, each entry with a structural objectclass of x509certificate MUST have one and only one value of the userCertificate attribute or caCertificate attribute, respectively. Klasen, et al. Expires August 28, 2002 [Page 16] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 4. DIT Structure and Naming If the schema presented in this document is used to store certficate information in a directory that contains entries for organizations, persons, services, etc., each certficate belonging to an entity SHOULD be stored as a direct subordinate to the entity's entry. In this case, these entries MUST be named by a multi-valued RDN formed by the certficate issuer and serial number, as this is the only way to enforce unique RDN under the siblings. This is expressed in the following name form: --------------------------------------------------------------------- ( 1.3.6.1.4.1.10126.1.5.5.1 NAME "x509certficate nameform" OC x509certificate MUST ( x509issuer $ x509serial ) ) certficate name form --------------------------------------------------------------------- For public directories of CAs that, besides the data stored in the certficates, do not hold any additional data about end entities the folloing DIT structure might be preferable. Entries for certficates are stored directly below the issuing CA's entry. In this case these entries SHOULD be named by the certficate serial number. This is expressed in the following name form: --------------------------------------------------------------------- ( 1.3.6.1.4.1.10126.1.5.5.2 NAME "x509certficate alternate nameform" OC x509certificate MUST x509serial ) certficate alternate name form --------------------------------------------------------------------- Care must be taken, when encoding DNs, that contain an x509issuer attribute. Such a value is a string representation according to [RFC2253]. These strings contain RFC2253 special characters and must therefor be escaped. For example, the issuer name in a certificate may be: Klasen, et al. Expires August 28, 2002 [Page 17] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 x509issuer: OU=3DVeriSign Trust Network,OU=3D(c) 1998 VeriSign\2c Inc.= - For aut horized use only,OU=3DClass 1 Public Primary Certification Authority = - G2,O=3DV eriSign\2c Inc.,C=3DUS When used in a DN, this will be appear as: dn: x509serial=3D123456+x509issuer=3DOU\3dVeriSign Trust Network \2cOU= \3d(c) 199 8 VeriSign\5c\2c Inc. - For authorized use only\2cOU\3dClass 1 Public= Prima ry Certification Authority - G2\2cO\3dVeriSign\5c\2c Inc.\2cC\3dUS,cn= =3DJoe E xample Klasen, et al. Expires August 28, 2002 [Page 18] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 5. Security Considerations Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations or devices. Most countries have privacy laws regarding the publication of information about people. Without additional mechanisms such as Operation Signatures [RFC2649] which allow a client to verify the origin and integrity of the data contained in the attributes defined in this document, a client MUST NOT treat this data as authentic. Clients MUST only use - after proper validation - the data which they obtained directly from the binary certificate. Directory administrators MAY deploy ACLs which limit access to the attributes defined in this document to search filters. Transfer of cleartext passwords is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties. In order to protect the directory and its contents, strong authentication MUST have been used to identify the Client when an update operation is requested. Klasen, et al. Expires August 28, 2002 [Page 19] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 6. Acknowledgements This document borrows from a number of IETF documents, including [certinfo-schema]. The authors wish to thank Michael Str=C3=B6der for his significant contribution to this document. This work is part of the DFN Project "Ausbau und Weiterbetrieb eines Directory Kompetenzzentrums" funded by the German ministry of research (BMBF). This document has been written in XML according to the DTD specified in RFC2629. xml2rfc has been used to generate an RFC2033 compliant plain text form. The XML source and a HTML version are available on request. Klasen, et al. Expires August 28, 2002 [Page 20] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 References [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998. [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Klasen, et al. Expires August 28, 2002 [Page 21] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 [RFC2459] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [RFC2559] Boeyen, S., Howes, T. and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC2587] Boeyen, S., Howes, T. and P. Richard, "Internet X.509 Public Key Infrastructure LDAPv2 Schema", RFC 2587, June 1999. [RFC2649] Greenblatt, B. and P. Richard, "An LDAP Control and Schema for Holding Operation Signatures", RFC 2649, August 1999. [RFC2651] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999. [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000. [X.501-93] ITU, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T Recommendation X.501, November 1993. [X.509-2000] ITU, "Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, March 2000. [certinfo-schema] Greenblatt, B., "LDAP Object Class for Holding Certificate Information", Internet Draft (work in progress), Februar 2000, . [matchedval] Chadwick, D. and S. Mullan, "Returning Matched Values with LDAPv3", Internet Draft (work in progress), December 2000, . [pkix-ldap-schema] Chadwick, D. and S. Legg, "Internet X.509 Public Key Infrastructure - Additional LDAP Schema for PKIs and PMIs", Internet Draft (work in progress), November 2001, . Authors' Addresses Norbert Klasen DAASI International GmbH Wilhelmstr. 106 T=C3=BCbingen 72074 DE EMail: norbert.klasen@daasi.de Peter Gietz DAASI International GmbH Wilhelmstr. 106 T=C3=BCbingen 72074 DE Phone: +49 7071 29 70336 EMail: peter.gietz@daasi.de URI: http://www.daasi.de/ Bruce Greenblatt DTASI 6841 Heaton Moor Drive San Jose, CA 95119 US Phone: +1 408 224 5349 EMail: bgreenblatt@directory-applications.com URI: http://www.dtasi.com/ Klasen, et al. Expires August 28, 2002 [Page 23] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 Appendix A. Sample directory entries A sample x509certificate directory entry for an intermediate CA in LDIF format: dn: x509serialNumber=3D4903272,EMAILADDRESS=3Dcertify@pca.dfn.de,CN=3D= DFN Topl evel Certification Authority,OU=3DDFN-PCA,OU=3DDFN-CERT GmbH,O=3DDeut= sches Fo rschungsnetz,C=3DDE objectclass: x509certficate x509version: 2 x509serialNumber: 4903272 x509issuer: EMAILADDRESS=3Dcertify@pca.dfn.de,CN=3DDFN Toplevel Certif= icatio n Authority,OU=3DDFN-PCA,OU=3DDFN-CERT GmbH,O=3DDeutsches Forschungsn= etz,C=3DDE x509validityNotBefore: 20020110170112Z x509validityNotAfter: 20060110170112Z x509subject: EMAILADDRESS=3Dca@daasi.de,OU=3DDAASI CA,O=3DDAASI Intern= ational GmbH,C=3DDE x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 x509basicConstraintsCa: TRUE x509keyUsage: keyCertSign x509keyUsage: cRLSign x509subjectKeyIdentifier:: 5nrZFpVK4RKfIglqQ4N4JXBS4Bk=3D x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/= g1 /data/crls/root-ca-crl.crx x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/= g1 /data/crls/root-ca-crl.crl x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1 mail: ca@daasi.de objectClass: pkiCa caCertificate;binary:: MIIHTTCCBjWgAwIBAgIDStFoMA0GCSqGSIb3DQEBBQUAMIG= sM QswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MRYwFA= YD VQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEyRERk4gV= G9 wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmNlcnRp= Zn lAcGNhLmRmbi5kZTAeFw0wMjAxMTAxNzAxMTJaFw0wNjAxMTAxNzAxMTJaMF8xCzAJBgN= VB AYTAkRFMSEwHwYDVQQKExhEQUFTSSBJbnRlcm5hdGlvbmFsIEdtYkgxETAPBgNVBAsTCE= RB QVNJIENBMRowGAYJKoZIhvcNAQkBFgtjYUBkYWFzaS5kZTCCASIwDQYJKoZIhvcNAQEBB= QA DggEPADCCAQoCggEBAKmQBp+Gr28/qlEWjnJoiH3AwmhNEYMRWgXMXMMjM3S4mSmXZ8FZ= fT SPhi5O1zx5nyHecfl01fAO79Kpc6XkOTOl4iKBwu7+DM6my9Iizp2puhOQ6iuuchAIyJQ= PR 0lfWAvvW+4n7Nf13Js5qFHvXBDqvgt6fud1l8XZ4nPWBSbs6OnB4EUDlRLx5fdCX2sEPQ= IN Keu0INMtjHI6eGbspmahup0ArPA9RYZVjVq6ZHkh4205/JAhji9KtFifKCztXNTRMba7A= Hd 2uS6GbF9+chGLPWGNZKtMhad1SvU7Zlw/ySHkFbBFZMu6x3kAVgwW8gKQa5qSFnMw/WTK= AT JRPekCAwEAAaOCA8IwggO+MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1U= dD gQWBBTmetkWlUrhEp8iCWpDg3glcFLgGTCB2wYDVR0jBIHTMIHQgBQGC/q1+Eh4oyCxCz= 7P oNDE0X990KGBsqSBrzCBrDELMAkGA1UEBhMCREUxITAfBgNVBAoTGERldXRzY2hlcyBGb= 3J zY2h1bmdzbmV0ejEWMBQGA1UECxMNREZOLUNFUlQgR21iSDEQMA4GA1UECxMHREZOLVBD= QT EtMCsGA1UEAxMkREZOIFRvcGxldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSEwHwY= JK oZIhvcNAQkBFhJjZXJ0aWZ5QHBjYS5kZm4uZGWCAxXP/TCBpQYDVR0fBIGdMIGaMEugSa= BH hkVodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NTA5L2cxL2RhdGEvY= 3J Klasen, et al. Expires August 28, 2002 [Page 24] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 scy9yb290LWNhLWNybC5jcngwS6BJoEeGRWh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0= aW ZpY2F0aW9uL3g1MDkvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDARBglghkgBhvh= CA QEEBAMCAQYwSwYJYIZIAYb4QgEIBD4WPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aW= Zp Y2F0aW9uL3BvbGljaWVzL3g1MDlwb2xpY3kuaHRtbDCB+QYJYIZIAYb4QgENBIHrFoHoV= Gh pcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGJ5IHRoZSBERk4tUENBLCB0aGUgVG9wCkxl= dm VsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIHRoZSBHZXJtYW4gUmVzZWFyY2gKTmV= 0d 29yayAoRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6LCBERk4pLgpUaGUga2V5IG93bmVyJ3= Mg aWRlbnRpdHkgd2FzIGF1dGhlbnRpY2F0ZWQgaW4KYWNjb3JkYW5jZSB3aXRoIHRoZSBER= k4 tUENBIHg1MDkgUG9saWN5LjA3BglghkgBhvhCAQMEKhYoaHR0cHM6Ly93d3cuZGZuLXBj= YS 5kZS9jZ2kvY2hlY2stcmV2LmNnaTBkBgNVHSAEXTBbMFkGCysGAQQB2RqCLAEBMEowSAY= IK wYBBQUHAgEWPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aWZpY2F0aW9uL3BvbGljaW= Vz L3g1MDlwb2xpY3kuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAU9GmwCW6LwsyHfC241afl= dq j/GULv8mfSkUEpK2OtYU1JAYFzmQx69iweOKHbgXZKZA2Wox+9AydIe98MJCSCOFKYjkz= gX U4fEZbEgnZBo+/1+W2BoB6gFAWy77KVHgimA7AqCcfbObeyCmyfLg1ro8/KpE01OjNr0S= +E fZ3gX9sezjVkCy12HBNQknz/hT2af25UUhyFTcvUY4xvlKAQpla29qyO28sfO93Qhkum6= SU 2XPlsKU+3lyqF33Xy84Y2z8ScVlsMuVWbUGtmVshnpT5K91n42pu/f0rLtkZDssEDbcLn= QD LWEz1aUDkLC++4CeFJxC/Dd/SOrE0yR0hNQ=3D A sample x509certificate directory entry for an end identity in LDIF format: Klasen, et al. Expires August 28, 2002 [Page 25] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 dn: x509serialNumber=3D1581631808272310054353257112721713,EMAILADDRESS= =3Dcer tificate@trustcenter.de,OU=3DTC TrustCenter Class 1 CA,O=3DTC TrustCe= nter f or Security in Data Networks GmbH,L=3DHamburg,ST=3DHamburg,C=3DDE objectclass: x509certficate x509version: 2 x509serialNumber: 1581631808272310054353257112721713 x509issuer: EMAILADDRESS=3Dcertificate@trustcenter.de,OU=3DTC TrustCen= ter Cl ass 1 CA,O=3DTC TrustCenter for Security in Data Networks GmbH,L=3DHa= mburg, ST=3DHamburg,C=3DDE x509validityNotBefore: 20011030180757Z x509validityNotAfter: 20021030180757Z x509subject: EMAILADDRESS=3Dnorbert.klasen@daasi.de,CN=3DNorbert Klase= n,C=3DDE x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 mail: norbert.klasen@daasi.de objectClass: pkiUser userCertificate;binary:: MIIDOTCCAqKgAwIBAgIOTfsAAAACxOstmlOu2TEwDQYJK= oZ IhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH= Ew dIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF= 0Y SBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMS= kw JwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw0wMTEwMzAxO= DA 3NTdaFw0wMjEwMzAxODA3NTdaME4xCzAJBgNVBAYTAkRFMRcwFQYDVQQDEw5Ob3JiZXJ0= IE tsYXNlbjEmMCQGCSqGSIb3DQEJARYXbm9yYmVydC5rbGFzZW5AZGFhc2kuZGUwgZ8wDQY= JK oZIhvcNAQEBBQADgY0AMIGJAoGBAL8+XK98p4YjD7Wq7ApmhAN/j2tfVsFCS0ufy12vGp= Et G4ny1tbbBORCJI8vIlDr2/vVTESl6UjzceloVUCib5V855mKUVmLL9Ay4qQLFd4wAoRSP= Au 9DkfbR+ygjzaYq+MUKMwaB61sG6911xk/e2/IIq8/IHKrRoYQGmHkaaJpAgMBAAGjgaow= ga cwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5= lc zARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0dHBzOi8vd3d3LnRydX= N0 Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS80REZCMDAwMDAwMDJDNEVCMkQ5Q= TU zQUVEOTMxPzANBgkqhkiG9w0BAQQFAAOBgQCrAzuZzLztupeqcHa8OUOcnRuTacMpBEeI= Cb ZMKv6mN9rMYkAxFKerj/yXbdCE8/3X3L00eGj+a8A7PumATiJSfmvYqa4EMZwHC2FFqPx= Yy Aj+xVuSlL5AC4HGHu4SOCp/UJu1xysoD16chOOLpj7+ZWZWLHIjA3zeXwUGl4kFvw=3D=3D= Klasen, et al. Expires August 28, 2002 [Page 26] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 Appendix B. Sample searches This section details how clients should access the certstore. The searches are presented in LDAP URL format. Retrieve all certificates for an end entity from a certstore using the first DIT structure: ldap:///CN=3DNorbert%20Klasen,O=3DDAASI%20International%20GmbH,C=3Dde?= userCertificate;binary?one?(objectClass=3Dx509certificate) Find a certificate in a trustcenter's certstore suitable for sending an encrypted S/MIME message to "norbert.klasen@daasi.de" ldap:///O=3DTC%20TrustCenter%20for%20Security%20in%20Data%20Networks %20GmbH,L=3DHamburg,ST=3DHamburg,C=3Dde?userCertificate;binary?sub? (&(objectClass=3Dx509certificate)(mail=3Dnorbert.klasen@daasi.de) (|(x509keyUsage=3DkeyEncipherment)(x509keyUsage=3DkeyAgreement) (x509extendedKeyUsage=3D1.3.6.1.5.5.7.3.4))) Find a CA certificate by its "subjectKeyIdentifier" obtained from the "keyIdentifier" field of the "autorityKeyIdentifier" extension in an end entity certificate: ldap:///?caCertificate;binary?sub? (&(objectClass=3Dx509certificate)(x509subjectKeyIdentifier=3D%5CE6 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43%5C83 %5C78%5C25%5C70%5C52%5CE0%5C19)) Klasen, et al. Expires August 28, 2002 [Page 27] =0C Internet-Draft An LDAPv3 Schema for X.509 Certificates February 2002 Full Copyright Statement 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Klasen, et al. Expires August 28, 2002 [Page 28]