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

Re: SDSI syntax

Ron Rivest wrote:
> 
> SDSI's object are basically either octet-strings, or lists of octet
> strings.  The canonicalization procedure converts an arbitrary SDSI
> object into an octet string, using a fixed set of rules.  (Octet
> strings are represented as length:value, and lists are represented
> with parenthesization.)  So you need a hash algorithm that maps octet
> strings to hash values.  Most hash algorithms are already defined this
> way, so there is no definitional problem; the efficiency questions
> come up in the choice of hash algorithm, if the algorithm favors one
> end or another...

   There's another issue with the "canonical" encoding in SDSI - it's
not possible to perform signature generation or signature verification
in single pass through the SDSI object. This is because the verbatim
representation includes a length field at the beginning of the
octet-string.

   This may or may not be a problem, depending on how large SDSI objects
grow. I do bring it up, though, because apparently SDSI has 90% of the
functionality of an e-mail encryption protocol such as PGP/MIME or
S/MIME. If it's actually going to be used in such a role, then
efficiency starts to matter, especially when there are other, perfectly
good solutions out there.

   But I'm disappointed that the only thing we're talking about is the
syntax. The semantics of SDSI bring up very large questions, and I can't
say I'm fully satisfied with the design. Unlike PolicyMaker, SDSI does
_not_ subsume the Web of trust. In fact, unless I'm missing something,
it doesn't attempt to solve the key distribution problem at all. The
(ref: DNS!! edu berkeley cs raph) mechanism, in my opinion, is
unworkable - it depends on a big, rigid hierarchy. By comparison,
VeriSign certs are the epitome of flexibility.
Follow-Ups: References: