Robert
You are right, attribute certificates are well-stated in ANSI X9. But
looking at your proposal for a new certificate format, it seems to me
that you have not taken into account PKCS, in particular PKCS#6. Its
"ExtendedCertificate" contains the same information you are proposing,
that is, a set of attributes. The difference is that PKCS#6 only
addresses the part related to subject attributes and explicitly separate
plain X.509 certificate and attributes.
On the other hand, I have serious concerns about the usefulness of an
issuerAttributes field, mostly if you refer to X.520 attribute types.
So we need the UID field, and we ought to add it
to the PEM RFCs. I might have preferred a field
with a more descriptive semantics than an
arbitrary bit string, but we can live with this. Maybe
people will hash their birth certificate information
to guarantee uniqueness, or use an employee ID number,
or the time of epoch when the certificate was
generated.
I agree, X.509 v2 (93) certificate should be used. Its usage will
shortly disturb existing implementations, and we will gain in
certification accuracy.
2. However, even if we have a UID to provide
unique certificate names, we have not solved the
problem of how the user who wishes to validate another
user's identity can distinguish between the two
entries. Clearly we don't expect users to memorize
other users employee IDs, much less some even more
arbitrary bit string.
I think that the unique identifier fields were thought to be used by
systems more than by humans. The main purpose of these fields is to
resolve ambiguities between instances of the same entity. How to achieve
it is another matter.
I have launched a proposal in which this problem is technically
resolved. Yes, It is also based on X.509 certificate v2.
By the way, I absolutely agree with Mark Wahl on his comments about
versionning certificate formats. Also, I can confirm you that there
exist X.500 DSA/DUAs that support strong authentication, in particular,
We participated in PASSWORD as pilot site and since then (August 1993)
we have opperative a DSA that support strong authentication.
Although I have discussed the possibility of saying
something like C=US,O=GTE,CN="Jueneman, Robert
<Jueneman(_at_)GTE(_dot_)COM>", I really believe that
burdening one attribute with two semantics would
be WRONG, WRONG, WRONG. So forget it,
and I'm sorry I even thought of it.
More, why to burden certificates with two semantics?
Why not differentiate them as ANSI's X9 Certificate and
AttributeCertificate, or PKCS's Certificate and ExtendedCertificate, or
even AuthenticatedAttributes.
Francisco Jordan