Re: [TLS] Updating for non-X.509 certificate types

Ilari Liusvaara <> Fri, 10 March 2017 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B64F12995F for <>; Fri, 10 Mar 2017 04:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1z5rc9DBY2pD for <>; Fri, 10 Mar 2017 04:40:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D105012995D for <>; Fri, 10 Mar 2017 04:40:23 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DA791DC94; Fri, 10 Mar 2017 14:40:21 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id rMjyFDWQQFWm; Fri, 10 Mar 2017 14:40:19 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 490452310; Fri, 10 Mar 2017 14:40:19 +0200 (EET)
Date: Fri, 10 Mar 2017 14:40:13 +0200
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Updating for non-X.509 certificate types
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Mar 2017 12:40:29 -0000

On Thu, Mar 09, 2017 at 04:43:19PM -0800, Eric Rescorla wrote:
> As noted in, the new fancy
> TLS 1.3 Certificate structure doesn't map well to the various non-X.509
> cert structures we have defined, specifically:
> - Raw Public Keys
> - Cached Info
> - OpenPGP
> Probably mapping each of these to 1.3 is relatively straightforward
> (Raw public keys == a list with one key, Cached info == the hash of
> each cert + its extensions, and so on), but I tend to think that given the
> modest/specialized deployment of these extensions, it's better to do a
> set of small bis RFCs to define each of these, rather than add a bunch
> of clutter to TLS 1.3 proper.
> Does anyone object to this? Volunteers.

Ugh, the situation is way worse than what I thought.

Basically, all three assume they have full control of certificate
message, worst of all being OpenPGP, which modifies it in more
complex ways (it isn't a pure element or list anymore).

And even with RPK, which appiles least severe modifications,
still modifies the structure in ways that are not obvious in
implications w.r.t. TLS 1.3.

Oh, and turns out I had implemented RPK in TLS 1.2 wrong by assuming
that it doesn't actually modify the certificate message format.
Which turned out to be wrong assumption (I fixed this after
discovering the format changes).

And then certificate types don't currently work sanely for client
certs, even if you knew how those map to Certificate message.

Client_certificate_type and server_certificate type aren't the
only problematic extensions w.r.t. TLS 1.3. The table of
extensions has the following too (all marked as allowed, I
added short reason I think those are problematic):

- client_certificate_url: Replaces certificate message. Hardcodes
  SHA-1 (which is now provably broken).
- user_mapping: Has extra handshake message.
- cert_type: All the problems of CCertT and SCertT, combined with
  fixing both to be the same.

With user_mapping, applying similar trick as in status_request is
not completely trivial because extensions that are answered in client
Certificate are offered in CertificateRequest. Okay, except that
extension is not an answer to ClientHello extensions, and the
extension assumes offer-answer relationship between client and server
extensions. Might need some special-casing.

Could be useful to have explicit list of extensions (no registry, since
this list can be never updated) that lists extensions that are
deprecated in TLS 1.3.

That is, only allowed in ClientHello and only if also advertising
prior versions.

AFAICT, the list would be:

- client_certificate_url?
- trusted_ca_keys
- truncated_hmac
- client_authz
- server_authz
- cert_type?
- srp
- status_request_v2
- client_certificate_type?
- server_certificate_type?
- encrypt_then_mac
- extended_master_secret
- cached_info?
- SessionTicket TLS (don't ask why it is written like this)
- renegotiation_info