Peter Churchyard writes:
Summarising the system implementation requirements outlined by
Steve Kent:
Conformance to PEM requires, independently of PCA policy statement on
certification and naming procedures, that the PEM infrastructure and UA
implementations consider that:
1) attribute types to be used for PEM e-mail user identification are
to be listed by IANA, and counter examples found in certificates
by PEM UAs are reason for certificate invalidity
2) collections of attributes used for naming identified parties
must conform to a naming architecture suitable for
effective organization of a Directory Information Tree, as represented
by a nominated set of competent schema specifications, enforced
by all PEM UAs
An optional requirement states that:
3) There must be an algorithmic relation between the issuer and
subject names represented in user certificates and the Distinguished
Name of the X.500 Directory entry in which it may be stored. A
simple relation is equivalence.
If valid, these propositions might be added to 1422 RFC to
make their role in enforcing PEM certification semantics
crystal clear.
If I understand the thrust of these remarks correctly, I VERY STRONGLY
DISAGREE.
I don't think that we know well enough at this time to say exactly what
attributes will be required for the various purposes for which PEM may
ultimately be used. I would therefore insist that the IANA specify a
MINIMUM required set of attributes necessary to support a reasonable
amount of interoperability, but that no constraints be placed on an
implementation that chooses to support additional attributes. Instead, as
the RFCs say currently, a compliant PEM UA should be required to display
any attribute type that it does not understand as best it can, whether as
a printable string or in hex. In particular, PEM should not be limited to the
set of attributes specified in X.521, but should be guided more by the
NIST stable implementors agreements (at least for US use).
Point 2) is so judgemental in its nature that it conveys little useful
information. "Effective organization of a Directory Information Tree" --
effective using whose particular implementation? "as represented by a
nominated set of competent schema specifications" -- nominated by whom?
Competent in whose judgement? CCITT's? One or more PTTs? NIST?
Individual Private Directory Service Providers providing service to multiple
users, e.g., AT&T or GE Information Services, or perhaps GTE? Truely
Private Directory Servers Providers, such as IBM or the University of
Michigan?
Point 3) requires an "algorithmic relationship" between the DN contained
in the X.509 certificate and the DN of the X.500 entry. Does this include
subsets or supersets? In other words, can I include multiple X.509
certificates in the entry for a given "individual," perhaps to support multiple
algorithms, different uses, etc? Or must a lower level DN be created in the
directory that is equivalent to the DN of the certificate? Likewise, can I
create multiple entries under multiple directory DNs, each of which would
contain identical certificates? I should think so, in both cases.
Example:
Suppose that the DN that is used to search the directory is
C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Can I create multiple
X.509 certificates and file them under that directory DN, including one with
C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman,Description="For
Personal and Confidential Mail Only"?
Likewise, suppose that I have a certificate containing a DN of
C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Is there any reason
that I cannot file that certificate under several directory DNs, including
C=US,O=GTE,OU=GTE Labs,CN=Robert R. Jueneman,Title=Mgr., Secure Systems,
C=US,O=GTE,OU=GTE Labs,CN=Bob Jueneman, and
C=US,S=Massachusetts,L=Acton,Address=10 Stoneymeade Way,
CN=Robert Jueneman? (Note that these may or may not be aliases
of each other, for I may wish to associate different mailboxes, telephone
numbers, etc. with each one.)
Many of these issues are presently being explored by the NADF and
individual service providers, and presumably by other such organizations
in other countries. I therefore think it would be highly presumptious of the
IETF to try to prejudge or foreclose potentially useful attribute options
and/or directory structure conventions at this time.
Instead, we should allow a relatively rich set of attributes, taking into
account the fact that many, perhaps most, PEM users may not have access
to a commercial-quality X.500 directory server for some number of years.
That should not hinder the deployment of PEM or its use outside of an X.500
environment.
As users make up certificates which contain information which they think
is necessary or at least useful, they will find out from their correspondents
and/or their directory service provider whether those attributes are
understood or useful. The users will then be free to negotiate with
their directory service provider and/or PEM UA provider for the support they
feel they need, and that is how it should be.
Bob