Here is the draft that Steve Crocker was talking about in his most recent
messages. I haven't yet submitted this to the Internet Drafts repository
since it needs a bit of polishing/discussion first.
Cheers,
Rhys.
---cut-here---
Network Working Group Rhys Weatherley
Internet Draft Queensland University of Technology
March, 1994
Encoding Internet Names as X.500 Distinguished Names for use in PEM
Status of this Memo
This document is an Internet Draft. 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. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It
is not appropriate to use Internet Drafts as reference material or to
cite them other than as a "working draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the status of this or any other Internet
Draft.
Distribution of this memo is unlimited.
Abstract
This memo defines mechanisms for encoding Internet domain names and
e-mail addresses as X.500 Distinguished Names (DN's) for use in
Privacy-Enhanced Mail (PEM) certificates. The intention is to aid
faster deployment of PEM on the Internet in the current absence of
wide-spread X.500 naming authorities and X.500 directory servers.
The mechanisms described here are intended to make it relatively easy
to tell instantly whether or not a DN contains an encoding of an
Internet domain name or e-mail address, so that compliant software
can display the Internet-friendly version if it wishes.
Note: some of the mechanisms in this memo are suggestions only, that
require further discussion to determine the best mechanism for the
long term.
1. Introduction
The PEM certificate format, described in [PEM2] and extended by
[PKCS6], associates the X.500 distinguished name of an entity with a
public key. The certificate also includes the distinguished name of
a Certification Authority (CA) issuer and a signature on the entity's
name and public key, signed using the issuer's private key. This
Weatherley DRAFT - expires 9/7/94 [Page 1]
RFC DRAFT March 1994
format provides a basis for issuing, distributing, and revoking keys
and for establishing trust relationships between communicants.
However, it will be quite some time before the X.500 naming
authorities and directory servers are wide-spread enough on the
Internet to make the process of a user obtaining a DN fairly
painless. In the mean-time, organisations are left making a "best
guess" as to what their DN would be with the attendant problems of
namespace collision.
In addition, one of the biggest growth areas of the Internet at the
moment is on the fringes, where small public access setups are
expanding the Internet to the public at large. In many cases, these
setups are private individuals who do not have an organisation name
that could be transformed into a suitable DN. Residential CA
hierarchies are not wide-spread enough internationally to be useful
to these individuals at present.
This situation will change over time, but currently PEM deployment is
suffering because of a lack of DN authorities, and because of a lack
of an established mapping between DN's and e-mail addresses.
On the Internet there is an existing naming authority, the Domain
Name System, which is in wide-spread use and already has procedures
for allocating names on a first-come, first-served basis. The
purpose of this memo is to define a method for encoding Internet
domain names and e-mail addresses so that if an individual or
organisation cannot obtain or decide upon a unique DN, or who would
rather use their Internet address, they can synthesise a DN based on
their existing Internet address.
The method described in this memo can be extended to the provision of
CA hierarchies based on the existing domain name system, such that
the PEM rules of name subordination are upheld [PEM2]. The provision
of such hierarchies is not a precondition for the deployment of this
method: they can be added (or not added) at a later date as local
policy dictates.
This memo in no way implies that an organisation or individual must
use this method if they have an Internet address. They can use
"traditional" DN's instead if they wish.
2. Notation
The following notation is used to represent X.500 distinguished names
in this memo:
DN ::= "<" 1*("," RDN) ">"
Weatherley DRAFT - expires 9/7/94 [Page 2]
RFC DRAFT March 1994
RDN ::= "{" 1*("," Identifier "=" String) "}"
That is, a DN is a list of one or more RDN's, each of which is a set
of (identifier, string) pairs. It is assumed that the first RDN is
at the start of the DER encoding of the name.
3. Basic Encoding Algorithm
The basic encoding algorithm takes an Internet domain name or an
Internet e-mail address, and transforms it into an X.500
distinguished name. By applying the reverse of this algorithm, an
encoding may be converted back into the original domain name or e-
mail address. This reversibility may be convenient for PEM receiving
software which wants to display the address in the conventional
Internet style, rather than displaying the X.500 encoding.
The encoding makes use of the "domainComponent" (DC) and
"rfc822Mailbox" (RM) object identifiers which are defined in [OSI-
DS]. The values are replicated here for convenience:
domainComponent ::= {ccitt 9 2342 19200300 100 1 25}
rfc822Mailbox ::= {ccitt 9 2342 19200300 100 1 3}
The representation of each of these attributes is IA5String. [Can
someone help me here? I've forgotten the numbers for "ccitt".]
An Internet domain name of the form "c1.c2.c3...cn", where the ci's
are domain components, is transformed as follows:
<{DC=cn}, ..., {DC=c3}, {DC=c2}, {DC=c1}>
Where all of the ci's have been converted to lower case. An example
of this encoding is the DN for the domain "fit.qut.edu.au":
<{DC=au}, {DC=edu}, {DC=qut}, {DC=fit}>
The encoding algorithm for Internet e-mail addresses is similar.
Everything to the right of the last '@' symbol in the e-mail address
is encoded in the same way as domain names above. Everything to the
left of the last '@' symbol (the local part) is encoded as an
IA5String and becomes the "rfc822Mailbox" (RM) attribute of the DN.
The case of the characters in the local part is preserved. For
example, "rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au" and
"jueneman%wotan(_at_)gte(_dot_)com" become:
<{DC=au}, {DC=edu}, {DC=qut}, {DC=fit}, {RM=rhys}>
<{DC=com}, {DC=gte}, {RM=jueneman%wotan}>
Weatherley DRAFT - expires 9/7/94 [Page 3]
RFC DRAFT March 1994
This encoding guarantees reversibility of the mapping, and can
adequately accommodate all of the Internet addressing forms currently
in use.
Note that some of the punctuation characters in the IA5 character set
have different meanings in different localities. The international
reference version should be used, which has 7-bit ASCII as a subset.
The e-mail address encodings may include an optional "commonName"
(CN) attribute in the same set as the "rfc822Mailbox" attribute,
indicating the actual name of the entity. For example:
<{DC=au}, {DC=edu}, {DC=qut}, {DC=fit}, {RM=rhys, CN="Rhys
Weatherley"}>
This provides greater flexibility, and permits translation of the
common Internet "name <address>" and "address (name)" formats. The
"commonName" attribute is optional, but encouraged. Any of the usual
string representations for the attribute may be used.
The encodings described above are intended to guarantee some level of
uniqueness with respect to other X.500 naming authorities. Compliant
PEM implementations would normally conceal the X.500 structure from
the user and present the Internet syntax.
4. Specifying E-mail Addresses In Traditional DN's
It may sometimes be desirable for a user with a traditional X.500 DN
to include their e-mail address in the DN so that it can be signed
and bound to the user's public key together with the DN. To
facilitate this, a RM attribute may appear in a traditional DN as a
member of the same set as the CN attribute. An example of this is
the following:
<{C=AU}, {O="Queensland University of Technology"}, {OU="Faculty
of Information Technology"}, {CN="Rhys Weatherley",
RM="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}>
Note that there are now two meanings for the RM attribute. They may
be distinguished by the presence of a DC attribute. If there is a DC
attribute in the DN, then the RM attribute has the meaning from
section 3, and if there is no DC attribute in the DN, then the RM
attribute has the meaning from this section.
5. Interleaving Traditional DN's With Internet Addresses
[Note: this mechanism was suggested by Steve Crocker. I'm not sure I
like it myself at the moment. It needs lots of discussion. It also
Weatherley DRAFT - expires 9/7/94 [Page 4]
RFC DRAFT March 1994
needs consultation with X.500 experts to determine if it is
feasible/desirable.]
It is possible to interleave the encodings presented in section 3
with a traditional DN, to produce a single DN which contains both a
traditional DN and an e-mail address encoding. Two examples follow:
<{DC=au, C=AU}, {DC=edu}, {DC=qut, O="Queensland University of
Technology"}, {DC=fit, OU="Faculty of Information Technology"},
{RM=rhys, CN="Rhys Weatherley"}>
<{C=US}, {DC=com}, {DC=gte, O="GTE Laboratories"},
{RM="jueneman%wotan", CN="Bob Jueneman"}>
These encodings can be processed in two separate ways by compliant
PEM implementations to extract the traditional DN and the e-mail
address.
This mechanism does have one slight draw-back: it is difficult, if
not impossible, to automate the process of choosing which domain
component corresponds to which attribute in the traditional DN to
interleave the two. Therefore, user input would be required to guide
the DN-creation process. The mechanisms from sections 3 and 4 do not
require such guidance.
It is also unclear at this stage as to whether such encodings would
confuse existing PEM and X.500 implementations.
6. Domain-Based Certification Authorities
The encoding methods presented in section 3 provide a natural method
to establish certification authorities aligned with domain names.
This memo does not require this however, as other CA structures may
be judged more flexible in the future. But, if a local region of the
Internet decides to use a domain-based CA hierarchy, this memo
provides a convenient method which conforms to the name subordination
requirements of PEM.
Certification authorities are represented by DN's associated with a
domain name, and entities are represented by DN's associated with an
e-mail address. The mechanisms from section 3 are used for this
purpose.
It is recommended that the mechanism presented in section 4 be used
if other certification authorities with traditional DN's wish to
include the e-mail address of an entity in the DN.
Weatherley DRAFT - expires 9/7/94 [Page 5]
RFC DRAFT March 1994
References
[OSI-DS] P. Barker and S. Kille, "The COSINE and Internet X.500
Schema", RFC 1274, November 1991.
[PEM2] S. Kent, "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[PKCS6] RSA Laboratories. "PKCS #6: Extended-Certificate Syntax
Standard", Version 1.5, November 1993.
Security Considerations
The usual PEM security conditions relating to distinguished names
apply.
Acknowledgements
Many thanks are due to Steve Crocker, Bob Smart, and Bob Jueneman for
their valuable comments on an earlier version of this draft.
Author's Address
Rhys Weatherley
School of Computing Science
Gardens Point Campus
Queensland University of Technology
2 George Street
GPO Box 2434
Brisbane Queensland 4001
Australia
Email: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au
Phone: +61 7 864 1290
Weatherley DRAFT - expires 9/7/94 [Page 6]