signature_algorithms_cert extension

NEW
Unassigned

Status

NSS
Libraries
13 days ago
13 days ago

People

(Reporter: mt, Unassigned)

Tracking

(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 days ago
This isn't trivial because we have to change the way that we configure certificates.  I think that the best plan is something along the lines of:

1. Add a handler for the extension, and save the values (this might be done as part of bug 1423044, I don't know).

2. Change SSL_ConfigServerCert so that it adds a certificate unconditionally.  That means removing the checks on authType for certificates that are configured using that function (the field is still necessary for the legacy configuration functions unfortunately).  There are checks on this field in a few places that would need to be reviewed - either the field is retained and ignored when installing, or it is set to zero on installation and the checks are tweaked.  I prefer the latter because it completely detaches SSL_ConfigServerCert from the legacy APIs; if doing that, the field might be changed to SSLKeaType so that it more cleanly matches what is used in legacy APIs.

3. Change the certificate selection logic so that the entire chain is examined

4. Build a better way of saving which certificate was in use so that we can pick the right certificate after resumption.  ssl_FindServerCert currently uses authType, and that will no longer work properly, a substitute will have to be found.  Maybe we can store multiple key types and find the certificate with the longest string of matches.
You need to log in before you can comment on or make changes to this bug.