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

[Martin Rex <Martin.Rex at sap.com>]

Stefan Santesson wrote:
> 
> Just agreeing on the principle that implementers should be forced to
> send the certificates in order but it definitely must be allowed
> to accept out of order chains.

I have absolutely no problem with implementations that accept an
unordered list.  However, implementations that accept an unordered
list should make sure they find a RELIABLE means to check that
they're always *SENDING* ordered lists, because a simple interop
check with their own client&server code or with other "unordered
accepting" implementations is NOT going to report bugs in
their *sending* implementation.

"Be liberal in what you accept" can be very dangerous with
careless implementors, because it will often make it more difficult
to verify whether your implementation is really conservative
with what it sends.  This may ruin the usefulness of
an originally sensible standard/spec.


>
> As long as I can use, some or all, of the provided certificates
> to construct a valid path, and I'm willing to undertake the effort
> to do so, then it would be quite senseless to force me to reject that path.

I wouldn't be surprised if some implementations of PKI would follow AIA
while building a chain from an incomplete unordered set.
*I* certainly would not want *my* servers to do that.

> 
> Also, In the practical world of cross-certification and bridge CAs,
> it is quite possible that I in any case as relying party only will
> use a subset of the provided certificates.

That's a whole different can of worms.

It should be possible to chop off the overly complexx cross-cert and
bridge-CA nonsense and treat some intermediate CAs as trust anchors
instead.  This is more likely to work and makes failures much
easier to understand.  :)


-Martin
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls