No CRL UI as of Firefox 24

[Kathleen Wilson]

All,

In case you missed the discussion (as I did), as of Firefox 24 there
will be no user-interface for CRLs.

https://bugzilla.mozilla.org/show_bug.cgi?id=867465#c12
--
To summarize:

- As of Firefox 24 there is no user-interface for importing a CRL or
modifying the CRLs that you have set to auto-import.

- All of the CRLs that you have setup for auto-import will continue to
be auto-imported as per your previous settings. See Comment #3 for details.

- If you want to see and/or modify your list of auto-importing CRLs, you
will need to install a previous version of Firefox.

- Or you can use crlutil
https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil
--


My questions to you...

1) May I delete the section about CRL DP from the Potentially
Problematic Practices wiki page?
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

2) May I stop doing the CRL checking that I do when I collect the
information for CA root inclusions?
https://wiki.mozilla.org/CA:Information_checklist (item #13)


Thanks,
Kathleen

[Kathleen Wilson]

On 8/13/13 3:16 PM, Kathleen Wilson wrote:
> - As of Firefox 24 there is no user-interface for importing a CRL or
> modifying the CRLs that you have set to auto-import.

I added a section about this change here:
https://wiki.mozilla.org/CA:ImprovingRevocation#Remove_CRL_User-Interface

There are also references to CRLs in Mozilla's CA Policy
- http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
-
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

Perhaps those CRL references can be deleted?

Kathleen

[David E. Ross]

On 8/13/13 3:16 PM, Kathleen Wilson wrote:

What is the bug number that authorized this change? In your opinion,
would this be an improvement or a "disimprovement" in security for a new
user who has no history of CRL?

--
David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., the government)
snooping into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>

[Jürgen Brauckmann]

Am 14.08.2013 00:16, schrieb Kathleen Wilson:
> My questions to you...
>
> 1) May I delete the section about CRL DP from the Potentially
> Problematic Practices wiki page?
> https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension
>
>
> 2) May I stop doing the CRL checking that I do when I collect the
> information for CA root inclusions?
> https://wiki.mozilla.org/CA:Information_checklist (item #13)

The change is in Firefox only, as far as I can see? What about other
Mozilla products?

Some people regard CRL processing as a valuable feature (Wasn't NIST
relying on CRLs?), and I would guess that there are many who want to
continue using CRLs even without UI.

So, I think it would be reasonable and valuable for Mozillas CA
Certificate Inclusion Policy to continue to enforce CRL issuance.

CAs will not stop issuing them anyway.

Regards,
Juergen

[Peter Gutmann]

Kathleen Wilson <kwi...@mozilla.com> writes:

>I added a section about this change here:
>https://wiki.mozilla.org/CA:ImprovingRevocation#Remove_CRL_User-Interface
>
>There are also references to CRLs in Mozilla's CA Policy
>- http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
>- http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
>
>Perhaps those CRL references can be deleted?

The talk about UI and policy changes is obscuring the real change that's going
on here, what will this do to CRL processing? Does it mean Mozilla apps won't
use CRLs any more and only use OCSP? If (say) Firefox sees a certificate,
what happens then in terms of CRLs and/or OCSP? Just trying to understand
what the underlying effects are here.

Peter.

[Ryan Sleevi]

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Presumably, it will continue to do the exact same thing it has always done
- absolutely nothing unless the user has explicitly configured CRLs to be
manually fetched.

This only affects the UI. It does not affect the existing processing
behaviour - which, however less than ideal it may be that Firefox never
chased CRL DPs, has been the long standing implementation.

As indicated in the bug and Kathleen's response, organizations can still
use utilities like crlutil. This only affects the UI surfaced for managing
that - which, arguably, is not something anyone could reasonably argue
users were doing, especially not for browsing the 'public' web.

[Kathleen Wilson]

On 8/13/13 5:36 PM, David E. Ross wrote:
> What is the bug number that authorized this change?

https://bugzilla.mozilla.org/show_bug.cgi?id=867465

> In your opinion,
> would this be an improvement or a "disimprovement" in security for a new
> user who has no history of CRL?

This will not impact security for a new user who has no history of CRL,
because only the CRLs that a user specifically imported or set up for
auto-import were used anyways.

Kathleen

[Kathleen Wilson]

On 8/13/13 10:29 PM, Jürgen Brauckmann wrote:
> The change is in Firefox only, as far as I can see? What about other
> Mozilla products?

