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

Re: comments on "shrinkwrap"

We seem to disagree on some things.

> Which reference could you not find without a detailed reference section?
> [SPKI]?  UDP [RFC-768]?

[IPS], actually. (IPS means Internet Protocol Suite. IPSec is the
generally accepted acronym)

> Pardon?  What byte orders are possible?  This is a network protocol, a
> product of the IETF, and of course, network protocol byte order is used.
> See RFC-1700 page 3.

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  :-)

> 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. 
 
> Are you sure that you read [SPKI] 3.3.1 pages 16-17?

Indeed I have (I suppose I'm the only person who has actually tried to
implement it).

> Is there some confusion about a certificate in the context of SPKI?
> Aren't all certificates signed?

Well, [SPKI] doesn't say so. Actually some forms of certs (like ACL's) are
always unsigned. 

> Is the definition of "verifier" unclear in the context of SPKI?  "single
> certificate"?  "subsequent use"?

You're right. I missed that. 

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 ?

> > o How can the client be sure that the result cert is actually the
> >   true reduced cert ? Reduction can be done in a number of ways
> >   that are effectively the same but look different.
> >
> >   -> The attacker (possibly MIN) can insert syntactically valid but
> >      empty certs in the client -> server stream. The server will reduce
> >      these and produce an empty result cert, sign it, and send it back to
> >      the client. The client can't see that the cert is actually useless
> >      and won't get service. (and can't know why -- because the error
> >      messages are are not very informative)
> >
> 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.

> How would the verifier mistake these for valid certificates?

They are valid .. but for a different purpose.

> >    I'd suggest using english ASCII error messages (ftp-style perhaps).
> How will that help?

Would help debugging. ftp error messages consist of a three-digit 
error code followed by an english string.

> Indeed, the IETF is moving away from using english ASCII messages.  Hard
> to Internationalize.

Well, that's news to me. I'd really like explanatory english ASCII
messages even though I'm a Finnish person :)

There's a recent draft called "Application Protocol Design Principles" by
C. Newman of Innosoft (draft-newman-protocol-design-01.txt)

On p. 4:

  "6.   Text Not Numbers 
  
    Whenever possible, text should be used instead of numbers.  Numbers
    almost always have to be looked up in order for humans to interpret
    them.  Text can be read and debugged by a mere mortal."

  Mr. Newman continues to list some more reasons and presents some case
  studies to support his argument. I quite agree with him.

- mj
Follow-Ups: References: