Comment 8 for bug 741528

The idea to explicitly add the bad certs to the roots module is a good idea, but I don't know how to make this work. I don't see a way to make a cert as "explicitly not trusted". All I know of is "no explicit trust", but this is not sufficient, as the cert will still be trusted, if it can be chained to a trusted root.

The idea to use a CRL is problematic, because:
- I don't know an easy way to preship a CRL with binary NSS, because NSS reads CRLs from the database
- the approach might require that the applications ships the CRL and imports it at runtime. I think this approach is more work than the following one.

I'd like to propose the following approach (which, in a discussion with Gerv and Dan, we're currently favoring):

- block the certs at the application level
  (PSM = all mozilla apps = all SSL sockets)

- embed the certs into PSM

- extend PSM's existing code for SSL_AuthCertificateHook
  http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1088805

- compare the server cert with our embedded blacklist

- in order to embed the blacklist, use
  "issuer name" and "serial number" as the primary key to
  decide about rejection

Implementation details:

I already have a tool that dumps this ID information for a given cert.
(I'm using this tool to extract the information that we need to grant the EV status to a root).

At runtime, when we arrive at the function, we have available:
- the full binary blob of the cert
- the ascii (utf8?) presentation of the issuer name
- the binary encoding of the serial number

I think it's tricky to store binary encoding into sourcecode.
It's better to use base64 encoding.

This has a minimal performance disadvante, we must convert the site's serial number from binary to base64. (But really, this little cpu overhead shouldn't be worrisome, there are many more expensive operations involved in processing certificates than this, anyway)

In theory, in order to be 100% sure we're checking the correct certificates, we ought to compare the binary encoding of the issuer name.

However, in this particular scenario, we are able to simplify, IMHO. The certificates to be blocked all use an issuer name that consists of pure ASCII characters. I propose we save CPU cycles, and do a standard string comparison for the issuer name.

When we find a match, we'll set error code SEC_ERROR_REVOKED_CERTIFICATE and abort the verification.
The user will see the existing error page "site of cert is revoked".
The user will NOT be able to override.