Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

["Ryan Sleevi" <[e-mail]>]

On Tue, May 12, 2015 11:54 am, Martin Rex wrote:
>  X.509 would require an omniscient trusted directory to perform certificate
>  path discovery, and the Certificate Path Validation algorithm in
>  rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
>  approach for certificate path discovery, because this approach would
>  be clearly insecure and irresponsible.

Again, Martin, you're making unsubstantiated and inaccurate claims.

To the extent it's relevant to the discussion for the TLS WG, I will
simply note that RFC 5280 does not say anything about path discovery
precisely because discovery is out of scope for validation. Validation is
consistent, while discovery depends on a myriad of cases and protocols
outside of the narrow view of TLS. e.g. the validation of certificates in
PKCS#7 or in S/MIME.

So yes, RFC 5280 doesn't discuss how to do path discovery, because it's
out of scope, even though it repeatedly describes extensions and options
for how to do path discovery *that rely on parsing the untrusted
certificate*

RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges
it exists precisely to make discovery possible.

However, to the points at hand, at least it establishes why you object to
the change. You view it as predicated upon a fundamentally insecure
algorithm. While I (and many others, as evidenced by implementation and
discussion) would disagree with you, and I personally feel your claims of
standards imprimatur to be lacking, it at least provides a clear rationale
for your disagreement.

I don't think it'd be helpful for consensus building for me to try and
demonstrate where I think even RFC 5280 would disagree with your
conclusions, but if others feel themselves swayed by Martin's arguments, I
would be happy to add that fuel to the discussion.