[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Binary vs. ASCII for certificates
Greg Rose <uunet!sydney.sterling.com!Greg_Rose> wrote:
> >(4) One must be careful to define what bytes are actually "present" in an
> > ASCII encoding, since the contents will be digitally signed. The
> > treatment of whitespace, etc., needs to be carefully specified.
>
> Yes -- this is very important.
>
> I disagree. PGP itself has a lesson for us here.
> Make the transport layer ASCII, and easily
> (lexically and syntactically) parsed, then
> transform it into a defined binary structure
> upon which the signature can be checked.
> Actually that structure can be ASCII too, but the point is
> to recognise it using some of the smarts we have
> left over from compiler theory and compile
> something which is rigorously defined.
How do you propose handling internationalization? Is spki targeted
mainly at the English speaking world? Allowing use of Unicode is
a plus that I think we ought to keep in mind.
I find it much easier processing messages when fields are either of
fixed length or are prefixed with a length field when appropriate. An
ASCII stream that has to be scanned is not my notion of a simple
encoding.
My own preference is the use of ASN.1 in a judicious manner such as is
done in HTTP-NG, where the resulting data structures are
straight-forward and the PER encodings are very similar to what I
think most folks would write if left to themselves. That is, values
that need a length are prefixed with a length (e.g., a varying length
string), and those that don't need a length do not have one (e.g., a
boolean value).
Bancroft Scott
Follow-Ups: