[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[firstname.lastname@example.org: Re: [email@example.com: Re: SDSI syntax] ]
Phill Hallam-Baker suggests that one should sign a "canonical" form
of an object. I fully agree. Which form it is doesn't matter too much.
The SDSI paper proposes representing all octet-strings in verbatim form,
and then hashing that. I think it is best if the quantity to be hashed
is easily derivable from the INTERNAL representation; then the EXTERNAL
(ASCII) representation can be redefined to suit one's taste or needs.
To: firstname.lastname@example.org (Ron Rivest), email@example.com
Subject: Re: [firstname.lastname@example.org: Re: SDSI syntax]
In-Reply-To: Your message of "Tue, 30 Apr 96 09:28:07 EDT."
Date: Tue, 30 Apr 96 14:14:14 -0400
>SDSI allows one to express octet strings in several forms:
> tokens: abc
> quoted-string: "abc"
> hexadecimal: #616263 (starts with sharp sign)
> base-64: =YWRj (starts with equals sign)
> verbatim: #03:abc (that is, length:value)
> decimal: 6382179
>These are all equivalent. Parsing is trivial.
This raises a question, do we want to sign a cannonical form or not? S
expressions should make conversion to a canonical form pretty cheap. Provided of
course the canonical form isn't something derranged like DER which require
multiple passes over the data.
If we can come up with a mechanism for converting to a canonical form in a
linear manner (i.e. the transformation can be performed by and FSR) I think it
would be a worthwhile thing to do. The finer points of Ron's syntax would then
be conveniences and there would be less need to argue over them.
I would suggest for a canonical form removing all syntactically unnecessary
whitespace and expressing all octet strings as tokens or in hexadecimal. (modulo
some wording to clean this up).