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!
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.
--Charlie Kaufman
(kaufman(_at_)zk3(_dot_)dec(_dot_)com)