Hi Bob,
Let me add my 2 cents...
You asked (with good grammar and spelling but not-so-hot line wrapping):
Now the questions are:
3. (Steve Kent, the NADF, the gods of X.500 political correctness, et al.)
Given the unavailability to date of an explicit Disclaimer or similar field
to be used for the purpose of defining the limits of liability a user is
willing
to agree to, would the use of the Description attribute for the purpose of
describing such a Disclaimer be considered egregiously poor form?
I believe that this sort of disclaimer should not be carried with the
x.509 certificates but rather via some other mechanism, perhaps the
signed messages themselves.
I think that a disclaimer is similar in many ways to authorization
information (or dis-authorization). Authorization information
deserves a separate mechanism which should not get mixed up with the
key - name binding mechanism (see ANSI X9F work).
I think it especially egregious to consider carrying a disclaimer with
the actual name information. The NADF folks strongly recommend using
the "civil naming authorities" to "discover" our distinguished names.
(My parents named me Steve, not SteveCounterSignatureRequired).
I fully understand and appreciate the issue that you are addressing.
It seems that you are trying to properly set the expectation level of
the receipient of my signed message as to the limits of my signature,
whether I know that receipient or not. Maybe this could be solved in
a slightly different way. Perhaps... (flame shields up) it would be
just as effective if the key holders had a way of conveying their
private-key protection mechanisms in their certificates. Perhaps this
could be considered an attribute of the public key in the certificate
rather than an attribute of the name...
4. (Steve Dussi, Steve Crocker, Jeff Schiller, and other PEM implementors)
Would the use of multiple Common Names and/or the Description attribute
break your PEM implementations? I.e., if you received such a certificate,
could you display it and validate it properly?
5. (Steve Dussi and the rest of the TIPEM implementors) Assuming that the
aplication program which invokes TIPEM can handle it, will TIPEM handle
such constructs correctly?
TIPEM is really flexible. It will accept and construct names with any
number, combination and frequency of attribute types. In fact, if you
don't like the attributes types that came with TIPEM, you can make
some up of your own. (This was especially useful to one customer who
didn't like that the '88 X.500 attribute types only allowed
PrintableString or T.61 encodings. They felt that their Asian
customers were a little underrepresented and that UNICODE just wasn't
there yet so they proposed and used alternative attribute types to
convey non Roman-centric characters).
6. (George Parsons and/or Steve Kent, etc.) Will the RSA/BBN Certificate
Issuing
System allow such constructs in a user's Distinguished Name when endorsing
the user's certificate?
As Steve Kent pointed out, the SafeKeyper is generally liberal about
attributes. Our Macintosh-based CIS application displays the
Attribute types that it knows about and warns about the existence of
others.
Hope this is useful.
Cheers,
Steve (I have no authority, why would anyone want to impersonate me)
Dusse
My phone, office, desk, and computer are the property of the company
but the opinions are mine.