Open Bug 1427994 Opened 6 years ago Updated 2 years ago

signature_algorithms_cert extension

Categories

(NSS :: Libraries, enhancement, P3)

3.35
enhancement

Tracking

(Not tracked)

People

(Reporter: mt, Unassigned)

References

(Depends on 1 open bug)

Details

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.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.