[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed certificate format

Carl's comments on certificates and ASN.1, distilled from several messages

Carl describes what ought to be in a keyid - a mandatory key hash,
and optional fields like name and how to find the key, and suggests a format:
> Certifying-key: "Carl Ellison",   61E2DE7FCB9D7984E9C8048BA63221A2,
>      http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x7362BE39
Obviously, if the key hash is mandatory, and the other fields are optional
and may contain random spaces and punctuation, it would make sense to
put the key hash first for programs to find, leaving the fuzzy stuff
for humans and grep.


>Most specifically, the need to encode what I call a Meaning as a
>set of OID/value pairs, instead of tag,value in natural language,
>is one sign of this taint.  I have had to make OIDs in a past life
> and was lucky enough to work for TIS which already had a corporate
> branch of the OID tree, so I could define one with little effort.  [....]
>
>The big issue is that an OID has usefulness only if the receiver understands
>it.  So, somehow I have to communicate the real meaning to that receiver
>-- either out of band or through some global database of OIDs.  A global
>database of OIDs might be interesting, but this strikes me as something
>quite baroque compared to the straight-forward use of natural language
>tags and values, as I have proposed.  The natural language tag,value can
>be chosen to communicate the meaning without requiring any out-of-band
>communication.

OIDs are also useful if the receiver _doesn't_ understand them,
because it _knows_ it doesn't understand them.  Human-readable strings
in a Meaning: field handed to programs for parsing can do arbitrarily bad
things if the program's author expected that "foo" meant "foo" to everybody.
Some mechanism for uniqueness is valuable, and OIDs will do as well as anything.
As an alternative, a 64-bit "random" number ought to be unique enough.
I suppose people can do this anyway, since "arbitary text" supports it,
but a common format would allow common parsing.  Having some standard OIDs
chosen upfront that people can share would be nice, but it's less critical.

Also, supporting multiple "Meaning:" lines would be nice.

>For example, there is no simple int32 in ASN.1.  To achieve that, you have
>to start with an INTEGER and then add a bell/whistle which limits its
>range -- but you can't just limit its number of bits -- you specify its
>min and max value, and then have to decide what an internal 0 really means.
>So, people rarely limit their INTEGERs -- and the resulting code has to
>stumble over structures which can accomodate 400,000 bit integers, even when
>the application will ralph on any integer over 12 bits. 

If we're not going to limit applications to int16 and uint32,
I'd like to be able to use arbitrary long numbers in any application 
involving crypto, where "arbitrary" means "at least up to 4096 bits";
I don't particularly see a need for more than 32K-bit numbers, but who knows.

On the other hand, I think you were the one commenting on 16 bits being
big enough for character string lengths - it doesn't cost that much to
use 32-bit integers for lengths, which lets you use 4GB-long strings.
Bill Gates said that 640KB ought to be enough, and the 64KB curse is still here.
Also, using 32-bit length indicators lets you preserve word alignment
in strings on real machines.

#--
#                               Thanks;  Bill
# Bill Stewart, stewarts@ix.netcom.com / billstewart@attmail.com +1-415-442-2215
# http://www.idiom.com/~wcs     Pager +1-408-787-1281