Re: [TLS] Verifying X.509 Certificate Chains out of order

[[e-mail] (Peter Gutmann)]

[Replying to two messages at once]

[e-mail] writes:

>> I'd say modify it, in fact I'm not sure what the rationale for requiring
>> ordering was in the original spec, "it's tidier that way" doesn't strike me as
>> a good argument :-).
>
>Consider TLS on low-end or embeddede devices with limited ressources. Walking
>through the chain becomes difficult or even impossible if there is no order.

Again, how can you create an implementation that can run the entire SSL
protocol but can't manage a few 32-bit pointers across three or four certs?
This seems like a total red herring, it's difficult to think of an
implementation that can perform the necessary cert verification but somehow
can't manage an extra pointer swap.

(Well, I'm sure I can come up with some pathological case where you can do one
and not the other, but I'd have to apply some pretty creative thinking :-).

>The situation that you describe as "unlikely" is the situation that is going
>to be the norm when SSL client certs start getting used in a serious fashion.

Oh, in that case there's nothing to worry about, if I can wait until PKI
starts working before I need to address it then I'm OK.

>You walk up to a restaurant for a dinner.  The guard at the door tells you
>that you need a membership card in order to enter and hands you a form to
>fill in and prove your membership    however he refuses to tell you which
>membership he will consider acceptable. Actually    he promises you that if
>you happen to pick one that is not acceptable, he will send you away with a
>painful kick in the butt.

What a marvellously nonsensical example.  If I go to http://www.amazon.com I
enter the password I use for Amazon.  If I need to provide a cert, I provide
the cert I use for Amazon.  End of story.  This procedure has worked just fine
for more than ten years now for SSH, which I'm sure has a much larger and more
diverse user base than client-side SSL certs ever will.

>Another serious problem of the "server sends nothing" approach is that it
>requires the client to blindly perform an expensive public key operation and
>this may incur the overhead/incovenience of prompting the user to insert a
>hardware token and/or enter a PIN to authorize a private key operation --
>which can be entirely avoided if the server announces what CAs it trusts and
>there is no match to the credentials available to the client.

Sure, I'll admit that one's a real issue in the special situation where this
specific case applies.  OTOH I'm happy to leave things as they are until
client certs take off before I look at it further, I've got way too much other
stuff to work on that's more pressing than this.

And that's the real killer for this I think: If you're going to go with these
niche variations that almost no-one uses, you sort of have to accept that
you're going to be in a world of pain.

Peter.
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls