Hoyt,
I don't know whether you have been following all of the discussion
on pem-dev, but as the Chair of X.509 and rapporteur for X.500,
perhaps you can answer some questions "ex cathedra".
Without necessarily putting words in anyone's mouth, I think
that a concensus is beginning to develop as to the need to deal with
multiple certificates per individual in a more structured manner than
is possible to date.
For example, there is a "requirement" or at least a strong desire by
some to allow encrypted e-mail to be sent to a Manager and/or
members of his/her staff, including the secretary/administrative
assistant. But no one but the manager should be able to sign on behalf
of the department or forge the manager's signature.
Likewise, the certificate that is used for official signatures may
not be appropriate for key exchange for routine business
correspondence, just because no one would be able to read it
in the manager's absence.
Some, perhaps most, certificates could be used for both purposes,
of course.
(Although it could certainly be argued that a trusted key management
system could deal with some of these issues, I would prefer to
have a more or less purely cryptographic solution to these problems. And
I would far rather deal with the issue of having multiple certificates for
read, write, or both purposes than I would deal with the very nasty
issue of key escrow within a company, for I think that emotionally
charged issue might just kill PEM and other similar technologies.)
In addition to these uses, there is a need to differentiate between
RSA key exchange and signature schemes, DSS + Diffie-Hellman,
PMSP-Mosaic, classified algorithms, and whatever algorithms other
countries come up with. Of course, interoperability will tend to require
that UAs will have to support multiple algorithms.
Finally, there is the issue of correctly identifying the various roles
and/or agent relationships that an individual may have, some of which
is already involved in the read/write/both issue. Assuming for the
moment that most companies will want to have a specific individual
identitied as a Purchasing Agent, rather than the faceless identification
of an entity as a Purchasing Agent with no name associated that Steve
Kent has argued for, I believe that an individual will at least have to be
identified as having that such a role, if only to indicate that a different
certificate is required.
For example, for my routine business correspondence I might be
satisfied with a 512 bit key, but for highly proprietary documents
and/or documents which I sign as manager, I might want to use 600 to
700 bits. And if I were the Chief Financial Officer of the company,
I might want to use a smart card implementation with close to 1000 bits.
In a pure PEM environment (no X.500 support), the imposition of
a Distinguished Name structure on the individual's name within
the X.509 certificate doesn't make an awful lot of sense.
We could have gotten by very nicely just using a letterhead type
of name and address structure, and it wouldn't have raised all
sorts of nasty issues as to how to map from the DN to an e-mail address,
for example. But we chose to be compatible with X.509 in the
expectation that X.500 would become a reality, so now we are
stuck with it and I don't believe anyone would seriously propose
abandoning it.
Now my question is, assuming that I have an X.500 directory system up
and running, how should I file all of these certificates so that my
correspondents can access them, and more importantly, choose
between them?
More particularly, exactly what are the semantics of the DN in an X.509
certificate? Is the DN that of the individual, who may have multiple
roles? Or is it intended to designate an individual who is exercising
a particular role at a given moment?
OR DOES THE CERTIFICATE CONTAIN THE DN OF THE CERTIFICATE
ITSELF, perhaps including a "certificatePurpose" attribute and probably
a "algorithmType(s)" attribute as RDNs?
I was originally assuming that the directory entry would contain
the individual's name, plus whatever qualifications such as employee
serial number are necessary to make the name globally unique. Then all
of the other information would be entered as attribute values associated
with that individual. But now I am not so sure. How would someone
determine that a given certificate was to be used for a given purpose,
unless various fields such as Title, roleName, agentName (two new ones
proposed by Rich Ankney and myself), and maybe even Description are
associated with each certificate?
Even more to the point, until X.500 becomes ubiquitous, what sort of
information should be contained in the X.509 certificate itself,
instead of half-hidden in algorithm names, etc.?
(Although I agree with Ankney and X9F1 that you don't need to
encode a "certificatePurpose" field in the certificate, I think that
burying such useful semantics in an algorithm ID field is an absolutely
terrible idea from the standpoint of having a transparent architecture.
I therefore strongly suggest that those fields be added explicitly
to the 1993 version.)
I'm sure that a phone call could have cleared up some of these issues,
but I think they are important enough for all of the pem-dev community
to have a chance to participate. I'll be out for a couple of days,
and will look forward to reading the discussion when I return.
Bob Jueneman