Robert Relyea wrote: > On 05/02/2013 02:02 PM, Brian Smith wrote: > 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...
There are no plans to change NSS, so as long as we're using NSS we would still check the stored CRLs, though there would be no UI to manage them. I doubt that the type of deployments that you are concerned about are managing these CRLs through the Firefox UI anyway. > > 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. I am only talking about SSL. There seems to be a vague agreement to stop using code signing for Firefox extensions, and I have a goal of removing all the email-certificate related stuff from Gecko (moving all S/MIME functionality it to mailnews). So, then Gecko and Firefox only need to worry about the SSL case. Like you noted, it would be very strange to me to *require* these offline CRLs for the SSL case for a closed network. Also, even if it were to be important to those particular users, it does not seem to be a particularly important use case for the Firefox product. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
