libssl is reportedly doing multiple calls to CERT_VerifyCert for server's cert properties - SSL cert and SSL step-up. The number of calls can be reduced with a new API that is being worked on . See bug http://bugzilla.mozilla.org/show_bug.cgi?id=149832 .
The new API is called CERT_VerifyCertificate and is working in the tip.
Summary: SSL library needs to replace CERT_VerifyCert with new API calls → SSL library needs to replace CERT_VerifyCert with new CERT_VerifyCertificate API call
It is a good idea to do this in 3.6 so that the new function is being used, but it is past Beta already so I'm assigning priority P2.
Assignee: wtc → nelsonb
Priority: -- → P2
Mass retarget all my old NSS bugs that were previous targeted at NSS versions that have now been released.
Target Milestone: 3.6 → 3.7
With libSSL's present architecture, we could change the existing CERT_VerifyCert calls to CERT_VerifyCertificate, but it would be a lot more work to reduce those two calls into a single call, because the first one (the prime one) is made in a callback function that, in theory, is supplied by the application. If the application does not supply its own callback, then we use a default callback function in libSSL, named SSL_AuthCertificate. We could change SSL_AuthCertificate to use CERT_VerifyCertificate and check for both certUsageSSLServer and certUsageSSLServerWithStepUp, (when called from a client). The API to that callback expects to get back a SECStatus that reports whether the cert was valid for the usage certUsageSSLServer and had the right server name in it. The API does not provide a way to return info about the certUsageSSLServerWithStepUp usage. SSL_AuthCertificate would have to use some other means (like reaching into SSL data structures) to return that info (or we could invent a new API for this purpose). Since NONE of the existing application-supplied callbacks check for certUsageSSLServerWithStepUp, we'd have to continue to separately check for that if the application used a callback other than SSL_AuthCertificate. So, the options are: 1. Change the existing CERT_VerifyCert calls into CERT_VerifyCertificate calls, (and nothing more), or 2. Change the existing CERT_VerifyCert calls into CERT_VerifyCertificate calls, and add a new interface by which the callback can optionally also report whether the cert is ok for Step Up. Comments?
Nelson, If we are going to provide a new type of callback, I would prefer a third option : SSL would call CERT_VerifyCertificate with *all* possible usages, before it calls the callback. Then, it would provide that information to the callback function, as an argument, therefore eliminating the need for any callback function to cal CERT_VerifyCert / CERT_VerifyCertificate again. Obviously the prototype for the new callback would need to be slightly different to pass the extra info.
Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Moved to NSS 3.9.
Target Milestone: 3.8 → 3.9
This enhancement request requires a new callback prototype. Nominating as a NSS 4.0 feature.
Severity: normal → enhancement
Target Milestone: --- → 4.0
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.