Jeff,
The biggest problem I have with this is that it requires one CA to
sign everything.
I'm sorry if I left that impression, for it was NOT my intent to have one
CA sign everything. I absolutely agree with almost everything in your message
regarding the need to have different entities to tell me different things. In
fact,
I have used the term "electronic wallet" to refer to a collection of
certificates that could be carried and used for different purposes,
ranging from simple identity confirmation (signing tax returns), to confirmation
of employment (electronic mail, access control, checking out pens at the
company store), to an electronic MasterCard or telephone company credit card.
I don't know and can't predict whether there will ultimately be multiple
X.509 certificates (with or without the extensions I proposed), or
whether individuals will have one X.509 identity certificate plus a number
of X9.30 certificates. I don't think it matters too much, although my
preference would be to minimize the number of different formats that have
to be supported.
My intent was really quite simple. Steve Crocker and a number of others
have commented on the fact that they would like to have the user's
Internet e-mail address available in some convenient form, and somehow tied
to the user's certificate for ease of use until X.500 becomes available.
In general I don't like the notion of REPLACING the existing DN structure
and the civil naming authority schema that it is based on, but I do agree
that it would be nice to be able to AUGMENT the DN with additional
attributes.
These attributes may be strictly informative or descriptive, and not necessary
from the standpoint of having a minimal length DN that is well-qualified and
globally unambiguous. They therefore shouldn't be placed in the DN, but it
IS desirable that they be capable of being captured in the certificate.
Individual users and/or CAs may not choose to use such attributes, but surely
there is nothing WRONG with capturing such information as the user's e-mail
address, department name and number, and employee ID number in the
user's certificate. Certainly if my CA is my employer it can certify such
information as factual.
Since the current X.500 schema at least suggests that the serial attribute
should be used for devices and not for people, we don't have a convenient
means of distinguishing between two individuals over time that have the
same names, except for the UID field included in the '93 version of X.509
(but not supported by PEM, at least so far.)
However, if the UID field is included in the DN to differentiate between
two different users who would otherwise have exactly the same DN, it will not
be NECESSARY to make such additional distinctions. But surely it would
be HELPFUL to a user who is trying to determine which user is which, and
therefore which certificate to select, when he has no way of knowing
which UID (a bit string) was assigned to which user. Such additional attributes
may be even more helpful when validating a message from the archives,
when there might be some confusion as to which user was which.
Finally, although I have no quarrel with the X9.30 certificate or any other
attribute certificate, I think that support for such certificates may take a
while to develop, especially outside of the banking and EFT environment
for which they were developed.
I would therefore like to have the ability to include at least a caveatEmptor
type of attribute in the certificate that says something like "This user is not
authorized to sign anything that binds or obligates XYZ Corp. to anything
at all, except as explicitly authorized in writing or by means of an signed
attribute certificate. In addition, the user denies any intent to use this
certificate for personal purposes, and any personal responsibility by the
user for any obligations alleged to have been signed using his digital
signature is hereby denied and repudiated."
Standing on my soapbox once more: I think a lot of people are
confused with the purpose of X.509. It merely binds a DN to a public
key and not a DN to an entity (unless the PCA so states in their
policy statement and which I may choose to disregard). This whole
technology is intended to be used in constructing a framework for
electronically propogating trust. It is not, of itself, intended to
actually confer that trust.
I really have to think about that. Since there is no _purpose_ per se
in the X.509 standard, your basis for saying that is unclear. Certainly
X.509 does frequently refer to users, and at least implicitly equates
the Distinguished Name of the entity with the entity itself. While I
strongly agree that mere identity confirmation is not sufficient as a
basis for TRUST, I don't think that you can successfully argue the
converse, i.e, that attribution of a message or document to the individual
named in the DN cannot ever imply any LIABILITY.
Lawyers and courts, not standards committees or implementors, decide what
implications can reasonably be drawn from a document, and the extent to
which any writing, electronic or otherwise, signed or unsigned, should be
admitted into evidence as representing someone's intent. My primary concern
is that we not make the risk of liability unbounded in the event of a key
compromise.
Bob