[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: specification language?
Carl,
>I think you're right that a modified [enhanced] subset of X.509 could work.
>However, unaugmented X.509 is flawed, IMHO, even if the DN were cleaned
>up to be a sensible text string rather than some X.500 carry-over.
>
>In particular, as I argue in my cert.html, X.509 suffers from the Vogon HQ
>problem -- that its meaning is not specified in the certificate itself.
There is some truth to this assertion. Within the X.500 community, the
generally accepted way out of this box, especially as it applies to private
attributes and extensions, is to publish the syntax (and hopefully the
semantics) of the various attributes in X.500 itself.
Another alternative, whihc I have argued for, is to include both a pointer to
the CA's policy where such things are defined in precise detail, and also a
terse statement that is human readable.
>
>It also suffers from trying to tie a name to a key rather than a permission
>[or meaning] to a key. The latter requires no names at all.
I though we had already agreed that X.509 did not specifically require a "name"
per se, as prt of the DN. If you want to use the key itself as a DN, or say an
arbitrary customer nunmber, you are free to do so.
>
>Specifically, one special case of a key-centered certificate is the one
>whose meaning is, for example:
>
>"This certificate assigns all permissions carried by the CyberCash employee
>Carl Ellison to the Subject key." That is a traditional X.509 meaning --
>but it's a subset of key-centered certification. That cert has to be
>signed by a CyberCash key authorized to give out such permission
>assignments.
>
>Another kind of key-centered cert might carry the meaning "I answer to the
>name Carl Ellison" and be signed by my key -- ie., be self-signed. These
>two have very different meanings -- a difference X.509 is not capable of
>expressing.
Since X.509 explicitly allows new extensions to be created whenever there is
the need, I cannot imagine how you can argue that these two different meanings
cannot be encoded in X.509. Although more efficient ways of encoding those
differences could be constructed, in particular if there were some industry
agreement as to classes of certs, X.509 is perfectly capable of carrying
precisely the menaings you have described, if necessary by a series of terse
statements that says in English, Ftrench, Spanish, Japanese, and Urdu exactly
what you have said.
>
> - Carl
Bob