Francisco,
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.
Your comment reminded me of a comment made previously by Steve Dusse
and Frank Sudia, as I recall, and that was that we should carefully separate
those attributes that may be optional for the sender, but if included MUST
be understood if the certificate is to be considered valid, vs. those that
may be descriptive but are merely supplemental.
I think that this principle may be more worthwhile in the case of an attribute
certificate, in particular to state a negative attribute (This user is NEVER
allowed to open the bank vault door).
But as long as we are going to think about generalizing X.509, we should
consider this too.
I am going to re-examine PKCS#6. But my understanding was that
the intent of that format was to include the types of authorization
attributes which I agree would be better placed in a separate certificate.
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.
I'm not thinking of two separate semantics, but (hopefully) a carefully
selected set of attributes that explain one complex semantic construct,
namely identity.
I'll grant that anything that can be expressed within a certificate
containing two attributes could also be expressed with two certificates.
There certainly is a trade off here, and I'm not sure where the boundaries
lie.
I certainly wouldn't put a megabyte MPEG movie of the subject in his
primary certificate. But I might very well want to put his e-mail name
in a certificate along with his civil DN, just as a convenience until we have
X.500 running. Don't forget, X.500 doesn't provide any archive facility,
so if you want to know some of the important characteristics about
someone when you pull a message out of the archives, you'd better have
stored all of the certificates away. It would certainly be more convenient
to have all of the attributes that _reasonably_ belong to gether in one
place, just to facilitate the retrieval.
A second, political issue is that it is dificult enought to gain concensus on
one certificate, much less trying to persuade developers to support two.
So these are judgment calls, about which reasonable men could certainly
differ.
While I'm on this subject, Richard Ankney made two observations:
1. X9.30 originally used the UID to distinguish between multiple certificates
for a user, but the UID is used by the 1993 X.500 ACL mechanism so it has to
identify a user, not his certs. We regretfully removed this idea from X9.30.
I'm not sure that I understand this, perhaps because I haven't looked
at strong authentication all that seriously yet. Since you are running a DSA
with strong authentication, could you comment?
If one user (DN) has multiple certificates for different purposes, how
are we supposed to tell the difference? One obvious way is to create
another entry under the user's common name node, but now I've lost
the sense of a single user??
2. The final version of X.509 (93) has the PEM CRL format, but still uses
the same (1988) OID. OOPS!!!
I think he is saying that this is a bug or defect. But I don't know that
it matters, unless someone is likely to read the '88 version and try to
code a CRL. Let's change OID in the '88 version retroactively! :-)
Bob