RE: Three short fixes

"Kemp, David P." <DPKemp <at> missi.ncsc.mil> writes:

>More to the point, the intent is to create an attribute that says:
>
>  "This certificate is merely a convenient universally-accepted
>   blob for communicating a public key and a name/email address/URL"
>*AND*
>  "There is no claim that the public key and the name/email/URL
>   have any relationship whatsoever"

Sure, the latter was implied in the former.

>In other words, the name/email/URL could belong to Bank of America but the
>key pair and certificate request could have been created by Phish-R-Us, and
>no claims to the contrary are made by the issuer. 

More or less.  As I said, there are people using certs simply as a universal
container for a public key because there's nothing else available.  They don't
care about any cert semantics, they just need a means of getting a key from A
to B in a format that B can process.  Providing some means of indicating this
in the cert would be useful.

I'm not really too fussed about it, I'll let users keep using Xyzzy certs,
however if there's no centralised record of this you end up with a pile of ad
hoc approaches instead, including the current one of taking otherwise normal-
looking certs and ignoring all the cert semantics.  The choice is really:

  1) Use null-semantics certs that look like normal certs.

  2) Use null-semantics certs but at least mark them as such.

Of these two, (2) seems to be the better approach.

Peter.