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

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

On Tue, May 12, 2015 3:38 pm, Martin Rex wrote:
>  Then add the line of text from rfc5280 or X.509 that explain what a
>  self-signed CA certificate is.

A self-signed CA certificate is not the same as a self-signed root CA
certificate, for example, nor are they to be confused with a self-issued
root CA certificate, which may not necessarily be self-signed.

>  I is *IMPOSSIBLE* to justify the use of "trust anchor" here.

I'll take that as you declining to read or respond then.

>  rfc5280 explicitly describes "trust anchor" to have only a *local*
>  meaning!
>  see rfc5280, section 6.2 (which I previously quoted).
>    https://tools.ietf.org/html/rfc5280#section-6.2

I don't think the text supports your claim, but it's clear that no matter
how compelling the argument, there's no room for you to budge on this. It
is unfortunate, but at least consistent.

>  The Certificate handshake message PDU is produced by one TLS peer (sender)
>  and consumed/interpreted by the *OTHER* TLS peer.  But the concept of
>  a trust anchor is a thoroughly local issue, so the use of the terminology
>  for the TLS Certificate PDU is provably incorrect for at least one TLS
>  peer.

No, it's not, but again, I don't think there's any room left for progress
on the matter, since it seems less and less likely to get a technical
discussion of the facts.

If the TLS peer knows, through whatever means (RFC 6066, out of band prior
agreement, incantations of the illuminati passed from generation to
generation), the trust anchor of the peer, it may omit any certificates
that follow that trust anchor.

How is that a difficult or wrong concept?
In the case of DANE, the peer needs all certificates, including the
self-signed, self-issued CA certificate expressed in the DANE record.
In the case of clients, if the server has perfect knowledge, then it can
omit the unnecessary certificates.

We've already established extensively why the myriad trust stores and
clients make such apriori knowledge on the Internet at large difficult to
impossible, and I think it's foolish to claim that
1) We replace the entire PKI with some future system
2) We replace the entire client TLS space with some future system that
ignores RFC 4158 (which will not happen)
3) We replace the entire server TLS space with some future system that
strictly enforces the TLS requirements (which will not happen; the ample
evidence of SSL3, RC4, Renego, etc provide ample proof of this)

So we deal with the system we have, the constraints we have, the clients
we have, the PKI we have, and we seek rough consensus and running code.
The vast majority of running code disagrees with you, and, by proxy, the
spec. Can we at least agree to that much?