On 05/02/2013 02:02 PM, Brian Smith wrote:
Robert Relyea wrote:
Oh, in that case I can say we have customers that definately need to
use CRLs that have been loaded and stored in the database.
To be clear, I don't know of any reason to consider the processing
of already-loaded CRLs as a requirement for Firefox.
Oh, then I'd say we really can't remove it....
Right now, I am thinking that we will remove it in the default configuration of
Firefox. If the user has switched Firefox to use the system's certificate
verification logic, and the system's certificate validation logic happens to
use this information, then it will get used. The good thing (for Firefox) is
that it will be the operating system's responsibility to provide tools to
manage this and also to make sure that it works, independently of anything that
Firefox explicitly does.
So are you actually going to ship a different version of NSS with the
default Firefox, or are you going to create a switch that changes the
behavior of NSS with respect to stored CRLs (and what about cached CRLs,
and do you want to support persistent cached CRLs?). I'm not really sure
this decision has been completely thought through...
I think this will address the desires of your customers, since they are using
system NSS with libpkix on RHEL, right? This would also meet the goal of
driving the web towards sane, uniform, and standardized certificate processing,
since Firefox wouldn't do it by default.
I'm not completely sure. I know I have to worry about off-line for
things like smart card login, which doesn't affect FF. I don't know if
the customer has some sort of off-line use of FF on windows (It does
seem like an oxymoron: off-line and FireFox and https...). You are
probably right on this case.
Cheers,
Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
