195842 - Certificate verification could be optimized by reordering processing

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Julien Pierre]

When verifying a certificate, we verify the certificate chain one cert at a time
- from leaf to root - in a loop. For each cert, we check signature, trust, key
usage, and revocation, until we go to the next cert up.

However, this is not the most efficient way to do it. You have to consider that
revocation takes a long time. So it makes sense to do the revocation check at
the end only, after the chain has been verified for all other purposes.
Otherwise, unnecessary revocation checks are performed, which can be lengthy.

For example, in this test :

(strange)/export/home/jpierre/nss/38/mozilla/dist/SunOS5.8_DBG.OBJ/bin{75}
certutil -d . -V -n "user789012's aol ID" -u C
Time for initial uncached verification :  0:22.121820

certutil: certificate is invalid: Peer's certificate issuer has been marked as
not trusted by the user.

certutil took 22 seconds because it had to read the 26 MB CRL from disk and
decode it. But as it turns out the failure was not revocation-related, this
lookup could have been avoided.

The next slowest operation is the verification of signatures. We might want to
do it second-to-last, before revocation checking. The quickest check is trust,
which we should keep at the beginning.

One side effect of these optimizations is that a different error may be returned
than before, in case there are multiple reasons why the cert won't verify.