Internet DRAFT - draft-chadwick-pkix-pidn
draft-chadwick-pkix-pidn
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
<draft-chadwick-pkix-pidn-00.txt>
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". <draft-ietf-pkix-pi-05.txt>, June 2002
[4] D. Chadwick. "LDAPv3 DN strings for use with PKIs", <draft-ietf-
pkix-dnstrings-00.txt>, April 2002.
[5] K. Zeilenga. "LDAP: String Representation of Distinguished Names".
<draft-ietf-ldapbis-dn-07.txt>,l March 2002
[6] J. Sermersheim (editor), "LDAP: The Protocol", <draft-ietf-ldapbis-
protocol-xx.txt>, a work in progress.
[7] K. Zeilenga (editor), "LDAP: Technical Specification Road Map",
<draft-ietf-ldapbis-roadmap-xx.txt>, 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
