[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on "shrinkwrap"
-----BEGIN PGP SIGNED MESSAGE-----
In message <Pine.NEB.3.95q.970827001228.244A-100000@pilari.ssh.fi>, Markku-Juha
ni Saarinen writes:
>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)
Because the server/verifier has to:
a) verify the sequence of certificates itself
b) issue the "collapsed" certificate
> 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 ?
Yes, that's right.
> This is guesswork; the draft should clearly specify the purpose and
> scope of the protocol.
Our first intention was to use this protocol in IPsec (the reason is
explained). However, you *could* (and it may be that in this function
it'll be used more often) use it to get reduced certs as a way of
loading the client's certificate cache.
>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 result certificate will be signed by the server/verifier. The
client can check the accompanying signature. If the server produced a
bad certificate, there's not much the client can do really. And of
course this holds for all ways of reducing a certificate chain in
SPKI.
> -> 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)
Will the signatures of the empty certificates verify ? No.
Remember, all this server does is 5-tuple reduction (the one you know
and love), but doesn't actually make use of the result.
> 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).
An error message means the chain was dropped, connection was closed,
no result will be given. The server will keep nothing from this
session.
It may make sense to differentiate between temporary lack of resources
and chain too big, simply because an intelligent client could ask some
other server to do a reduction of part of the chain in the latter case.
> I'd suggest using english ASCII error messages (ftp-style perhaps).
I really dislike that kind of error messages. This is not an
interactive protocol. On the other hand, i can see uses for them.
Thanks for your comments.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNAQrf70pBjh2h1kFAQHSagP+OttMt//HqtfXt6JAvFk3Ap+IKcGjT1RR
6dmAzvX1riRfFZkOxxO/8p/uHyyFXZD2b6r8/bCsvHitdxJx1Wh8nJazHwa1NA96
6qnK40kK7dHh7I0ahlqIPJlJnjHHVJDSMefD4AJQ8SAL1EcCkeFsBuHouJqYLXks
Ex5a37vjwXY=
=H7b7
-----END PGP SIGNATURE-----
References: