[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
chain.
<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: