[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more comments on "shrinkwrap"
> From: Markku-Juhani Saarinen <mjos@ssh.fi>
> 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.
>
Any kind of certificate without a signature doesn't make any sense.
This is clearly a bug in the BNF.
> 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 !).
>
(sigh) The ShrinkWrap protocol assumes that every certificate is signed.
It relies on this for security. It expects verification. It says so in
the Security Considerations.
The signature on a so-called Certificate Reduction Certificate is not
"blind". It is self-signed by the verifier. It is the same signature
that the verifier will use to verify the certificate later.
> > 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
> chain.
>
> <sequence>:: "(" "sequence" <seq-ent>* ")" ;
> <seq-ent>:: <cert> | <pub-key> | <signature> | <op> ;
>
Another bug in the BNF. Note that a sequence can somehow form a list of
signatures and ops without any keys or certs. I'll propose a
replacement later today.
Please don't blame me for bugs in someone else's draft.
> > 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.
>
(shrug) They are irrelevant to the example. The reduction isn't based
on the assertion tags, last time I looked.
Are you just arguing for arguments sake?
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: