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

From: Dave Garrett <[email-masked]>
Date: Tue, 12 May 2015 17:31:56 -0400

I've added some general additional language to the PR to add more detail explaining the changes. If there's anything that needs to be changed in order to make this as clear as needed, please comment on the PR. (e.g. we might want to add more specifics)

https://github.com/tlswg/tls13-spec/pull/169/files

Dave

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 23:38:53 +0200 (CEST)

Dave Garrett wrote:
> I've added some general additional language to the PR to add more
> detail explaining the changes. If there's anything that needs to be
> changed in order to make this as clear as needed, please comment
> on the PR. (e.g. we might want to add more specifics)
> 

One of the worst problems in your proposed text is the replacment
of the term "self-signed [...] root certificate authority" with
two bogus occurrences of the term "trust anchor".

Trust anchor is a _strictly_ local concept, so this term
MUST NOT be used in the description of the TLS Certificate PDU.

self-signed root certificate authority is a simple technical term,
that does *NOT* imply trust by any party.

-Martin

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 12 May 2015 15:03:16 -0700

>  that does *NOT* imply trust by any party.

Martin,

You will find the reasoning already provided in past messages for why this
proposed terminology change. "self-signed root certificate authority" is,
unquestionably, NOT a simple technical term (considering how many times it
has confused people, I should think this obvious). Please do re-read the
message is which I provided the justification for this change, and
hopefully provide counter-factual evidence if there is any.

Considering that "trust anchor" is a term extensively used in RFC 5280, I
also fail to understand your objection about it being a "local only"
concept. This is entirely in line with the current language where you can
omit certificates that you know your peer does not need.

I'm happy to work to resolve the objections, but I can't help but feel
like some, like this, aren't well justified or supported.

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 May 2015 00:38:38 +0200 (CEST)

Ryan Sleevi wrote:
> has confused people, I should think this obvious).

Then add the line of text from rfc5280 or X.509 that explain what a
self-signed CA certificate is.

> Please do re-read the

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

> 
> Considering that "trust anchor" is a term extensively used in RFC 5280,

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 also fail to understand your objection about it being a "local only"

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.

-Martin

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 12 May 2015 15:51:28 -0700

>  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.

>    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.

>  for the TLS Certificate PDU is provably incorrect for at least one TLS

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?