[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more comments on "shrinkwrap"
> From: Markku-Juhani Saarinen <firstname.lastname@example.org>
> 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
> <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?
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2