[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on "shrinkwrap"
> From: Markku-Juhani Saarinen <mjos@ssh.fi>
> Some ciphers use little endian ordering and hash function paddings
> typically specify lengths in bits.. as a crypto sort of a person, I'd be a
> little confused. It's only one sentence and might help the implementor a
> lot. I don't think every implementor has read RFC-1700, p. 3 :-)
>
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.
There is no need that every RFC be a tutorial. We are not writing
textbooks.
SPKI has an extensive tutorial, which made it large and unwieldy, and
allowed folks to miss important things like certificates with no
signature.
And the first ShrinkWrap draft was only 3 pages. We are up to 7. Too
much boilerplate bloat already.
> > How would a client "do it itself?"
>
> Well, anyone with the right certs can do the reduction. And the client has
> to have them as he gives them to the server.
>
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.
> By the way, why do you talk about "certificate chains" when the <sequence>
> construct (4.2.6) is especially meant for this kind of use ?
>
The <sequence> is a set of signatures (and other cruft) on a single
certificate.
> > I don't understand. What form would "syntactically valid but empty
> > certs" take?
>
> Suppose that I'm A and want to log to target machine B and I have a cert
> sequence originating from B that says that I can do that. When I'm trying
> to give this chain to B, E comes in and substitutes this sequence with
> an another that says X can log in. B reduces this and gives it back to me.
> Result: the service is denied from me.
>
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>?
> There's a recent draft called "Application Protocol Design Principles" by
> C. Newman of Innosoft (draft-newman-protocol-design-01.txt)
>
1) ShrinkWrap is an Application Protocol in the same fashion as DNS
and SNMP. That is, not.
2) Sure we've seen zombies from both Apple and Microsoft who think that
ARPA host file textual data is the canonical form for the DNS, have
shipped products that are not interoperable, and then demanded that
the rest of the world change because of market share. Pardon me for
my derisive laughter.
3) Not having read Cliff's draft, I cannot comment in detail. But the
use of incompletely defined ad hoc numerical error codes without a
deterministic finite state machine, and non-existant standards for
output messages and data formats (for both FTP and SMTP), was a
serious design error that we have not yet recovered from in 20
years. It has made life miserable for User Agent designers, lead to
10 long painful years of MIME efforts, and FTP is still undergoing
interminable revision.
4) The world is not a glass teletype. Appropriate tools are better.
Internet protocol implementors have appropriate tools, and when they
don't, they write some.
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: