Charlie,
It would seem that the extended certificate format in PKCS #6 and PKCS #9
would support everything you want to do in terms of adding additional
attributes to certificates. I would strongly encourage you to consider using
it rather than inventing something new. You're always in a stronger position
supporting someone else's proposal than coming up with your own because you
can't be accused of NIH. I believe PKCS #6 has the additional advantage of
and installed base, though I haven't been following it carefully; I'm sure
someone on this list knows.
PKCS #6 is not without its problems. While it is arbitrarily extensible, its
funky encoding almost guarantees it will not be accepted by the X.509
committee. On the other hand, they chose that encoding to get a greater degree
of compatibility with X.509 than could be achieved any other way. It would be
trivial to modify a PEM implementation to accept either X.509 or PKCS #6
certificates. The X.509 committee (not their real name) has seen such
extensions to X.509 proposed before and they have been consistently
rejected on philosophical grounds - there's no reason to believe that
you'll have better luck this time. You may not even be able to sell it
in this community!
I'm game for anything that works, and don't have any particular pride of
authorship in this area. But I think you are correct -- there has been a
reluctance on the part of the PEM community to consider any change at all,
and I predict that the same reaction will occur within the X.509 group.
but I might be wrong -- Hoyt Kesterson seems pretty reasonable and was
talking to me about how to make the certificate extensible. I would prefer
to stay as close as possible to X.509, to avoid breaking too many other
products. I just don't feel that we can wait until 1996 to see something happen,
or worse yet wait for three years and then be told that the idea is
philosophically wrong!
If you decide to go your own way, there is a problem with PKCS #6 (and also
with your proposal) that you should probably fix. Additional attributes in
the certificate should be in two groups: Class 1 are attributes that if you
don't know what they mean, you should ignore them (e.g. internet mail
address), while Class 2 are attributes that if you don't know what they
mean, you should reject the certificate (e.g. Disclaimers). That would
enable you to add new attributes without changing the standard *and*
without giving up interoperability with existing implementations.
I think that this is an excellent idea. I had thought about something similar,
but was somewhat afraid that it would seem to complex. But this would
certainly help deal with the situation that would exist even if the ASN.1
syntax of an attribute were known but the semantics weren't.
Thanks for your comments.
Bob