Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client

[Geoffrey Keating <[e-mail]>]

Matt DeMoss <[e-mail]> writes:

> On Fri, Mar 4, 2011 at 6:41 PM, Martin Rex <[e-mail]> wrote:
> 
> 
> >
> > The TLS spec should not mess around with PKI and X.509 issues.
> > Negotiation of the algorithm used for the "digitally signed" struct
> > ought to be _completely_ seperate from characteristics of certificates.
> >
> > A TLS extension to convey hints about digital signature algorithms
> > ought to be a fairly black box to TLS, containing a list of
> > ASN.1 AlgIds, and with the semantic of a "hint to the PKI software
> > for selecting the most appropriate certificates", i.e. "MAY" not "MUST".
> >
> 
> This is interesting to me; as a kind of thought experiment do you
> think it would ever be appropriate for TLS to negotiate hash
> algorithms on CRLs or on OCSP responses? It seems unlikely that
> multiple CRLs will be generated with different hashes and that is only
> slightly less true for X.509 certs.

Well, let's look at the environment you'd be doing this in.

This extension is primarily useful if the server has multiple
certificates available and is trying to decide which to send because
there is no algorithm which all clients support.  So, some CA has
issued two certs for this server, one with SHA-1 and one with SHA256.

Presumably these two certs have different serial numbers.  That means
the OCSP responses will be different anyway.

If there are intermediate certificates, they also need to match the
hash algorithm, no point sending a SHA-1 certificate signed by an
intermediate with a SHA256 hash.  In that case, the leaf certificates
have to have different CRLs because the signers will be different.

It also makes no sense to issue two certificates and then point them
both at an OCSP responder or CRL which is signed by only one of the
hashes.  In any situation where you need to issue two certs, that just
won't work.  So you need to have different OCSP responders (or just
one responder that knows to use different hash algorithms for
different certificates) and different CRLs.

So, I don't think TLS needs to negotiate this, it's implicit in the
certificate negotiation.  The server probably won't even notice, it
just knows that 'this OCSP response goes with this certificate'.


BTW, this is a strong argument for negotiating certificate algorithms
separately from the "digitally signed" struct: the server does not
need to be able to verify its own certificates, or stapled OCSP
response, but it does need to implement the algorithm for the signed
TLS structures, so having them be negotiated to be the same causes an
unnecessary interoperability barrier (between the server and its CA).

> Does it make more sense for TLS to instead negotiate the version of
> X.509 (or PKIX profile, or other credential) in use and hope some
> future version will provide functionality for a smoother transition? I
> read RFC 5280 to say there can only be one signature per certificate,
> but it isn't hard to imagine having doubly signed certificates in the
> future.

I can't imagine a problem to which a solution is a new version of
X.509.  The deployment timeline would be so long that any problem
worth fixing would need to be fixed some other way.