On Thu, Mar 09, 2017 at 04:43:19PM -0800, Eric Rescorla wrote: > As noted in https://github.com/tlswg/tls13-spec/issues/722, 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 -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
