1547617 - Improve certificate selection logic

Status: ASSIGNED

(NSS :: Libraries, enhancement, P2)

Description

[Martin Thomson [:mt:]]

When SSL_ConfigServerCert was introduced, it was built to mimic the SSL_ConfigSecureServer[WithCertChain] API. The now-deprecated API places certificates into slots based on SSLKEAType, which doesn't fit with our use of SSLAuthType for signaling how the connection was authenticated.

Things are even more complicated with the addition of two extensions for signaling which signature schemes are used in TLS 1.3 (signature_scheme and signature_scheme_cert). Delegated credentials (draft-ietf-tls-subcerts) adds another wrinkle to the certificate selection business. There, a server might want to offer several types of delegated credential.

Rather than try to slot certificates, we should just throw all certificates into a list and pick the first that works. This would allow us to configure the same certificate multiple ways (with different delegated credentials, for instance).

The primary cost here is to the deprecated API. For instance, SSL_SetStapledOCSPResponses uses SSLKEATYpe to target a certificate. If there are multiple such certificates, we would have to decide on what happens. I propose the following for those (deprecated) APIs:

• SSL_ConfigSecureServer[WithCertChain] will find all "matching" configurations and remove them. Then a single entry will be created.

• SSL_SetStapledOCSPResponses and SSL_SetSignedCertTimestamps will find the first "matching" configuration and update that.

This is very similar to what that code does today and will only cause problems if the new API is used.

The biggest change here is to SSL_ConfigServerCert, which will no longer "replace" an existing entry. The question is whether we want to have newer entries appear before older entries so that the effect of inserting similar entries is that the most recently entered is used. That would result in looking like replacement for the simple cases we currently support. However, it would result in code that configures certificates needing to use an unusual ordering, with the highest priority certificate being added last.

As SSL_ConfigServerCert is in ssl.h (and not sslexp.h), I think that the unusual ordering option is probably best. So newer entries will be inserted ahead of older ones.

Comment 1

[Robert Relyea]

I'm going to take a look at this. I think Martin's suggestion is a good one. This also fixes the problem that you can't configure both a ECDH and a DHE_ECDSA certificate at the same time (since the time the required certificate will have mutually exclusive requirements). I'm thinking I want to add a new ConfigServerCert so the current one maintains it's old sematic. Server applications will already have to change to take advantage of this.

bob