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

From: Dave Garrett <[email-masked]>
Date: Mon, 18 May 2015 19:00:09 -0400

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

Of note, see also:
https://www.ietf.org/mail-archive/web/tls/current/msg16238.html

The discussion on this list got quite long and at least one person changed their opinion on the topic. I'd like to figure out where we stand on this now.

The primary people advocating for this are myself and Ryan Sleevi.
The primary person advocating against this is Martin Rex.

Who else is in favor or against, at the moment?

Regardless of your opinion, is there anything else that needs to be added to the changeset?
(If you think this is problematic, what needs to be added to reduce that?)

Also, the topic of AIA cert fetching came up, with people both arguing for and against. Personally, I don't think cert chain verification should be triggering any network activity unless explicitly approved beforehand. Do we need to add a note of some kind with regard to this topic? Could we make OCSP stapling a requirement in some way to at least address that? In an ideal world, I'd prefer either the server sends 100% of what's needed to verify, or the handshake should fail. (this is beginning to get off-topic from the main issue, though)

Don't interpret this as a full vote or consensus call just yet. I'm just trying to assess what needs to be discussed to move forward on the topic in some way.

Dave

---

From: Geoffrey Keating <[email-masked]>
Date: 18 May 2015 16:48:55 -0700

> Who else is in favor or against, at the moment?

I am for it, as it documents existing practice.

> Also, the topic of AIA cert fetching came up, with people both
> arguing for and against.

I believe this is out of scope for TLS; it is not a transport layer
issue.  We should therefore not discuss it in the TLS RFC.  There's
already discussion of some security impacts of AIA in RFC 5280, but
not this particular issue; I think that would be a good place to
mention the issue.