(1) I confess my ignorance, Mr. Stefferud, as I am sure others will!
Until you informed us all in your last message, I was completely unaware
that that "PEM and friends [and I certainly count myself one of those]
appear to want to establish a new (different) global name registration
system in parallel with the existing national civil naming
infrastructures." Honestly, I naively thought that *someone else* (like
those North American Forum guys or NIST or somebody) was going eventually
going to get around to *registering* names, and that PEM would then *use*
those names by incorporating them in X.509 certificates.
However, it is not my fault! I was misled by the evil cabal of PEM RFC
authors, who concealed their nefarious and disruptive registration plan by
not mentioning it in the PEM RFCs. To see that I am blameless, you only
have to read the few parts of the RFCS that deal with naming. (To make
that reading easy, I have reproduced those parts below.) See there, they
never mentioned what they are planning!!
Now that you know that most of the PEM WG is innocent, surely you will
enlighten us by explaining (in small words, sans rhetoric) just what the
heck is going on and where PEM has gone wrong. After that, we will be
ready to receive your new Internet-Draft text of the RFC modifications that
we need to ratify to put ourselves back on the side of the angels.
(2) I am told that in some WGs of the IETF, it has gotten to the point
where they are forced to give the following kinds of instruction if they
want to get anything done: "If you have been working on implementing or
modifying the current draft text, sit in front. If you have read the
current draft text *before* the meeting and have constructive comments, sit
in the middle and take your turn. If you have not read the draft before
coming to this meeting or are just learning what it is all about, sit in
back and shut up."
Since I am near-sighted, I don't want to sit in back. So, although we
really don't deserve it after our Philistine behavior, please provide a
copy (or at least the reference and electronic source) of the document(s)
("SD-5") that you want us to read. The next IETF is fast upon us. We
innocents and plotters alike will read your documents; please read ours.
In RFC 1421, it is mentioned that:
----------------------------------
6. User Naming
Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one
which has received (and continues to receive) significant study.
. . .
The use of user identifiers unrelated to the hosts on which the
users' mailboxes reside offers generality and value. X.500
distinguished names, as employed in the certificates of the
recommended key management infrastructure defined in RFC 1422,
provide a basis for such user identification. As directory services
become more pervasive, they will offer originators a means to search
for desired recipients which is based on a broader set of attributes
than mailbox specifiers alone. Future work is anticipated in
integration with directory services, particularly the mechanisms and
naming schema of the Internet OSI directory pilot activity.
In RFC 1422, it is mentioned that:
----------------------------------
3.1 Scope and Restrictions
...
Specifically, the architecture proposes a system in which user (or
mailing list) certificates represent the leaves in a certification
hierarchy. This certification hierarchy is largely isomorphic to the
X.500 directory naming hierarchy, with two exceptions: the IPRA forms
the root of the tree (the root of the X.500 DIT is not instantiated
as a node), and a number of Policy Certification Authorities (PCAs)
form the "roots" of subtrees, each of which represents a different
certification policy.
...
3.2 Relation to X.509 Architecture
CCITT 1988 Recommendation X.509, "The Directory - Authentication
Framework", defines a framework for authentication of entities
involved in a distributed directory service. Strong authentication,
as defined in X.509, is accomplished with the use of public-key
cryptosystems. Unforgeable certificates are generated by
certification authorities; these authorities may be organized
hierarchically, though such organization is not required by X.509.
There is no implied mapping between a certification hierarchy and the
naming hierarchy imposed by directory system naming attributes.
This document interprets the X.509 certificate mechanism to serve the
needs of PEM in the Internet environment. The certification
hierarchy proposed in this document in support of privacy enhanced
mail is intentionally a subset of that allowed under X.509. This
certification hierarchy also embodies semantics which are not
explicitly addressed by X.509, but which are consistent with X.509
precepts. An overview of the rationale for these semantics is
provided in Section 1.
. . .
3.3.4 Subject Name
A certificate provides a representation of its subject's identity in
the form of a Distinguished Name (DN). The fundamental binding
ensured by the key management architecture is that between the public
component and the user's identity in this form. A distinguished name
is an X.500 directory system concept and if a user is already
registered in an X.500 directory, his distinguished name is defined
via that registration. Users who are not registered in a directory
should keep in mind likely directory naming structure (schema) when
selecting a distinguished name for inclusion in a certificate.
3.3.5 Issuer Name
A certificate provides a representation of its issuer's identity, in
the form of a Distinguished Name.
...
3.4.4.2 Residential CAs
. . .
Such users can be registered as residential
persons and the DN of such a user should be consistent with the
attributes of the corresponding X.521 object class. Over time we
anticipate that such users will be accommodated by civil government
entities who will assume electronic certification responsibility at
geographically designated points in the naming hierarchy. Until
civil authorities are prepared to issue certificates of this form,
residential user CAs will accommodate such users.
Because residential CAs may be operated under the auspices of
multiple PCAs, there is a potential for the same residential CA DN to
be assumed by several distinct entities. This represents the one
exception to the rule articulated throughout this document that no
two entities may have the same DN. This conflict is tolerated so as
to allow residential CAs to be established offering different
policies. Two requirements are levied upon residential CAs as a
result: (1) residential CAs must employ the residential DN conflict
detection database maintained by the IPRA, and (2) residential CAs
must coordinate to ensure that they do not assign duplicate
certificate serial numbers.
6. Naming Conventions- If the PCA imposes any conventions on DNs used
by the CAs it certifies, or by entities certified by these CAs, these
conventions must be specified. If any semantics are associated with
such conventions, these semantics must be specified.
. . .
[5] North American Directory Forum, "A Naming Scheme for c=US", RFC
1255, NADF, September 1991.
[9] North American Directory Forum, "NADF Standing Documents: A Brief
Overview", RFC 1417, NADF, February 1993.
In RFCs 1423 and 1424, there is no mention of "naming".
------------------------------------------------------