Thunderbird 25.0: https://bugzilla.mozilla.org/show_bug.cgi?id=892255 --
Remove "Revocation Lists" button from Advanced > Certificates options

SeaMonkey 2.22: https://bugzilla.mozilla.org/show_bug.cgi?id=886099 --
Remove "Manage CRLs..." button from Preferences

>
> Some people regard CRL processing as a valuable feature (Wasn't NIST
> relying on CRLs?), and I would guess that there are many who want to
> continue using CRLs even without UI.
>
> So, I think it would be reasonable and valuable for Mozillas CA
> Certificate Inclusion Policy to continue to enforce CRL issuance.
>
> CAs will not stop issuing them anyway.
>

That sounds reasonable. If everyone is in agreement on this, then I
suppose I'll have to figure out how to use crlutil, so I can test the
CRLs when I do the verification of the CA's information.


Kathleen

[David E. Ross]

You might have misunderstood my second question. I am concerned about a
potential user who is indeed familiar with certificates and CRLs -- who
has a working history with CRLs -- but who is new to Mozilla-based
applications and has no existing CRLs relative to the NSS database of
root certificates.

[Brian Smith]

On Tue, Aug 13, 2013 at 3:16 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> - All of the CRLs that you have setup for auto-import will continue to be
> auto-imported as per your previous settings. See Comment #3 for
> details.

> - If you want to see and/or modify your list of auto-importing CRLs, you
> will need to install a previous version of Firefox.

No. The feature of auto-importing/updating CRLs through Firefox is gone.
CRLs won't be updated any more by Firefox. If you have another program
that is adding/updating your CRLs in your NSS certificate database,
then those CRLs will be used for the time being (probably; there are
no tests in Gecko for this, though there are tests in NSS).

> My questions to you...
>
> 1) May I delete the section about CRL DP from the Potentially Problematic
> Practices wiki page?
> https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_E
> xtension

That still applies as long as we support any CRLs imported from
crlutil or other sources.

> 2) May I stop doing the CRL checking that I do when I collect the
> information for CA root inclusions?
> https://wiki.mozilla.org/CA:Information_checklist (item #13)

I think we should have a more general discussion of how we do
revocation checking in Firefox. That discussion should answer these
two questoins.

Cheers,
Brian

[Brian Smith]

On Thu, Aug 15, 2013 at 10:36 AM, David E. Ross <nob...@nowhere.invalid> wrote:
> You might have misunderstood my second question. I am concerned about a
> potential user who is indeed familiar with certificates and CRLs -- who
> has a working history with CRLs -- but who is new to Mozilla-based
> applications and has no existing CRLs relative to the NSS database of
> root certificates.

Any Mozilla-based application that isn't Firefox could add the
functionality back in their source code tree, though it will be
painful (and increasingly so) for them to do so.

As for why the feature was removed:

0. Nobody could seriously think that the number of users of this
feature justified any effort spent on it.
1. It was buggy, in serious ways. There were crashing bugs on file.
There were bugs regarding the failure to auto-update the CRls. There
were no tests for the feature. There was no disk usage or network
quota management for the feature.
2. The CRL support in NSS does not support RFC-4158-style path
building, except when NSS is configured in a way that causes serious
problems that require significant effort to fix. One of our goals is
to finally support proper path building in Firefox and reducing the
number of points where the old, bad path building is used is part of
that goal.
3. We have much more important things to work on than any of the above things.
4. We did have a discussion about removing the feature on firefox-dev
and dev-tech-crypto and there was a clear consensus to remove the UI
for this as long as we didn't change any of the CRL processing in NSS
(which we didn't and don't plan to).
5. Firefox has never supported CRLDP and our lack of support for CRLDP
without any serious negative consequences for about two decades
demonstrates that CRL support is not really important to the security
of users online.

Cheers,
Brian

[Brian Smith]

On Sun, Aug 18, 2013 at 11:13 PM, Brian Smith <br...@briansmith.org> wrote:
> As for why the feature was removed:
>
> 0. Nobody could seriously think that the number of users of this
> feature justified any effort spent on it.
> 1. It was buggy, in serious ways. There were crashing bugs on file.
> There were bugs regarding the failure to auto-update the CRls. There
> were no tests for the feature. There was no disk usage or network
> quota management for the feature.
> 2. The CRL support in NSS does not support RFC-4158-style path
> building, except when NSS is configured in a way that causes serious
> problems that require significant effort to fix. One of our goals is
> to finally support proper path building in Firefox and reducing the
> number of points where the old, bad path building is used is part of
> that goal.
> 3. We have much more important things to work on than any of the above things.
> 4. We did have a discussion about removing the feature on firefox-dev
> and dev-tech-crypto and there was a clear consensus to remove the UI
> for this as long as we didn't change any of the CRL processing in NSS
> (which we didn't and don't plan to).
> 5. Firefox has never supported CRLDP and our lack of support for CRLDP
> without any serious negative consequences for about two decades
> demonstrates that CRL support is not really important to the security
> of users online.

Sorry, I forgot two:

5. (similar to #0 and #3) This feature was never implemented for
Firefox for Android or for Firefox OS. I couldn't justify adding the
complexity of this feature to those products for the near-zero (if not
negative) benefit it would offer. And, we have to make sure Firefox
for Android and Firefox OS are both safe even in the absence of this
feature. Well, if those products are safe to use even without this
feature, then desktop Firefox should also be safe to use without the
feature. And, if all of these products are approximately as safe with
or without the feature, then why keep it in desktop Firefox,
especially considering the bugs and limitations it had?

6. We have an ongoing effort to make our UI simpler throughout the
product by removing unnecessary options, especially ones with negative
side-effects. This is part of my contribution to making the UI
simpler, along with removing the manual OCSP responder configuration
UI and the TLS version selection UI. I am hopeful that we will be able
to further simply many aspects of the security and privacy options UI
in Firefox to a significant extent.

Thanks,
Brian

[David E. Ross]

On 8/18/13 11:28 PM, Brian Smith wrote [in part]:

>
> 6. We have an ongoing effort to make our UI simpler throughout the
> product by removing unnecessary options, especially ones with negative
> side-effects. This is part of my contribution to making the UI
> simpler, along with removing the manual OCSP responder configuration
> UI and the TLS version selection UI. I am hopeful that we will be able
> to further simply many aspects of the security and privacy options UI
> in Firefox to a significant extent.

In other words, the Firefox developers are dumbing-down the user
interface. This is only one example.

[Michael Ströder]

Brian Smith wrote:
> 5. Firefox has never supported CRLDP and our lack of support for CRLDP
> without any serious negative consequences for about two decades
> demonstrates that CRL support is not really important to the security
> of users online.

What a non-sense...

Ciao, Michael.

[Michael Ströder]

Brian Smith wrote:
> Sorry, I forgot two:
>
> 5. (similar to #0 and #3) This feature was never implemented for
> Firefox for Android or for Firefox OS. I couldn't justify adding the
> complexity of this feature to those products for the near-zero (if not
> negative) benefit it would offer. And, we have to make sure Firefox
> for Android and Firefox OS are both safe even in the absence of this
> feature. Well, if those products are safe to use even without this
> feature, then desktop Firefox should also be safe to use without the
> feature. And, if all of these products are approximately as safe with
> or without the feature, then why keep it in desktop Firefox,
> especially considering the bugs and limitations it had?
>
> 6. We have an ongoing effort to make our UI simpler throughout the
> product by removing unnecessary options, especially ones with negative
> side-effects. This is part of my contribution to making the UI
> simpler, along with removing the manual OCSP responder configuration
> UI and the TLS version selection UI. I am hopeful that we will be able
> to further simply many aspects of the security and privacy options UI
> in Firefox to a significant extent.

Even more non-sense. (sigh!)

Yes, I'm very much in favour of using CRLs over OCSP. Will have to look for
another browser...

Ciao, Michael.

[David E. Ross]

As I pointed out in a thread in a different news.mozilla.org newsgroup,
there is an ongoing trend to dumb-down the Firefox user interface.
While promoted as improving the user experience, a review of the related
bug reports shows that this is really motivated by the fact that
developers find that making the user interface work correctly is too
tedious for them. They would rather add new bells and whistles than fix
what is broken.

[Michael Ströder]

Forcing everybody to use OCSP will produce more data of the network traffic.

Ciao, Michael.

[fhw...@gmail.com]

If I may be crass for a moment it seems the argument for removal boils down to "the CRL UI is dumb and I hate it". That's how I feel about it anyway. 

But, that doesn't mean the UI and underlying functionality is not needed. I've seen corporate IT departments that do use the capability and rely on the use of CRLs. Some web applications also rely on it. This is especially the case where certs are distributed to individuals for restricted accesses. 

Also, the fact that it doesn't work and nobody complained doesn't mean that nobody expected it to work...and nobody complained. 

So, I'd be curious to know if:

A) Did Mozilla consult with corporate users and/or high security web app teams?

B) Is there a backup plan in case there is a backlash against Firefox 24?

The last thing we want is a roar of people saying Firefox broke everything, you can't upgrade to it.

[Michael Ströder]

Also the possibilty of configuring a corporate trusted OCSP responder was
dropped which one could feed with all the CRLs. So this is also not an
fall-back option.

Stupid!

Ciao, Michael.

[Ryan Sleevi]

On Wed, August 21, 2013 10:07 am, Michael Ströder wrote:

> Also the possibilty of configuring a corporate trusted OCSP responder was
> dropped which one could feed with all the CRLs. So this is also not an
> fall-back option.
>
> Stupid!
>
> Ciao, Michael.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Michael,

Can you explain why the use of crlutil, as originally discussed, does not
meet your needs or use case?

You suggest this is a step back for enterprise administration, but surely
enterprise admins are capable of configuring things properly using other
means.

How is this different from the concept of needing to change a registry key
on Windows - which an enterprise can do via Group Policy - but not
exposing said key through a visible UI? Or, in Linux terms, different from
using Puppet/Chef to manage a set of files or, alternatively, using
group/world-readable but not writable configuration files?

I think it would be helpful to discussion, and to understanding your
position, if you could consider the alternatives presented and explain why
they are unacceptable, given the design considerations Brian has raised,
rather than simply writing them off with "Stupid!" without contributing
useful feedback.

Cheers

[Michael Ströder]

> Michael,
>
> Can you explain why the use of crlutil, as originally discussed, does not
> meet your needs or use case?
>
> You suggest this is a step back for enterprise administration, but surely
> enterprise admins are capable of configuring things properly using other
> means.
>
> How is this different from the concept of needing to change a registry key
> on Windows - which an enterprise can do via Group Policy - but not
> exposing said key through a visible UI? Or, in Linux terms, different from
> using Puppet/Chef to manage a set of files or, alternatively, using
> group/world-readable but not writable configuration files?
>
> I think it would be helpful to discussion, and to understanding your
> position, if you could consider the alternatives presented and explain why
> they are unacceptable, given the design considerations Brian has raised,
> rather than simply writing them off with "Stupid!" without contributing
> useful feedback.

Personally I can deal with crlutil. I'm also familiar with group policies and
Puppet.

But normal users can't do this. It was easy for them to just click on a URL
downloading a CRL and set check boxes for letting the software download the
CRL once a day. And at least the downloads happened with my local Seamonkey
installation.

And I can't see why this was dropped. Turning off security features because
some UI designers don't like the dialogue is stupid.

What really strikes me is the tendency in Brian's postings that even if you
import CRLs with crlutil it's not guaranteed that this will be supported in
the not so far future. It seems to me everybody is forced to use OCSP (if the
CA provides it and the URL is in the certificate). But personally I regard
OCSP as yet another privacy nightmare.

The developers simply don't care about security features and simply hide the
configuration options. More and more...

Ciao, Michael.

[Eddy Nigg]

On 08/19/2013 09:13 AM, From Brian Smith:

> 5. Firefox has never supported CRLDP and our lack of support for CRLDP
> without any serious negative consequences for about two decades
> demonstrates that CRL support is not really important to the security
> of users online.

I beg to differ here - the fact that the browser "worked" without it
doesn't mean it was a serious lack and during the course of many years
Firefox supported many certificates without any means of certificate
status checking. Only since OCSP was made a requirement through the
Baseline Requirement, Firefox users can be better protected. The lack of
CRL and CRLDPs was one of THE shortcomings, together with the inability
to fetch the certificate chain via AIA extension.

At least for intermediate CA certificates CRLs are way better suited
since they hardly change. Also for frequently used issuers, CRLs could
be more efficient than OCSP.

Equally you could remove OCSP support and claim that it will not impact
the users since you probably will never get a complaint - it will just
"work".

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Ryan Sleevi]

On Wed, August 21, 2013 1:31 pm, Michael Ströder wrote:

> > Michael,
> >
> > Can you explain why the use of crlutil, as originally discussed, does
> > not
> > meet your needs or use case?
> >
> > You suggest this is a step back for enterprise administration, but
> > surely
> > enterprise admins are capable of configuring things properly using other
> > means.
> >
> > How is this different from the concept of needing to change a registry
> > key
> > on Windows - which an enterprise can do via Group Policy - but not
> > exposing said key through a visible UI? Or, in Linux terms, different
> > from
> > using Puppet/Chef to manage a set of files or, alternatively, using
> > group/world-readable but not writable configuration files?
> >
> > I think it would be helpful to discussion, and to understanding your
> > position, if you could consider the alternatives presented and explain
> > why
> > they are unacceptable, given the design considerations Brian has raised,
> > rather than simply writing them off with "Stupid!" without contributing
> > useful feedback.
>

> Personally I can deal with crlutil. I'm also familiar with group policies
> and
> Puppet.
>
> But normal users can't do this. It was easy for them to just click on a
> URL
> downloading a CRL and set check boxes for letting the software download
> the
> CRL once a day. And at least the downloads happened with my local
> Seamonkey
> installation.

I think the empirical evidence and telemetry gathered would likely
disagree with you on this point.

Any security setting that requires 'normal' users (for whatever value of
normal there is) to click through multiple security UI dialogs - AND
understand the implications of what they're changing - is certainly a
failure on the security UI.

Further, given how unlikely this feature is to be used, it would seem that
the 'normal' users who would be instructed to go through such a UI are
likely of a technical competence to be able to use other means.

I think it's a reasonable balance between making sure that UIs remain
simple and clean and provide the user actionable steps and providing the
flexibility of configuration.

>
> And I can't see why this was dropped. Turning off security features
> because
> some UI designers don't like the dialogue is stupid.

Security features are as much - if not more so - a UX problem as an actual
technological problem.

Brian's points about the technical debt incurred by such features,
compared with the value, don't seem to be addressed by your sentiments
here, other than you simply disagree. Is that a fair statement?

>
> What really strikes me is the tendency in Brian's postings that even if
> you
> import CRLs with crlutil it's not guaranteed that this will be supported
> in
> the not so far future. It seems to me everybody is forced to use OCSP (if
> the
> CA provides it and the URL is in the certificate). But personally I regard
> OCSP as yet another privacy nightmare.

OCSP with stapling does not have the same privacy implications.

Revocation of intermediates and roots is already something that CRLs do
not scale well to.

CRLs themselves on the public Internet are not something that scale well
either (case in point: certain CA's 40mb CRLs).

Regardless, however, it seems your point of contention in this point is
less with the UI in and of itself, and more about how you view the
relative strengths and weaknesses of CRLs vs OCSP. You would rather prefer
CRLs over OCSP (for privacy reasons), although for the vast majority of
users, it's much more important for them as individuals to favour the
performance of OCSP over the CRLs.

This would be a case where the Firefox developers need to make a choice to
best serve the majority of their users. They could continue to support
both (thus serving both contingents), or they may decide that the costs of
that maintenance exceed the benefits of supporting both. Both are
reasonable engineering decisions, however, and shouldn't be taken as
intentional slights.

>
> The developers simply don't care about security features and simply hide
> the
> configuration options. More and more...
>

[fhw...@gmail.com]

From: Ryan Sleevi Sent: Wednesday, August 21, 2013 3:55 PM

...snip...

I think the empirical evidence and telemetry gathered would likely
disagree with you on this point.

^^ RS ^^

What evidence and telemetry was collected and where might we examine it?

vv RS vv

Any security setting that requires 'normal' users (for whatever value of
normal there is) to click through multiple security UI dialogs - AND
understand the implications of what they're changing - is certainly a
failure on the security UI.

Further, given how unlikely this feature is to be used, it would seem that
the 'normal' users who would be instructed to go through such a UI are
likely of a technical competence to be able to use other means.

^^ RS ^^

I think the word "unlikely" is unsubstantiated when you consider a large deployment (say, over 1000 users). There are undoubtedly countless documents, web pages, screen shots, PowerPoint slides, help desk procedures, and so forth that were put together by sys admins to explain to their users how to manipulate the Firefox trust store.

I've seen examples, too, where they say "the easiest way to do < whatever > is in Firefox..." followed by a complicated procedure. To be sure, most users won't understand but they don't necessarily have to.

So instead of logically explaining why the functionality won't be missed, I think the discussion we need to have is what are we going to do when somebody misses it? Even if it's broken in a lot of ways, I guarantee you that someone depends on that UI. 

[Michael Ströder]

Ryan Sleevi wrote:
> Any security setting that requires 'normal' users (for whatever value of
> normal there is) to click through multiple security UI dialogs - AND
> understand the implications of what they're changing - is certainly a
> failure on the security UI.

Well, then why not drop TLS support and all other security features
completely? This would make NSA's job even more easy.

Ciao, Michael.

[Rick Andrews]

Since support for CRLs has been removed from Firefox, why does Mozilla's root policy (http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/) require CAs to maintain and publish CRLs?

Is it because Mozilla intends to build CRLs sets in the future?

[Gervase Markham]

Yes.

Gerv

[Brian Smith]

On Fri, Mar 14, 2014 at 4:05 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 13/03/14 19:20, Rick Andrews wrote:

> > Is it because Mozilla intends to build CRLs sets in the future?
>

> Yes.
>

I always thought that the CRL requirement was in there because long of go
we expected that we'd eventually start fetching CRLs at some point, and
then it was left in there due to inertia, mostly.

Keep in mind that S/MIME and TLS have different requirements. OCSP is a
significant private issue for both. We can resolve that for TLS by
switching to OCSP stapling. But, there's no good, practical stapling
solution for S/MIME (S/MIME can in theory do stapling, but nobody does). It
may be that we need to have separate requirements for S/MIME and TLS.

I think it will make sense to revise the CRL requirement in the future,
after we've figured out how we're going to build the revocation lists, and
after we've figured out Must-Staple, and after we've figured out the issue
in the preceding paragraph. If we don't end up using CRLs for building the
revocation list then CRLs could very well be useless. Also, nobody has
proposed a plan for using CRLs to build the revocation list, though Google
does do that.

Practically speaking, I'd argue strongly against any inclusions of CAs that
don't support OCSP into our root store and/or EV programs. I wouldn't
argue, at this time, against any CAs that don't do CRLs, but that could
change.

Cheers,
Brian

[Michael Ströder]

Brian Smith wrote:
> I always thought that the CRL requirement was in there because long of go
> we expected that we'd eventually start fetching CRLs at some point, and
> then it was left in there due to inertia, mostly.
>
> Keep in mind that S/MIME and TLS have different requirements.

I really wonder why this is discussed *after* quickly hunking out CRL support
even from Thunderbird and Seamonkey.

Actually this means that you don't have revocation checking when drafting an
e-mail while traveling.

Ciao, Michael.

[Brian Smith]

On Sun, Apr 13, 2014 at 7:41 AM, Michael Ströder <mic...@stroeder.com>wrote:

> Brian Smith wrote:
> > I always thought that the CRL requirement was in there because long of go
> > we expected that we'd eventually start fetching CRLs at some point, and
> > then it was left in there due to inertia, mostly.
> >
> > Keep in mind that S/MIME and TLS have different requirements.
>

> I really wonder why this is discussed *after* quickly hunking out CRL
> support
> even from Thunderbird and Seamonkey.
>

I spent a long time talking with Brendan and also with my former managers
at Mozilla about how we support Thunderbird while we improve Gecko for
Firefox. Unfortunately, Mozilla hasn't done a good job of frankly
explaining the policy. Basically, Gecko developers are allowed to basically
work almost as though Thunderbird doesn't exist; if we break something in
Thunderbird, it's up to the Thunderbird developers to fix it. It isn't
clear if Gecko developers actually have a responsibility to help integrate
fixes for Thunderbird, but I and others seem to all review patches to Gecko
for the Thunderbird team to fix breakage we caused.

In this instance, if we've broken something regarding S/MIME, it's up to
the Thunderbird developers to notice and fix it. Unfortunately, there are
no automated tests of S/MIME functionality (AFAICT) so it is likely that
nobody will notice if/when we break anything with S/MIME in Thunderbird.
AFAICT, the Thunderbird project is in need of somebody to volunteer to
maintain the S/MIME functionality, and has been in need of somebody for a
long time.

For a long time I've been wanting to remove the S/MIME code from Gecko
completely. It is likely that will happen the next time the S/MIME code
inconveniences us during Firefox development. I would guess that the
Thunderbird team would then import the S/MIME code into comm-central and
maintain it there.

Cheers,
Brian