On 05/09/2013 03:47 PM, Brian Smith wrote:
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.
So to be clear:
You propose removing the mime processing for CRLs which imports the CRLs
into the database.
You propose removing the UI that manages CRLs in the database (and also
automatically fetches the CRLs).
You are not changes the NSS processing which automatically checks the
CRLs if they are there.
The only downside I see is that someone who had set crls up in the past
won't be able to remove them using firefox. I suggest coming up with a
plan to help these people recover (I think the number should be small
enough).
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.
OK, if mailnews still has the UI, that's probably fine. I suspect the
customer may use the mail interface to distribute CRLs. If they were
using FF to fetch them, one wonders why OCSP doesn't work in that case..
Cheers,
Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
