Re: [TLS] TLS 1.3 certificate delegation?

[Andy Lutomirski <[e-mail]>]

On Fri, Nov 8, 2013 at 8:16 AM, Salz, Rich <[e-mail]> wrote:
>> > It is a bad idea to introduce violations of PKIX standards (RFC 5280) in TLS  1.3.
>
>> Please explain why.
>
> TLS uses certificates.  Certificates use the CA structure.  The CA structure has a particular trust model.  PKIX [dr]efines an instance of that trust model. PKIX is used throughout the Internet when X.509 certificates are used, almost exclusively.  It is hard to write trust-path code and get it right. Adding a new complexity for this one special case (even if it is a major user) makes library re-use harder, and is could well make all certificate-using software on the same computer open to buggy and/or confusing behavior.
>

This doesn't necessarily need to change the PKIX validation algorithm
at all [1].  Rather than presenting a proxy certificate, the server
could present a standard (valid according to PKIX / TLS 1.2 rules)
certificate and *separately* present a chain of public keys, each
signed by the previous one and marked with validity times, where the
first public key is signed by the server certificate and the last
public key is compatible with the key exchange algorithm.  (To keep it
simple, the allowable final key types could be limited to fixed DH
parameters and RSA/ECDSA signing keys -- there's no reason to support
traditional RSA key exchange here.)

None of this needs to be in X.509 format.  An advantage of *not* using
X.509 is that libraries can't make the mistake of asking clients to
validate these keypairs -- clients should validate the actual PKIX
certificate instead.

There's no need for revocation, OSCP stapling, or related mechanisms
-- the validity periods can be kept short enough that a validly signed
key is equivalent to a valid, fresh OCSP response.

This is a lot like how QUIC works.  I think Google got that part of
the protocol right.

Of course, the downside of this approach is that it's a much more
intrusive change in the TLS protocol (proxy certificates don't require
any protocol change except some indication from the client that it
accepts proxy certificates).

--Andy