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

more comments on "shrinkwrap"

W. A. Simpson wrote:

> I do not understand how the prover (client) generates a reduced
> certificate when the prover does not have the private-key or secret-key
> for the verifier.
> I do not believe that "anyone" can do a reduction.

Reduction can be performed by anyone as it is an algorithmic procedure
that relies only on the given data (namely certificates). You're right,
a "Self" certificate without a signature doesn't make a lot of sense.

But the ShinkWrap protocol doesn't say that the server should sign the
certificates. I thought that this was intentional as a "blind signature"
service like this is potentially very dangerous; multiple signatures
have a special meaning in SPKI (see 7.5 !). 

( here Simpson claims that it is unneccessary to specify the used byte
  order in the ShrinkWrap protocol because: )
> Every Internet protocol implementor has a copy of RFC-1700 at hand (or
> on disk), and keeps abreast of the changes posted to the IANA web site.
> Nobody else matters.

As RFC 1700 doesn't mandate the use of big endian notation;
"The convention in the documentation of Internet Protocols is to
 express numbers in decimal and to picture data in "big-endian" order.",
I think it should be explicitly stated by each draft. And most seem
to do so.

> The <sequence> is a set of signatures (and other cruft) on a single
> certificate.

Nope. It may contain any number of certificates, preferably forming a

   <sequence>:: "(" "sequence" <seq-ent>* ")" ;
   <seq-ent>:: <cert> | <pub-key> | <signature> | <op> ;
> The prover sends a certificate chain with [I1=B, S1=C, ...] and [I2=C,
> S2=A, ...] and gets back a certificate with [B,X,...].  Why is the
> prover not going to notice that X != A, which is the prover's
> <principal>?

You're missing the auth fields.

- mj 

Markku-Juhani O. Saarinen <mjos@ssh.fi>, SSH Communications Security Ltd

Follow-Ups: References: