[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

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