Internet-Draft David Chadwick PKIX WG University of Salford Intended Category: Standards Track Expires: 11 February 2003 12 August 2002 Internet X.509 Public Key Infrastructure The use of Permanent Identifiers in LDAP Distinguished Names 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 LDAPEXT working group discussion list: ietf-pkix@imc.org or directly to the author. ABSTRACT This document defines a standard way of using Permanent Identifiers in LDAP distinguished names, in order to facilitate the allocation of globally unique distinguished names to PKI subjects, and to allow the certificates of these subjects to be easily retrieved from LDAP servers. 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]. 1. Introduction and Rationale Permanent Identifiers [3] may be used to permanently identify people. They can be used in the subjectAltName extension as an otherName form as described in [3]. In some PKI contexts it may be desirable to locate the certificates of subjects in LDAP servers, based on their Permanent Identifiers, but this is not possible with the LDAP technology available today if the PI is only stored in subjectAltName extension of the certificate, since no LDAP matching rules or software tools are available to support this. The PI would need to be stored in a separate LDAP attribute (or attributes) in order to facilitate LDAP searching, and this ID defines a pair of LDAP attributes that could be used for this purpose. Alternatively, if the PI is used to form part of the LDAP distinguished name of a subject, then LDAP searching is not necessary as the certificates can be read directly from the entry of the subject's DN. This document describes one way of doing this mapping, to yield the following advantages: i) it gives CAs and AAs an easy method of allocating globally unique distinguished names to certificate subjects and holders ii) it allows a person to be allocated multiple public key and attribute certificates to the same subject/holder name, but with different issuing CAs and AAs iii) it means that PKI components may not need to implement the PI subjectAltName extension as the same information can be carried in the subject field iv) it facilitates the look up of a subject's certificates in one or more LDAP directory servers without the need for searching 2. Possible Alternative Mappings There are two things that a relying party needs to know in conjunction with permanent identifiers, namely: - which authority assigned the PI (herein after called the naming authority) - the value of the permanent identifier. There are several possible ways of mapping PIs into LDAP DNs. Note that in all the following examples, LDAP DNs have been converted into string representations as described in [4] and [5]. i) Use the pre-existing serialNumber attribute type to hold the PI value, and define a new PI authority attribute to identify the naming authority e.g. SerialNumber=12345, PIAuth=DHSS, C=GB ii) Use the pre-existing serialNumber attribute to hold the PI value and use the existing OrganisationalName attribute to hold the naming authority e.g. SerialNumber=12345, O=Department of Health and Social Security, C=GB iii) Use a new PI attribute to hold the permanent identifier value, and the existing OrganisationalName attribute to hold the naming authority e.g. PI=12345, O=Department of Health and Social Security, C=GB iv) Define a new attribute type for each permanent identifier, defined by the naming authority for the PI e.g. DHSSNo=12345, C=GB v) Use a new PIAuth attribute to hold the naming authority, and a new PI attribute to hold the permanent identifier value e.g. PI=12345, PIAuth=DHSS, C=GB Note. If PKIs wish to hold user friendly names as well as PIs in subject DNs, then this could be done by either using a multi-valued RDN for the subject, as in CN=David Chadwick + PI=12345,... or by creating a child entry, as in CN=David Chadwick, PI=12345,... 3. Advantages and Disadvantages of the Alternatives It is clearly advantageous from an LDAP perspective to use pre-existing and defined attribute types whenever possible. This will minimise reconfiguration and administrative tasks and maximise interworking. However if the semantics of the pre-existing attribute types are too vague or imprecise, then it will not be possible for a user of the attribute type to imply the correct semantics from the vague definition. Further pre-existing attribute types may not be able to hold the complete range of syntaxes of permanent identifiers. Alternative ii) is one extreme and uses only pre-existing attribute types. Existing LDAP implementations can therefore easily use it. However, a RP will not necessarily know that the serial number is a permanent identifier of the subject. Further serial numbers hold values of PrintableSting syntax whereas PIs in [3] can be IA5 of UTF8 string syntax. Alternative iv) is the other extreme and uses a new attribute type for each type of permanent identifier. This will have the most precise semantics for each PI, and is similar to the original PI concept in [3] where a new OID is registered for each new PI. However, from an LDAP perspective it is likely to cause the most interworking problems, and naming authorities may find it difficult to register the new PI naming attribute that they have created. Alternatives i) and iii) are variants on a theme, and require just one new LDAP attribute type to be defined. In alternative i) a new PI authority attribute type is defined, to identify the PI authority. As part of this definition it would need to be explicit that PI authorities MUST use the existing serialNumber attribute type to hold the permanent identifiers, and that these MUST be in the subordinate RDN. It would then be obvious to users of the subject name who the PI authority is and what the PI value is. However this solution would only work for those PIs that have a PrintableString syntax. In contrast, alternative iii) defines a new PI attribute type to hold permanent identifier values, and implicit in the LDAP DN structure is the fact that the superior RDN is the PI authority. The PI authority could be named by any suitable pre-existing LDAP attribute type, for example, a country (C), an organisation (O), an organisational unit (OU) or a domain name (DC). It is obvious to users of the subject name what the PI value is, but it is imprecise as to exactly who the PI authority is. Alternative v) creates two new attribute types, one for the PI naming authority and one for the PI value. The new attributes have clear semantic meaning to the users of the subject DNs, and have syntaxes capable of holding any PIs. This is the approach recommended in this document. 4. PI Attributes Two new LDAP attribute types are defined, one to hold the PI authority and one to hold the PI value. By using two separate LDAP attributes, each having a pre-existing LDAP syntax, means that existing LDAP servers will be able to store these attributes and search for them using existing software machinery. They will also be able to create entries for them where these attributes form part of the distinguished name. 4.1 The PI Authority Attribute Type The PI Authority attribute type identifies an authority responsible for allocating permanent identifiers. The attribute is multi-valued, and if multiple values are stored in the pIAuth attribute of a directory server, each value represents an alternative name for the same PI Authority. ( 1.2.826.0.1.3344810.1.1.34 NAME 'piAuth' SUP name ) piAuth is a subtype of the generic name attribute type and the definition of the latter can be found in [8]. 4.2 The PI Attribute Type The PI attribute type holds a permanent identifier. It is single valued. ( 1.2.826.0.1.3344810.1.1.35 NAME 'pi' SUP name SINGLE-VALUE ) 5. Mapping suggestions Ways of mapping from permanent identifiers conforming to [3] into subject DNs are suggested in the following sections. 5.1 Conversion of URI PI Types The suggested mapping between URI PI types and LDAP DNs is as follows. The identifier value becomes the PI attribute value. The DNS host name of the URI is converted into an LDAP DC based DN according to [9], and the path becomes the value of the piAuth attribute. For example, if the PI has a value of {5445,http://xmlns.nist.gov/ssn} this would create a subject DN of pi=5445,piAuth=ssn,dc=xlms,dc=nist,dc=gov Note that the protocol specific features of a URI, i.e. the scheme/protocol and port number, are not relevant to creating a globally unique distinguished name for the subject. Further, if LDAP repositories are being used, then the information about the naming authority located at the URI can equally well be stored in the LDAP repository in the entry of the PI naming authority. 5.2. Conversion of OID PI Types At least two alternative mapping scenarios are possible. The first mapping requires the PI naming authority to separate the OID into the prefix that identifies the organisation, and the suffix that identifies the PI naming authority/type (as referred to in [3]). A pre- existing user friendly name for the organisation is then chosen and turned into a LDAP DN by the organisation e.g. this could be its domain name and converted into a DC style distinguished name according to [9], or it could be a pre-existing X.521 based DN (for example every limited company in the UK has been allocated an X.500/LDAP DN by [10]). A user friendly name is also chosen for the PI naming authority/type and this becomes the value of the piAuth attribute (this value could be the same as the one used in the path of the equivalent URI). For example, if the PI has a value of {5445,1.2.3.4.5}, where 1.2.3 is the OID of the organisation My Organisation (myorg.com), and 4.5 is the OID component for the PI naming authority/type whose user friendly name is SSN, this would create a subject DN of pi=5445,piAuth=SSN,dc=myorg,dc=com The second mapping simply takes the OID value of the identifier type and uses this as the value for the piAuth attribute using the string encoding rules for object identifiers defined in [11]. It takes the value of the identifier as the value of the PI attribute. For example, if the PI has a value of {5445,1.2.3.4.5}, the subject DN would become pi=5445,piAuth=1.2.3.4.5 6. Security Considerations The following security considerations are specific to the handling of distinguished names. LDAP security considerations are discussed in [6] and other documents comprising the LDAP Technical Specification [7]. 7. Acknowledgements Tom Gindin for many discussions about the PI ID [3]. 8. Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. References [1] S. Bradner. "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] D.Pinkas, T. Gindin. "Internet X.509 Public Key Infrastructure Permanent Identifier". , June 2002 [4] D. Chadwick. "LDAPv3 DN strings for use with PKIs", , April 2002. [5] K. Zeilenga. "LDAP: String Representation of Distinguished Names". ,l March 2002 [6] J. Sermersheim (editor), "LDAP: The Protocol", , a work in progress. [7] K. Zeilenga (editor), "LDAP: Technical Specification Road Map", , a work in progress. [8] M.Wahl. "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [9] Kille, S et.al. "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, Jan 1998 [10] BRITISH STANDARD BS 7453 Part 1. Procedures for UK Registration for Open System Standards Part 1: Procedures for the UK Name Registration Authority. [11] Wahl, M., Coulbeck, A., Howes, T., Kille, S. "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions". RFC 2252. December 1997. 10. Authors Address David Chadwick IS Institute University of Salford Salford M5 4WT England Email: d.w.chadwick@salford.ac.uk Tel: +44 161 295 5351