Bob> the only place to put [a disclaimer] where it will be both obvious
and firmly bound to the user's signature is in the X.509 certificate
itself. I therefore recommend that the IETF or other appropriate
organization raise this as an urgent issue within the X.500 standards
committee, and try to get such a Disclaimer field added to X.509 at the
earliest opportunity.
Attribute types are defined in X.520 and there already are some
interesting ones that have not been here-to-fore discussed.
- -
Bob> On another issue, I previously raised the question of support for
the X.509-1993 UniqueID field but got no response. I would like to
encode the employee's ID number in the certificate, both to guarantee
uniqueness in case we have two John Jones working for us and for
administrative convenience. Unless someone has a better idea, I plan to
put that in an OU field as well.
Why not use the serial number {attributeType (5)}?
- -
Bob> My goal is to make it possible to validate a user's certificate
without having to have a human read it, so I am not thrilled about
having to encode a disclaimer inside an OU field where it obviously
doesn't belong. But at least if everyone who needs this protection were
to follow the convention of OU=DISCLAIMER: blah blah blah, it would be
possible to machine parse this certificate as an exception without
caring particularly what the disclaimer says. The user can then read
the disclaimer in more detail.
Consider Business Category {attributeType 15} or Member {attributeType
31} or even Description {attributeType 13}.
- -
Bob> There might not be any practical difference, but the use of an
explicit organizational role might tend to give greater weight to the
assumption that someone was in fact authorized to perform some
particular function than just a title. More importantly, if I
understand what you are saying, you can either have a organizational
role or you can be identified by your individual name, but not both,
since you can't have two common names.
Neither of these statements are true from the point of X.509, although
it might be the case that some countries will try to limit an RN to a
single common name. Also the common name is {attributeType 3} but the
Role Occupant is {attributeType 33}, so it could be used in either case;
even with a title {attributeType 12}.
- -
Bob> In this case, our internal practice will require the use of a smart
card for the signature function, and we will also require the use of
keys that are close to the maximum length (1024 bits, as I recall?).
Now there is something that should be specified in a attribute! I
understand that X9.30 will make some statements about the requirements
for cryptographic modules. They have also added two fields to the
Certificate that may be of more interest than changes to one's
Distinguished Name. You should consider the X9.30 certificate model if
more data is your aim. No one has told me if X9 or TC68 will approach
ISO on this certificate.
Peace ..Tom Jones