[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on "shrinkwrap"
Some comments on the the proposed SPKI ShrinkWrap protocol (version 00).
o the references are missing
o description of the used conventions, such as the byte order, is
o it looks like this protocol is for "reduction servers", systems
that will do chain reduction for the client. Why can't the client
do it itself ? Or is the server supposed to sign the result cert ?
(the draft doesn't say anything about signing)
I guess that I could use this protocol to ask the target machine
to reduce a cert chain for me. If I want to do business with the target
machine again, I could give this reduced cert (sort of a "token") and
this would speed things up. Is this correct ?
This is guesswork; the draft should clearly specify the purpose and
scope of the protocol.
o How can the client be sure that the result cert is actually the
true reduced cert ? Reduction can be done in a number of ways
that are effectively the same but look different.
-> The attacker (possibly MIN) can insert syntactically valid but
empty certs in the client -> server stream. The server will reduce
these and produce an empty result cert, sign it, and send it back to
the client. The client can't see that the cert is actually useless
and won't get service. (and can't know why -- because the error
messages are are not very informative)
o p.5 :
" This error message is sent by the verifier when too many certificates
are included in a single transaction, a certificate is too large, too
many other reduction sessions are in progress, or some other resource
is unavailable. "
Sounds useless. If the client gets this message, it can't know
whether it should send the the same certificates again or not.
(i.e. the message doesn't say if the server is temporarily out of
resources or is the certificate chain just too big).
I'd suggest using english ASCII error messages (ftp-style perhaps).
Markku-Juhani O. Saarinen <email@example.com>, SSH Communications Security Ltd