Subject: Re: [TLS] Proposed Change to Certificate message (#654)

From: Sean Turner <[email-masked]>
Date: Wed, 5 Oct 2016 15:06:25 -0400

I’m not seeing objections to this PR so please let us know by Friday (7 October) whether you see any issues with what’s been proposed. 

spt

> On Sep 22, 2016, at 20:42, Nick Sullivan <[email-masked]> wrote:
> 
> PR: https://github.com/tlswg/tls13-spec/pull/654
> 
> Hello,
> 
> I'd like to propose a small to the Certificate message format to allow for future extensibility of the protocol.
> 
> This change adds a set of extensions to the Certificate message. With this change, the Certificate message can now hold all extension messages that are certificate-specific (rather than connection-specific). This change also resolves the anomaly of OCSP messages appearing before certificates in the handshake.
> 
> Reasoning: 
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not per-connection metadata. By putting these responses in the EncryptedExtensions, you limit these extensions to being shown once per connection. This restricts future protocol extensions from using multiple Certificate messages to support multiple certificates on the same connection. An example of this is the post-handshake authentication proposal (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00), which currently requires a modified post-handshake Certificate message. This proposed change would simplify the post-handshake auth proposal significantly and generally make more sense as more certificate-specific extensions are created.
> 
> Nick
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 5 Oct 2016 22:40:28 +0300

On Wed, Oct 05, 2016 at 03:06:25PM -0400, Sean Turner wrote:
> I’m not seeing objections to this PR so please let us know by Friday
>  (7 October) whether you see any issues with what’s been proposed. 
> 

The only issue that comes to mind is where extensions that are specific
to the certificate chain instead to the certificate go.

E.g. if a new kind of certificate chain[1] is ever implemented using
client_certificate_type/server_certificate_type (or anything similar
for that matter).

[1] E.g. for allowing multisigning EE certificates (currently one can
multisign CA certificates, but not EE ones).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Oct 2016 13:59:33 +1100

> to the certificate chain instead to the certificate go.

Let's keep it simple.  I would put these on the EE cert.  That is the
entry that has the most chance of being looked at.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 6 Oct 2016 09:42:20 +0300

> entry that has the most chance of being looked at.

Yeah, if there is no separate slot, then EE cert slot is the most
logical.

Perhaps also put server_certificate_type/client_certificate_type
there? That would eliminate the anomaly that one must know the
server certificate type before sending the certiifcate.

However, with client_certificate_type, one has to be careful, since
server support also matters. So presumably one would have server
send a list of supported formats.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Oct 2016 20:25:37 +1100

> server certificate type before sending the certiifcate.

Sounds like a perfect use for the CertificateRequest extension field,
for the client certificate anyway.

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 07 Oct 2016 00:55:28 +0000

This seems resolved.

I'll update the text to reflect that per-chain extensions should be
included as extensions of the end-entity certificate. For RFC 7250
client/server_certificate_type values (such as X.509) that apply to the
entire chain should be extensions of the EE cert.

The client_certificate_type extension sent from the server in RFC 7250 can
go in either the encrypted extensions or the proposed CertificateRequest
extension field, but that has no bearing on this proposal.