Closed Bug 477244 Opened 15 years ago Closed 15 years ago

Embed a list of URLs for CRLs and have Firefox fetch and update them periodically

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
3.5 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: KaiE, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

Patch to relax requirements on intermediate certs
2.45 KB, patch
Details | Diff | Splinter Review 
      No description provided.
Blocks: 474606
No longer depends on: 477243
Depends on: 477243
Johnath, I would like to object on this approach. It really behooves Mozilla to
implement CRL fetching in the year 2009 for all CAs. Apparently there are no
patent problems and the code exists to my understanding.

(I should have posted this comment here, not at bug 477240)
(In reply to comment #4)
> Johnath, I would like to object on this approach. It really behooves Mozilla to
> implement CRL fetching in the year 2009 for all CAs. Apparently there are no
> patent problems and the code exists to my understanding.

I'm sympathetic to this, but they are not mutually exclusive, nor has Kai said
that CRLDP support will not be implemented in 2009.  In fact, he has suggested
elsewhere that it will be a matter of months, not years, for that support to
reach an appropriately stable state that we can rely on it.  Any measures we
take in the interim around ensuring that we have strong revocation information
for EV CAs will be rolled back once we have proper CRLDP support, but we also
won't let perfect be the enemy of good, here.

(In reply to comment #1)
> (I should have posted this comment here, not at bug 477240)

(As should I)
(In reply to bug 477240 comment 6)
> Is there a road-map or plan?

I think you want bug 321755 if you want to track the progress of CRLDP support.  A precondition of resolving this bug is that we file a followup, blocked on bug 321755, to remove the code added here once CRLDP support has been implemented.
+1
Kai - are you working on this bug, or is your expectation that someone else is?
I have not yet worked on this bug, help would be welcome.
We need code that runs at startup time, and modifies the CRL entries in the prefs.js file, so that automatic update for all CRls we want gets added.

Dynamic code is required, because the CRL pref entries seem to be numbered, and a user could already have other CRLs added.

Furthermore, for each such CRL entry we add automatically, we should add some flag to distinguish this automatic addition from a user's explicit additions. This would allow us to remove those automatic addition at a later time from users' profiles, once we have bug 321755 fixed and available in Firefox.
Kai - is the pref route significantly safer than just adding an appropriate interface to nsICRLManager that looks like importCRL,, but is totally silent?  Just as a way to avoid needing to account for existing CRLs?
(In reply to comment #8)
> Kai - is the pref route significantly safer than just adding an appropriate
> interface to nsICRLManager that looks like importCRL,, but is totally silent? 

Your approach seems reasonable, but please add the flag to distinguish our addition from user's additions.

> Just as a way to avoid needing to account for existing CRLs?

You mean because you saw code in importCRL that already accounts for existing CRLs?
(In reply to comment #7)
> We need code that runs at startup time, and modifies the CRL entries in the
> prefs.js file, so that automatic update for all CRls we want gets added.

Looking more at this approach, which prefs specifically would need to be managed here?  I see references to the set of security.crl.autoupdate.* prefs in a couple places (e.g. http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCRLInfo.h#45 ) in various places but I'm not clear on:

 - Are those the right prefs?  
 - If so, how can I determine the "nameInDB" to append to each set of prefs, or is that up to me?
 - Which prefs do I need to specify values for (I'm assuming .url & .enable, but am not sure about the others or whether default values will work)? 
 - Is it sufficient to just set the prefs, or do I need to kick the CRLManager afterwards?

> Dynamic code is required, because the CRL pref entries seem to be numbered, and
> a user could already have other CRLs added.

I don't see this numbering in the prefs, though I do see that each CRL has its own suffix based on nameInDB - where does the numbering appear?

> Furthermore, for each such CRL entry we add automatically, we should add some
> flag to distinguish this automatic addition from a user's explicit additions.
> This would allow us to remove those automatic addition at a later time from
> users' profiles, once we have bug 321755 fixed and available in Firefox.

I agree - I think we could do this by just adding another pref for those CRLs, to be checked by later code, could we not?  Or do you think it needs to be in the CRL DB?
Depends on: 479229
Additionally, I find on current trunk that when I manually import the CRLs, it does not restore EV status to those sites.  E.g.

1) Manually import http://crl.globalsign.net/ExtendVal1.crl 
2) Visit https://addons.mozilla.org/en-US/firefox/

I currently see DV treatment after performing the above, and would expect EV.  Kai, in addition to the questions above, am I missing something here?
No longer depends on: 479229
(In reply to comment #11)
> Additionally, I find on current trunk that when I manually import the CRLs, it
> does not restore EV status to those sites.  E.g.
> 
> 1) Manually import http://crl.globalsign.net/ExtendVal1.crl 
> 2) Visit https://addons.mozilla.org/en-US/firefox/
> 
> I currently see DV treatment after performing the above, and would expect EV. 
> Kai, in addition to the questions above, am I missing something here?


Yes, sorry for not clarifying it earlier.

The current PSM code asks for valid revocation info for both
- server cert
- intermediate certs

I think our intention is to limit requirements to the server cert, and not requiring for the intermediate certs.

The attached patch is required to relax this.
Johnathan, with this patch applied and the CRL imported, do you get EV?
(In reply to comment #10)
> (In reply to comment #7)
> > We need code that runs at startup time, and modifies the CRL entries in the
> > prefs.js file, so that automatic update for all CRls we want gets added.
> 
> Looking more at this approach, which prefs specifically would need to be
> managed here? 

I don't know, finding out is part of solving this bug.
I propose to manually add such a auto-update-CRL using UI and compare prefs.js


> I see references to the set of security.crl.autoupdate.* prefs
> in a couple places (e.g.
> http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCRLInfo.h#45
> ) in various places but I'm not clear on:
> 
>  - Are those the right prefs?  

security.crl.autoupdate sounds right.


>  - If so, how can I determine the "nameInDB" to append to each set of prefs, or
> is that up to me?

I thought you want to create a modified version of the current import code, that would automatically add a new pref for the newly imported CRL. Wouldn't that do all the pref magic for you? (plus an addition to add one more pref for distinguishing from user added CRLs)

According to nsCRLInfo.cpp the "nameInDB" seems to get poplated from the OU (org-unit) field.


>  - Which prefs do I need to specify values for (I'm assuming .url & .enable,
> but am not sure about the others or whether default values will work)? 

I like your other proposal that would use the existing code to create the prefs, instead of writing your own code. 

I didn't write the CRL code. I can't give recommendations on the prefs. I would have to research myself. Hopefully you can either use existing code to create it, or learn from studying the created prefs.


>  - Is it sufficient to just set the prefs, or do I need to kick the CRLManager
> afterwards?

There is a global CRL timer, so, if the next-update-times are good, you should be fine.


> > Dynamic code is required, because the CRL pref entries seem to be numbered, and
> > a user could already have other CRLs added.
> 
> I don't see this numbering in the prefs, though I do see that each CRL has its
> own suffix based on nameInDB - where does the numbering appear?

I had misremembered. If it's not a number, but based on the name, that's great.


> > Furthermore, for each such CRL entry we add automatically, we should add some
> > flag to distinguish this automatic addition from a user's explicit additions.
> > This would allow us to remove those automatic addition at a later time from
> > users' profiles, once we have bug 321755 fixed and available in Firefox.
> 
> I agree - I think we could do this by just adding another pref for those CRLs,
> to be checked by later code, could we not?

Yes, sounds good.


> Or do you think it needs to be in the CRL DB?

No, let's stay away from the NSS DB (which stores the CRLs).
In reply to comment #12:
> I think our intention is to limit requirements to the server cert, and not
> requiring for the intermediate certs.
>
> The attached patch is required to relax this.

"I think our intention is..."?

When will you know for sure?
(In reply to comment #12)
> I think our intention is to limit requirements to the server cert, and not
> requiring for the intermediate certs.

It seems highly doubtful to me that this kind of revocation checking
meets the requirements/expectations of the EV Guidelines. Even if they do not spell it out explicitly (at least not for SSL certificates), I assume that the guidelines expect certificates to be validated according to section 6 of RFC 5280 (or 3280, or even 2459, for that matter), which says, inter alia:

   The basic path processing actions to be performed for certificate i
   (for all i in [1..n]) are listed below.
 
      (a)  Verify the basic certificate information.  The certificate
           MUST satisfy each of the following:
         [...]
         (3)  At the current time, the certificate is not revoked.  This
              may be determined by obtaining the appropriate CRL
              (Section 6.3), by status information, or by out-of-band
              mechanisms.

(note "for all i in [1..n]" in the second line of this quote)

I object to relaxing the revocation requirements for EV SSL certs as
proposed by attachment 363120 [details] [diff] [review]. Instead, the list of preconfigured CRL URLs should be extended to include CRLs for intermediate CAs as well (if that's how the issue is going to be addressed in 3.1).
OS: Linux → All
Hardware: x86 → All
Version: 3.0 Branch → 3.1 Branch
+1

...or CAs should really operate OCSP responders by now and/or re-issue end-user certificates affected by missing OCSP URI in the AIA extension. 

Else lets clutter NSS with CRLs it should be fetching by itself by now anyway :-(
Depends on: 479229
So as I understand the goals are:
1. have a list of all CAs rooted by EV CAs
2. pick from that list those CAs that don't have OCSP AIA
3. then drop CAs that don't have any CRLDP extension (probably are not valid EV issued certs?)
4. from the rest collect distinct list of CRL urls from CRLDP of each cert
5. for each URL we don't already have a 'security.crl.autoupdate.url.*.<URL>' preference call nsNSSComponent::DownloadCRLDirectly (the key argument is unused)
5a. if there is already a record, flag it to do update on every firefox start?
6. optionally, set some pref not to walk the CA list again on firefox start from now

Repeat step 5 and 5a for any newly imported CA conforming 1. - 4.

The nsNSSComponent::DownloadCRLDirectly API have to be enhanced to set doSilentDonwload on PSMContentDownloader instances and add a new flag like isAutomatic. 

It seems that nsCRLManager::ImportCrl that finally handles data from the URL doesn't expect silent downloads for not yet imported URLs, we need to update its code i.e. if there is no entry for that CA yet, create one and enable auto update by default.

We are probably dependent on bug 418921.
Guys,
   As a representative of a CA that produces CRLs and pays for serving them to the internet, your approach of downloading CRLs on expiry compares very unfavourably with your competitor browser's approach of downloading CRLs on demand.  As far as I understand it, both Opera and IE fetch a CRL only when a site is visited which required that CRL to be checked AND an unexpired copy of that CRL is not already held.
I have done some back-of-the-envelope calculations which show that your "download-on-expiry" method (even if limited to EV-only CRLs) will generate a greater number of hits to our CRL servers that all the rest of our CRL traffic put together - and quite out of proportion with your share of the installed base of browsers/platforms.
I anticipate that CAs whose installed base of certificates is smaller than ours could suffer perhaps a factor of ten increase in the number of CRL hits they experience if your proposed method is implemented.  

Have you considered the demands you are placing on the CRL servers of CAs who are present in your trust-list?

Perhaps I have misunderstood your proposed method.  
Do I correctly understand that you will have something of the order of 100 million active Firefox users downloading a number of CRLs at a regular interval whether or not it is required?
Will this number of firefox users be downloading the new CRL at the same instant (either the moment the previous CRL expires, or 24 hours before that), or will measures be taken to spread the load (temporally) somewhat?

Regards
Robin Alden
Comodo
Assuming that CLRs for EV certs are relatively small (~10KB) that would be still a whooping ~ 950 GB if all users would open the browser at the same time...not bad :D
(In reply to comment #18)
> Guys,
>    As a representative of a CA that produces CRLs and pays for serving them to
> the internet, your approach of downloading CRLs on expiry compares very
> unfavourably with your competitor browser's approach of downloading CRLs on
> demand.  As far as I understand it, both Opera and IE fetch a CRL only when a
> site is visited which required that CRL to be checked AND an unexpired copy of
> that CRL is not already held.

Hi Robin,

You will find no disagreement from me that the situation would be considerably ameliorated if we had support for fetching CRLs on demand (bug 321755). In the absence of that support or any other fix like the one contemplated here, the result will be that EV certificates employing CRLs will show as DV in Firefox 3.1, and I am not particularly keen on that outcome either nor, I imagine, are you.

The suggestion in this bug to fetch the certificates manually, is an attempt to mitigate the impact of the lack of CRLDP support for CAs like yourselves but obviously we won't do so for any CA that doesn't wish it.

Given that CRLDP support will not be available, you have suggested here and elsewhere a couple of alternative approaches:

 1) Pre-load the CRLs but only update on visit to an appropriate site, rather than periodically
 2) Use a designated OCSP responder for all certs from a particular issuer, regardless of the content of the certificate

I'm not sure either of these is implementable in a 3.1 timeframe, but I would invite Kai/Honza to comment on the feasibility of these approaches. If they aren't though, and if there are CAs who would prefer this approach to no fix, we will continue to look to implementing it.

I'm not trying to stonewall or anything, Robin, I would very much like to find a resolution to this that all parties are satisfied with. If you have other alternatives to suggest either here or via email, I would welcome them.
Hi Johnathan,
  Thanks for stating my preferred approaches.  My comment would have been more valuable had I included them rather than just state my negative feelings.
For #2, I would restate it slightly as
 2) Use a designated OCSP responder for all certs from a particular issuer as a default, unless an OCSP responder URL is present in the certificate (in which case use it), and (optionally) only until bug 321755 is fixed.

You ask if I have other solutions.  I do not have any which I see as being acceptable.

One way I can reduce the risk of 100M hits trying to download an EV CRL in a 5 minute period could be to issue my CRLs every few minutes, and have each one valid for (say) 48 hours.  That would spread the 100M hits into smaller bursts of fetches every five minutes or so.  That could get my hit rate (for Mozilla-driven EV CRLs) to average out over the day rather than all be clustered into one apoplectic burst.  If I do that I may be able to serve the traffic you generate.

Here are some thoughts about ways I can try and address the problem:-
I could generate CRLs that are valid for long periods so they aren't downloaded very often - but the EV guidelines prohibit me from doing that. 

I could ask Mozilla to host a copy of my CRL (updated from time to time) at a new URL just for Firefox to download as it sees fit.  That would give you the headache of serving the "bursty" CRL traffic - but I can't see you going for that option.  I wouldn't if I were you.

I could just swallow the (say) US$10K cost per year extra that it might cost me in serving CRLs - but I would feel that I had been railroaded into it, and that only solves Comodo's problem.  The other affected CAs still have their own decisions to make.

I could offer to assign some or all of that US$10k figure to sponsor the CRLDP work, but would that produce a fix for 3.1? - and I get that railroaded feeling again.
Perhaps I could spread the sponsoring cost over the affected CAs, but perhaps I wouldn't get any takers.

I could just choose not to have the URL to our EV CRLs embedded, and to allow that proportion of our EV certificates which don't have the OCSP responder URL in them to fail to get the EV treatment in Firefox.  If I choose this option then, for each customer that complains to me that she doesn't get the expected EV behaviour with Firefox, I get the opportunity (and cost) of either re-issuing the certificate or of directing them to the PR material we would make available that explained the EV shortcomings in Firefox 3.1 - but that puts me at a competitive disadvantage to other CAs, so I would loathe to do it.

I could ask Mozilla to embed my CRL within Firefox and to issue a new point release of Firefox every time I issue a new CRL.  We don't revoke many EV certificates, but if and when we do could you issue a security update every week (at the very least)?  I would imagine you don't really want 100M users downloading a new copy of Firefox every week just to get a CRL update out.

As I mentioned, I don't see any of those as being practical solutions.

Robin
The participants in this bug should be aware of two other bugs related to 
updating of CRLs.  They are bug 371522 and bug 418924.  The summary is that
Firefox's automated fetcher of CRL updates has not been very reliable, but
it has largely gone unnoticed because so few people ever attempt to use it.

Bug 371522 (now fixed in NSS, but fix not yet present in any Firefox release)
observed that if we fetched a CRL update and got exactly the same CRL that 
we already had, we would lose the stored URL, and therefore be unable to 
fetch any further updates.  

Bug 418924 may be a duplicate of bug 371522, or may be a separate bug that 
has the same effect as bug 371522.  It states (hypothesizes ?) that for each stored CRL Firefox tries at most one time to fetch an update, and if that attempt does not result in fetching a new cert with a newer nextUpdate date, then FF does not try again for that CRL/issuer. 

In any case, before we "bet the farm" on Firefox's automatic cert updater,
we should take care that it actually works.
Depends on: 371522, 418924
Nelson, did you really mean bug 418924 ( Selecting text with the keyboard is slow )?
(In reply to comment #17)

> So as I understand the goals are:
> 1. have a list of all CAs rooted by EV CAs
> 2. pick from that list those CAs that don't have OCSP AIA
> 3. then drop CAs that don't have any CRLDP extension (probably are not valid EV
> issued certs?)
> 4. from the rest collect distinct list of CRL urls from CRLDP of each cert

Yes, and this work I have already been doing for the impacted CAs - Robin from Comodo has raised issues that we should deal with, but I think they should not stop progress on this bug.

> 5. for each URL we don't already have a 'security.crl.autoupdate.url.*.<URL>'
> preference call nsNSSComponent::DownloadCRLDirectly (the key argument is
> unused)

Or otherwise get them into the CRL DB, yeah.  The constraints here are that each CRL should be imported in a way that enables auto-update, and that it *must not* trigger any follow-up prompting or user interaction.

> 5a. if there is already a record, flag it to do update on every firefox start?

Notwithstanding the bugs Nelson cites, the CRLs should be flagged to auto-update according to their built in lifetime information.

> 6. optionally, set some pref not to walk the CA list again on firefox start
> from now

Yes, should only happen once, assuming it succeeds.

> Repeat step 5 and 5a for any newly imported CA conforming 1. - 4.

Ideally there won't be others, but yes.

> The nsNSSComponent::DownloadCRLDirectly API have to be enhanced to set
> doSilentDonwload on PSMContentDownloader instances and add a new flag like
> isAutomatic. 
> 
> It seems that nsCRLManager::ImportCrl that finally handles data from the URL
> doesn't expect silent downloads for not yet imported URLs, we need to update
> its code i.e. if there is no entry for that CA yet, create one and enable auto
> update by default.
> 
> We are probably dependent on bug 418921.

I have a WIP patch that accomplishes some of the work, but it does basically what you describe, and I know you've worked more closely on PSM code than I have recently. We need to get this solved sooner rather than later, and I would appreciate your help on it, since I know Kai is quite busy with other things.

Robin, replies to follow.
(In reply to comment #21)
> Hi Johnathan,
>   Thanks for stating my preferred approaches.  My comment would have been more
> valuable had I included them rather than just state my negative feelings.

Not at all, I appreciate your willingness to work through options with me.

> For #2, I would restate it slightly as
>  2) Use a designated OCSP responder for all certs from a particular issuer as a
> default, unless an OCSP responder URL is present in the certificate (in which
> case use it), and (optionally) only until bug 321755 is fixed.

I do think this would be helpful, if possible.  Kai/Honza?  Is there a way to do this without being maximally intrusive?

> Here are some thoughts about ways I can try and address the problem:-
> I could generate CRLs that are valid for long periods so they aren't downloaded
> very often - but the EV guidelines prohibit me from doing that. 

Right, it won't help our EV indicator here to adopt solutions which contravene the guidelines.

> I could ask Mozilla to host a copy of my CRL (updated from time to time) at a
> new URL just for Firefox to download as it sees fit.  That would give you the
> headache of serving the "bursty" CRL traffic - but I can't see you going for
> that option.  I wouldn't if I were you.

I will discuss this option with our IT group. It's not clear to me whether this would work for the code or not (will PSM be unhappy if the CRL is fetched from a location that doesn't match the cert?  Probably not, but I'd like to know for sure). I'm not ready to rule this out yet.

> I could just swallow the (say) US$10K cost per year extra that it might cost me
> in serving CRLs - but I would feel that I had been railroaded into it, and that
> only solves Comodo's problem.  The other affected CAs still have their own
> decisions to make.

In any event, each CA will certainly have to tell us which option they prefer, and we have been speaking with them to that effect.

> I could offer to assign some or all of that US$10k figure to sponsor the CRLDP
> work, but would that produce a fix for 3.1? - and I get that railroaded feeling
> again.
> Perhaps I could spread the sponsoring cost over the affected CAs, but perhaps I
> wouldn't get any takers.

Yeah, this is not a solicitation for donations.  What we lack right now is available, experienced developers, not cash.

> I could just choose not to have the URL to our EV CRLs embedded, and to allow
> that proportion of our EV certificates which don't have the OCSP responder URL
> in them to fail to get the EV treatment in Firefox.  If I choose this option
> then, for each customer that complains to me that she doesn't get the expected
> EV behaviour with Firefox, I get the opportunity (and cost) of either
> re-issuing the certificate or of directing them to the PR material we would
> make available that explained the EV shortcomings in Firefox 3.1 - but that
> puts me at a competitive disadvantage to other CAs, so I would loathe to do it.

Certainly if all else fails, this is the fall back position.  If that happens, you can be assured that I will have a blog post explaining the limitations, which you can reference from any such press materials.

> As I mentioned, I don't see any of those as being practical solutions.

Certainly none of them are ideal, but I appreciate you taking the time to work through them.
In reply to Kai's comment #6:
> ...help would be welcome
and to Johnathan's comment #25:
> > 2) Use a designated OCSP responder for all certs from a particular issuer
> > as a default, unless an OCSP responder URL is present in the certificate
> > (in which case use it), and (optionally) only until bug 321755 is fixed.
>
> I do think this would be helpful, if possible.  Kai/Honza?  Is there a way to
> do this without being maximally intrusive?
<snip>
> What we lack right now is available, experienced developers...

I accept your invitation (and I hope I prove to be experienced enough!) :-)

The patch I just attached implements a default OCSP Responder URL for all of the CA Certificates that Comodo ever use in EV certificate chains.  The latest Mozilla trunk + NSS trunk + this patch causes the EV UI to appear once more for sites that use Comodo EV certs.
No CRLs need to be imported, and Kai's "Patch to relax requirements on intermediate certs" is not required.

If other affected CAs (GlobalSign, Network Solutions, Trustwave, etc) have OCSP Responders, their details could be added very easily.
(In reply to comment #24)
Johnathan, feel free to throw the patch to me. We have to change some of non-public APIs to pass flags like 'silent' and 'auto', it should not be a problem.

(In reply to comment #18)
To Robin Alden (and probably all others). As intermediate solution we should decide how to implement bug 418921 (not 418924). There is IMHO no need to re-fetch CRLs at every start for those marked for auto-update. We should re-fetch in some intervals based on 'Next Update' field. Say, try four times in the next-update interval, i.e. next update will be in 20 days, try to re-fetch every 20/_4_ = 5 days? Round-up to try not more then every one or two days?

Also, it IMHO doesn't make sense to do this on every start, my Firefox runs for days (or weeks) on one of my machines and on other one is started 20 times a day :) so we need to auto-update only when CRL is considered obsolete (every quarter of the next update interval, for example).

Makes sense?

(In reply to comment #27)
Cool idea, I am just not sure this could be easily merged to 1.9.1.
Not bad, Rob! Please just allow me to question the approach of hard coding OCSP responders into NSS...on the other hand the roots are hard coded too, so who cares. Certainly a policy decision I guess. 

Also is querying the subject line the right way to search for the OCSP URI? But Nelson will tell that for sure ;-)
Hard coding OCSP responders sucks big time, but we think it is a viable work-around for the deficiencies in the currently to-be-offered revocation checking systems - at least for those CAs who have an available OCSP responder which can give a meaningful reply for all certificates issued by that CA whether or not the certificates themselves include an OCSP responder URL.
I don't think this is primarily a policy issue.

The CA's name and key uniquely define it, of course, so choosing an OCSP responder based on the CA name while relying on the existing certificate path processing to effectively check the key would seem adequate to us.
To summarize Rob's proposal:

- for CAs that don't like the new CRL download traffic,
  offer a way to divert to an OCSP responder known at build time

- this proposal only works for those CAs that indeed have
  such a responder

- in order to make it work, embed knowledge about those responders
  directly into NSS


As NSS is a separate project, and Firefox a consumer of the NSS code, the NSS team might not like the idea to make the change in the proposed way. But I don't know.

The trouble is that Firefox consumes unmodified snapshots of NSS.
Note the list of EV roots is not stored in NSS, but in Firefox' PSM module.

As the motivation here is to solve an application problem, a solution that avoids embedding in NSS and modifies Firefox' PSM code would be preferable. But this approach would require a bit more code:

- implement a new callback function
  e.g. GetOCSPDefaultResponderByIssuerName

- change NSS' ocsp_GetResponderLocation
  to call new function GetOCSPDefaultResponderByIssuerName

- move your root list and implementation to PSM ( security/manager/ssl )

- have PSM register this callback at NSS init time
Nelson, Julien, would you be OK with the proposed change to NSS as described in comment 31 ?

Are you OK with Rob's original proposal, or would you prefer my modified proposal?
(In reply to comment #20)
> Given that CRLDP support will not be available, you have suggested here and
> elsewhere a couple of alternative approaches:
> 
>  1) Pre-load the CRLs but only update on visit to an appropriate site, rather
> than periodically

This approach is equivalent to the missing CRLDP support.
We don't have the code to "detect" when we are visiting an "appropriate site".
Correctly deriving the respective CRL URL from a cert is the hard part of CRLDP support.

On the other hand...

Maybe a hack implementation could be:
- each time we check a cert
  - try to extract CRL URLs embedded
  - compare to the list of CRLs configured for auto update
  - if a match is found, try to auto update this CRL

But this logic is not sufficient, it would have to be combined with a logic to minimize repetitive downloads. Some new code would have to remember "we have downloaded recently, don't do it again" or "we failed within the last 2 seconds, don't try again now"

All this additional logic is avoided with the "simply download regularly" approach.
The part that I don't understand:

If you DO have an OCSP responder, why don't you simply re-issue new certs to all your EV customers, and we avoid your additional trick-CRL-into-OCSP code?
(In reply to comment #28)
> To Robin Alden (and probably all others). As intermediate solution we should
> decide how to implement bug 418921 (not 418924). There is IMHO no need to
> re-fetch CRLs at every start for those marked for auto-update. We should
> re-fetch in some intervals based on 'Next Update' field. Say, try four times in
> the next-update interval, i.e. next update will be in 20 days, try to re-fetch
> every 20/_4_ = 5 days? Round-up to try not more then every one or two days?
> Also, it IMHO doesn't make sense to do this on every start, my Firefox runs for
> days (or weeks) on one of my machines and on other one is started 20 times a
> day :) so we need to auto-update only when CRL is considered obsolete (every
> quarter of the next update interval, for example).
> Makes sense?
Your comments around that bug make good sense, but my problem is with the whole approach of downloading a new CRL automatically at some interval before expiry.  It is not ideal.  
It makes good sense if you make the assumption that all active firefox users visit at least one site every day for each of the CAs for whom automatic CRL downloads are enabled.  The data we have from our existing CRL server logs indicate that assumption is not true.
If Opera and Internet Explorer had implemented their CRL fetching using the same method (download on expiry) then we would need (and this is a guess) ten times the infrastructure available to us now as CRL servers.
(In reply to comment #34)
> The part that I don't understand:
> If you DO have an OCSP responder, why don't you simply re-issue new certs to
> all your EV customers, and we avoid your additional trick-CRL-into-OCSP code?

That approach is not commercially attractive.  Put another way, we don't want to incur the cost of communicating with (some proportion of) our EV customers and having them install new certificates.
I'm not aware that we have anything in our subscriber agreement that requires the customer to install replacement certificates at our request.  The customers expect EV treatment (reasonably or unreasonably) as widely as possible and if they don't get it it is automatically our (Comodo's) fault as far as they are concerned.
We implemented our EV certificates and especially the parts relevant to revocation checking carefully in compliance with the EV guidelines.  Mozilla supports those EV guidelines (although not being a CA is not bound by them) but has chosen a partial implementation of revocation checking which requires work-arounds of some sort - whether CRL or OCSP.  We really don't want to re-issue our certificate base to fix the problems presented by a partial implementation of revocation checking in FF3.1 which will then (possibly) be fixed in a forthcoming version.
(In reply to comment #27)

> If other affected CAs (GlobalSign, Network Solutions, Trustwave, etc) have OCSP
> Responders, their details could be added very easily.

I am in complete agreement with Comodo that their patch is the most palatable solution at this time for all impacted parties: Mozilla, CA's, and most importantly SSL customers and their end-users.  Network Solutions supports this solution and will be glad to provide our OCSP Responder details for inclusion.
+1
Adding Gerv to CC list, because of comment 34 and comment 36.

(In reply to comment #36)
> That approach is not commercially attractive.

Please remember that Mozilla Firefox is a non-profit project.

From my point of view, the approach mentioned in comment 34 is be a compromise. CAs make money selling certs, and CRL-only CAs probably have had some kind of (commercial) benefit by FF 3.0.x giving EV UI treatment to their certs. With this compromise those who benefit from selling certs would do the work to fix the problem.

I speak for myself, not for the project.
> (In reply to comment #36)
> > That approach is not commercially attractive.
> 
> Please remember that Mozilla Firefox is a non-profit project.
> 
> From my point of view, the approach mentioned in comment 34 is be a compromise.
> CAs make money selling certs, and CRL-only CAs probably have had some kind of
> (commercial) benefit by FF 3.0.x giving EV UI treatment to their certs. With
> this compromise those who benefit from selling certs would do the work to fix
> the problem.
> 
> I speak for myself, not for the project.

It's certainly true that we have no direct commercial interest in certificate issuance, but we are members of the group (the CABForum) which sets out standards for CA issuance that we consider "strong enough to merit enhanced treatment in the browser."

We pushed for OCSP-only during that process, but the arguments were that the existing server products were not trustworthy at scale, and it would take time for them to get there. We agreed that, our own lack of CRLDP support aside, it was better for the internet to have a strong standard for identity vetting which included revocation information, than for us to insist upon OCSP immediately and thereby write a standard that CAs said they couldn't implement.

The CAs depending on CRLs in the interim are adhering to rules we helped write. Yes, if we are unable to get any kind of mitigation in place, they will have to re-issue or otherwise deal with the downgraded status, but I'm really loathe to insist upon them changing to suit our implementation concerns if we have any viable options for answering our own need for revocation information.

If we are forced to say "no alternatives exist, move to OCSP and reissue, or you will be downgraded," CAs will respond however they will, but we should not be surprised if it hurts our ability to work with CAs on future policy issues.  I think an interim measure that allows us to respect ALL EV certs from trusted CAs is worth doing, and preferable to punting it back to the CAs to cope with.

Thanks for the patch, Rob! Are Kai's comments in comment 31 something you can work with?
Going back to the technical point of view of the potential solution proposed by Rob, in addition to my comment 31, I have one more proposal:

In the past the idea to identify certs by issuer has been rejected. For the EV-granted listed embedded in the Firefox PSM module, we used the combination of "issuer name encoding" and "serial number encoding" and "cert fingerprint" for failsafe identification. I propose the same approach should be used when producing the "cert to OCSP responder" mapping as proposed by Rob.
Kai: I am deferring to johnath to look after this bug and process. Or is there some particular aspect where you particularly want my input?

Gerv
(In reply to comment #23)
> Nelson, did you really mean bug 418924 

No, sorry, I meant bug 418921.  Sigh.
(In reply to comment #24)

> Notwithstanding the bugs Nelson cites, the CRLs should be flagged to
> auto-update according to their built in lifetime information.

Well, one of our CAs updates their CRL every 8 hours.  I don't think they
want 100 million hits every 8 hours.  

For OCSP, we have a number of parameters to the fetching algorithm. 
There is a minimum time between successive attempts which applies to both
successful and unsuccessful attempts.  There is also a maximum lifetime,
so that we don't trust a 2 year old response, even if it says on its face
that it is good for 3 years.  

Our OCSP fetching is on demand, so there's little synchronicity of browsers
all pounding on the same server at once.  That's good.  IMO, if we time 
CRL update fetches based on their nextUpdate field, we run a real risk of 
having all Firefox browsers on the planet start to try to fetch CRL updates
at the very same time.  So, I would suggest adding a random value in the 
range 0-12 (or 0-24 hours) to the nextUpdate time, and using that randomized
result as the target time for a new update.  That way, the browsers requests
will be spread out over some reasonable time frame.
Comment on attachment 364100 [details] [diff] [review]
Patch NSS to use a default OCSP Responder for Comodo's CAs

I'll review Rob's patch.

Rob,, is this OCSP responder already in existence? 
If so, one wonders why your certs don't reference it in AIA extensions.
Attachment #364100 - Attachment description: Patch to use a default OCSP Responder for Comodo's CAs → Patch NSS to use a default OCSP Responder for Comodo's CAs
Attachment #364100 - Flags: review? → review?(nelson)
(In reply to comment #45)
> Rob,, is this OCSP responder already in existence? 
> If so, one wonders why your certs don't reference it in AIA extensions.
Although I'm not Rob, I'll answer on his behalf.

Yes, the OCSP is already in existence.  That OCSP responder will give a valid response for any certificate that Comodo have issued.

All certificates that we issue today do include the OCSP responder URL in the AIA extension.
The snag is that if you look back to the certificates we issued 18 months ago we weren't adding the OCSP responder URL then because the OCSP responder wasn't live when we issued those certificates.
Robin, this also means that a few month from now there will be no valid EV certs without OCSP URI pointer from your CA anymore. Am I assuming this correctly?
(In reply to comment #47)
That is correct.
Perhaps we should investigate how many CAs are affected and for how long. In case of <= 6 month from now, it wouldn't be worth the effort I think.
Comment on attachment 364100 [details] [diff] [review]
Patch NSS to use a default OCSP Responder for Comodo's CAs

Rob's patch does what (I believe) he intended for it to do, and seems to 
do a good job of it.  I find no errors in the code.  This code makes the
change in a function that is used for OCSP by both the old and new cert 
verification code, so it kills two birds with one stone.
  
Rob, for your first time at bat, that's a VERY good job!

But, unfortunately, I must give the patch r- for the reasons Kai outlined
in comment 31.  This change would affect ALL products that use NSS, including
Mozilla clients, servers from Sun and Red Hat, and numerous other programs
and products that use NSS.  But AFAIK, this change is only appropriate for 
Mozilla client products.  

IMO, the right way to do this is to define a new callback interface, by 
which applications can register their own functions to be called for 
finding an OCSP server in some application-defined way.  I would define
the interface so that it passed the address of the CERTCertificate out 
to the callback function.  The function would then be able to study the
entire contents of the cert, and not only the issuer name, for the 
purpose of determining the OCSP responder to use, if any.  

I'm willing to devise a patch to implement the callback features in NSS.
Rob's code could be turned into one of those callback functions in PSM 
with little effort.

But before we go down that path, I want to ask: is this really a solution?
As I recall, Johnathan found 4-6 EV CA roots whose PKIs use CRLs and not OCSP.
Do all of them now have ocsp responders that can answer these requests?
If only half of them do, is it worth it to do this work for just that half?
Attachment #364100 - Flags: review?(nelson) → review-
In reply to comment #41:
> In the past the idea to identify certs by issuer has been rejected. For the
> EV-granted listed embedded in the Firefox PSM module, we used the combination
> of "issuer name encoding" and "serial number encoding" and "cert fingerprint"
> for failsafe identification. I propose the same approach should be used when
> producing the "cert to OCSP responder" mapping as proposed by Rob.

Kai, I thought you might pick me up on this.  I did start looking at following the "issuer name encoding" approach (and oops, I left a stray '#include "nssb64.h"' in my patch!)

I agree that PSM's myTrustedEVInfos[] does the right thing.  However, I don't think that "serial number encoding" and "cert fingerprint" are appropriate to my patch...

Firstly, as far as I can tell, ocsp_GetResponderLocation() only knows about the individual certificate for which it needs to hunt for an OCSP Responder URL.
From where would the code locate the serial number and fingerprint of this certificate's issuer?  (Comodo and many other CAs put the "keyIdentifier" into AIA extensions, but do *not* include the "authorityCertIssuer" and "authorityCertSerialNumber").

Secondly, the use of cross-certification by Comodo and other CAs means that there are often multiple candidate CA certificates to choose between when building a certificate chain.  If my patch kept a list of serial numbers and fingerprints, it would need to explicitly list each of these cross-certificates.  As it stands, my patch doesn't need to do this, which keeps it simpler and would work with any other cross-certificates that might be issued in the future.

Perhaps the best approach would be for my patch to check "issuer name encoding" and "AIA extension encoding" ?
In reply to comment #50:
> Rob, for your first time at bat, that's a VERY good job!

Thanks Nelson! :-)

> But, unfortunately, I must give the patch r- for the reasons Kai outlined
> in comment 31.

OK.

> I'm willing to devise a patch to implement the callback features in NSS.
> Rob's code could be turned into one of those callback functions in PSM
> with little effort.

No objections from me.  :-)
In reply to comment #37:
> I am in complete agreement with Comodo that their patch is the most palatable
> solution at this time for all impacted parties: Mozilla, CA's, and most
> importantly SSL customers and their end-users.  Network Solutions supports
> this solution and will be glad to provide our OCSP Responder details for
> inclusion.

Patch v2 attached.  This adds default OCSP Responder details for Network Solutions EV certificate chains.

Firefox trunk + NSS trunk + this patch always gives a sec_error_ocsp_invalid_signing_cert error when browsing to https://www.networksolutions.com.

However, with Firefox trunk + NSS trunk + this patch + Nelson's "Patch v1 for NSS Trunk" from Bug #479029, the OCSP check works and I see the EV UI for https://www.networksolutions.com once again.
Attachment #364100 - Attachment is obsolete: true
In reply to comment #50:
> But before we go down that path, I want to ask: is this really a solution?
> As I recall, Johnathan found 4-6 EV CA roots whose PKIs use CRLs and not OCSP.

Yes, Johnathan found 5.  This bug depends on 1 bug for each such CA (#477240, #477241, #477242, #477243, #479229).

I've just done some quick analysis of Johnathan's Alexa data and I find the same 5 and no others.

> Do all of them now have ocsp responders that can answer these requests?

? GlobalSign: ocsp.globalsign.com exists in DNS at least
? Trustwave: unknown
Y Network Solutions: ocsp.netsolssl.com
? SECOM Trust: unknown
Y COMODO: ocsp.comodoca.com / ocsp.usertrust.com

> If only half of them do, is it worth it to do this work for just that half?

I say "yes" !

My analysis finds that 85.6% of the EV Certificates without AIA->OCSP URLs in Johnathan's Alexa data were issued by either COMODO or Network Solutions.
In reply to comment #49:
> Perhaps we should investigate how many CAs are affected and for how long. In
> case of <= 6 month from now, it wouldn't be worth the effort I think.

I've looked at the Alexa data again, and I find that the latest EV certificate expiry dates (for certificates that don't include AIA->OCSP) for each of the 5 CAs is no earlier than:

GlobalSign: 15th Jan 2011
Trustwave: 13th Nov 2010
Network Solutions: 31st Dec 2010
SECOM Trust: 21st Oct 2010
COMODO: 15th Sep 2010

That > 6 months by a long way.
Well that sucks too :-(

I have to check once again with the EV guidelines, but is the cutoff date end of 2010 for issuing certs or for valid certs? It's not an issue for us, hence I haven't looked at t more into depth.
Additionally I think we should once more consider to invest our efforts in correct CRL fetching than waste the time for such hacks.
In reply to comment #56:
> Well that sucks too :-(

Maybe, but these CAs are not breaking the EV Guidelines.

> I have to check once again with the EV guidelines, but is the cutoff date end
> of 2010 for issuing certs or for valid certs? It's not an issue for us, hence I
> haven't looked at t more into depth.

The EV Guidelines state that "CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010."

So GlobalSign, Trustwave and SECOM Trust could quite reasonably choose to avoid deploying any OCSP capability at all for the next 22 months!

Furthermore, given that an EV Certificate may be valid for 27 months, a conforming CA could quite legitimately issue one on Dec 31st 2010 without any OCSP capability, which would expire on March 31st 2013 !!
Also, note that the EV Guidelines *NEVER* absolutely require the Authority Info Access extension to be present in an EV Certificate!

Even when a CA does operate an OCSP Responder, and even after 2010, EV Certificates are not required to include OCSP Responder URLs (as long as they do include a CRL Distribution Point URL)!

(Suddenly the idea behind my patch looks even more useful!)
Nah, better take Johnath and Kai's word to implement CRLDP. I believe it's on the way anyway...
In reply to comment #60:
> Nah, better take Johnath and Kai's word to implement CRLDP. I believe it's on
> the way anyway...

In comment #20, Johnathan said "Given that CRLDP support will not be available".
In reply to comment #50:
> But, unfortunately, I must give the patch r- for the reasons Kai outlined
> in comment 31.  This change would affect ALL products that use NSS, including
> Mozilla clients, servers from Sun and Red Hat, and numerous other programs
> and products that use NSS.  But AFAIK, this change is only appropriate for
> Mozilla client products.

Nelson, just out of curiosity, are you suggesting that my patch would actually break stuff with these other products that use NSS?
(In reply to comment #54)
> In reply to comment #50:
> > But before we go down that path, I want to ask: is this really a solution?
> > As I recall, Johnathan found 4-6 EV CA roots whose PKIs use CRLs and not OCSP.
> 
> Yes, Johnathan found 5.  This bug depends on 1 bug for each such CA (#477240,
> #477241, #477242, #477243, #479229).
> 
> I've just done some quick analysis of Johnathan's Alexa data and I find the
> same 5 and no others.
> 
> > Do all of them now have ocsp responders that can answer these requests?
> 
> ? GlobalSign: ocsp.globalsign.com exists in DNS at least
> ? Trustwave: unknown
> Y Network Solutions: ocsp.netsolssl.com
> ? SECOM Trust: unknown
> Y COMODO: ocsp.comodoca.com / ocsp.usertrust.com
> 
> > If only half of them do, is it worth it to do this work for just that half?
> 
> I say "yes" !
> 
> My analysis finds that 85.6% of the EV Certificates without AIA->OCSP URLs in
> Johnathan's Alexa data were issued by either COMODO or Network Solutions.

I agree.  If Nelson & Kai find Rob's patch acceptable technically, I will contact the other CAs to ask whether they would prefer this approach.  Without committing them to anything or speaking for them, I suspect that some, but not all, of the remaining 3 will be amenable to this approach.
(In reply to comment #51)
> Kai, I thought you might pick me up on this.  I did start looking at following
> the "issuer name encoding" approach (and oops, I left a stray '#include
> "nssb64.h"' in my patch!)
> 
> I agree that PSM's myTrustedEVInfos[] does the right thing.  However, I don't
> think that "serial number encoding" and "cert fingerprint" are appropriate to
> my patch...


When I proposed to use {isser name, serial number, fingerprint} I think we have a misunderstanding which serial number and fingerprint to use.

We want a CA-CERT to CRL mapping.
Your patch implements that by using "issuer name of CA-CERT", only.

For the mapping, I propose to use:
- issuer name of CA-CERT
- serial number of CA-CERT
- fingerprint of CA-CERT

This is what the existing code uses.

Not serial number of the issuer, not fingerprint of the issuer.
Nelson, when you work on the NSS patch to add the new
functions for an application to set up the mapping
table, please take the opportunity to verify it is
inappropriate to just put the mapping table in NSS.

If an application tells NSS to use OCSP, and given
the condition described by Comodo in comment 46, it
seems that it should be fine for NSS to use the mapping
table provided by Comodo -- we'd be just applying
Comodo's decision retroactively to older certs issued
by Comodo, with Comodo's blessing.
In reply to comment #64:
> I think we have a misunderstanding which serial number and fingerprint to use.
> ...
> We want a CA-CERT to CRL mapping.

I think you meant "URL" (for a default OCSP Responder) rather than "CRL".

> Your patch implements that by using "issuer name of CA-CERT", only.
>
> For the mapping, I propose to use:
> - issuer name of CA-CERT
> - serial number of CA-CERT
> - fingerprint of CA-CERT
>
> This is what the existing code uses.

The "existing code" for EV in PSM only cares about identifying specific self-signed Root CA Certificates.  As I've said, I agree that checking the issuer name / serial number / fingerprint is the right thing for it to do.

In contrast, my patch needs to reliably identify which CA (for which there may exist *multiple* Root/Intermediate/Cross CA Certificate(s) with the *same* Public Key and Subject Name) issued the certificate for which an OCSP Responder URL is being looked for.

> Not serial number of the issuer, not fingerprint of the issuer.

Actually, I think we're talking about the same thing.

In comment #51, I said "From where would the code locate the serial number and fingerprint of this certificate's issuer?".  By "this certificate's issuer", I meant "CA-CERT" in your terminology.
ocsp_GetResponderLocation() knows about 1 CERTCertificate object, which does contain the "issuer name of CA-CERT", but which does *not* appear to contain or provide anyway to lookup the "serial number of CA-CERT" or the "fingerprint of CA-CERT".  (Please correct me if I'm wrong).

I went on to suggest that "issuer name encoding" and "AIA extension encoding" would be a better mapping.
- These fields are available in CERTCertificate.
- "issuer name encoding" reliably identifies the CA's Subject Name.
- "AIA extension encoding" reliably identifies the CA's Public Key (when the AIA "keyIdentifier" option is used).
(In reply to comment #53)

> Patch v2 attached. This adds default OCSP Responder details for 
> Network Solutions EV certificate chains.

Thanks Rob. I confirm that your updated patch does include the correct CA Name / OCSP Responder URL details for NetSol EV.

> Firefox trunk + NSS trunk + this patch always gives a 
> sec_error_ocsp_invalid_signing_cert error when browsing to 
> https://www.networksolutions.com.
>
> However, with Firefox trunk + NSS trunk + this patch + Nelson's "Patch 
> v1 for NSS Trunk" from Bug #479029, the OCSP check works and I see the 
> EV UI for https://www.networksolutions.com once again.

We've done some tests and found that this same problem affects Firefox 3.0.x as well !!!

This means that NetSol EV SSL Certificates that *do* contain OCSP Responder URLs (of which there are mercifully few, because we only started doing this
recently) *never* get the EV UI in Firefox 3.0.x !!!
(We've tested Firefox 3.0.0 and 3.0.6).

This leaves us with no option but to *stop* including our OCSP Responder URL in the EV SSL Certificates we issue, and to avoid starting to include it again until the Firefox 3.0.x userbase reaches 0% of the market. :-(

As a result of this discovery, we are now in complete agreement with Robin's objections (Comment #18) to your CRL pre-loading idea.

Please, please, please commit to doing one of the following things before releasing Firefox 3.1:

1. accept Rob's patch, or...
2. commit Nelson/Kai to modifying Rob's patch so that you do accept it, or...
3. finish CRLDP support.
As 2. seems to be agreed from all sides, I would personally vote for it as well and could potentially start working on it immediately.
Honza, I don't agree that (2) is agreed from all sides. 
We're working on (3) as fast as possible.
In response to NetSol's proposal "to *stop* including our OCSP Responder URL 
in the EV SSL Certificates we issue, and to avoid starting to include it 
again until the Firefox 3.0.x userbase reaches 0% of the market.", 
I think that's not a great idea.  

IINM, FF 3.1 will soon require that some form of revocation test (CRL or OCSP) 
be successfully performed as a prerequisite to showing the green bar.  

Don't rule out the possibility that bug 479029 will be fixed in FF 3.0.x.
(In reply to comment #69)
> Honza, I don't agree that (2) is agreed from all sides. 

Not at all.

> We're working on (3) as fast as possible.

Yes! :-)
(In reply to comment #67)
> We've done some tests and found that this same problem affects Firefox 3.0.x 
> as well !!!
> 
> This means that NetSol EV SSL Certificates that *do* contain OCSP Responder
> URLs (of which there are mercifully few, because we only started doing this
> recently) *never* get the EV UI in Firefox 3.0.x !!!

For completeness, could you please provide a link to a site that uses a NetSol cert having both CRLDP and OCSP AIA listed, failing to show EV in FF 3.0.x? Thanks.
I've seen one at https://www.softballoutlet.com/
In reply to comment #70:
> In response to NetSol's proposal "to *stop* including our OCSP Responder URL
> in the EV SSL Certificates we issue, and to avoid starting to include it
> again until the Firefox 3.0.x userbase reaches 0% of the market.",
> I think that's not a great idea.

Nelson, are you really suggesting to NetSol that they continue to issue EV SSL Certificates that fail to give the EV UI in the current release of Firefox?

I think you'll find it hard to convince NetSol that that's a great idea.

> IINM, FF 3.1 will soon require that some form of revocation test (CRL or
> OCSP) be successfully performed as a prerequisite to showing the green bar.

NetSol's EV certs appear to always contain the CDP extension, which AFAIK they don't plan to remove.  If FF 3.1 (now called 3.5) will have full support for CDP, all is well.

Also, the patch I've proposed is able to use NetSol's OCSP Responder even if/when their EV SSL Certificates don't contain AIA->OCSP.  If NetSol do omit AIA->OCSP for the foreseeable future, then it may be worth accepting my patch (or some variant of it) now and leaving it in place even after CDP support has been fully implemented.

> Don't rule out the possibility that bug 479029 will be fixed in FF 3.0.x.

Sure, but what % of FF 3.0.x users will upgrade (and over what timeframe) to an FF 3.0.x/3.5.x version that does include the fix for bug #479029?

If the answer to that question is anything < 100% and/or any timeframe longer than "immediately", then I think NetSol's concerns in comment #67 are still valid.
I question the usefulness of such hacks due to the shortcomings of CAs. In my opinion this isn't the correct solution.
Eddy, what is the "shortcoming" you perceive in that CA?
They provide both CRLDP and OCSP URL.  For this CA at least, FireFox is capable of using neither.
Interestingly Network Solutions own site seems to be working correctly with OCSP hard fail and current nightly. The other site from above (https://www.softballoutlet.com/) fails with sec_error_ocsp_invalid_signing_cert. Isn't this a shortcoming of the CAs OCSP responder?

In any case I believe the correct solution to be supporting CRLDP which is being worked on and fix the OCSP responder at the CA.
In reply to comment #75:
> I question the usefulness of such hacks due to the shortcomings of CAs.

Eddy, are you blaming NetSol for bug #479029?

If yes, then your logic would also be forced to conclude that StartCom were to
blame for bug #381317, and that Comodo were to blame for bug #419030.

No!
Eddy,
Network Solutions' own site works because
a) the EV certificate on it has no OCSP responder URL in it and
b) Firefox won't follow the CRLDP and currently ignores the fact that it can't
therefore check revocation status.

The problem with https://www.softballoutlet.com is NSS bug 479029 which has
been fixed but not released.
(In reply to comment #78)
> In reply to comment #75:
> > I question the usefulness of such hacks due to the shortcomings of CAs.
> 
> Eddy, are you blaming NetSol for bug #479029?

I'm not sure, https://www.interfimo.fr/ works for me on "rv:1.9.1b4pre  Gecko/20090311" but not https://www.softballoutlet.com/. But both sites fail now on a new profile. Strange.

> If yes, then your logic would also be forced to conclude that StartCom were to
> blame for bug #381317

I'm taking some blame for bug 381317, it was unexpected for NSS. ;-)
> I'm not sure, https://www.interfimo.fr/ works for me on "rv:1.9.1b4pre 
> Gecko/20090311" but not https://www.softballoutlet.com/. But both sites fail
> now on a new profile. Strange.

Without the fix for bug #479029, https://www.interfimo.fr only gives sec_error_ocsp_invalid_signing_cert when certain cross-certificate(s) have been cached by PSM.

Without the fix for bug #479029, https://www.softballoutlet.com *always* gives sec_error_ocsp_invalid_signing_cert, regardless of whether or not certain cross-certificate(s) have been cached by PSM.

With the fix for bug #479029, both sites work ok.
Comment on attachment 364297 [details] [diff] [review]
Patch NSS to use default OCSP Responders for EV certificate chains from Comodo and Network Solutions

I support this patch.  I also support just doing
this workaround in NSS so that all NSS users can
benefit from it without extra work, provided that
the myDefaultOCSPResponders array contains only
entries blessed by the CAs.
We are distracting from the purpose of this bug.

Site softballoutlet still confuses me, because despite the bug 479029 being fixed in NSS, I still don't get EV UI on softballoutlet with Firefox experimental trunk. I propose to move discussion around this specific site over to new bug 482996.
(In reply to comment #74)

> Nelson, are you really suggesting to NetSol that they continue to issue EV SSL
> Certificates that fail to give the EV UI in the current release of Firefox?

Yes, because those certs will not show EV in FF 3.1. 
When FF 3.1 comes out, it will quickly displace FF 3.0.x for a very high 
percentage of FF 3.0 users, but not 100%.  Are you willing to issue certs
taht will show as non-EV in all FF 3.1 browsers until the last users 
abandons FF 3.0.x?  That seems to be what is being suggested.  
I don't think that's a great idea.
> Yes, because those certs will not show EV in FF 3.1. 
Sorry, that wasn't clear.  The certs they propose to issue instead, the
ones which lack the revocation info, will not show EV in FF 3.1.
Nelson, I agree that NetSol issuing EV certs without OCSP URLs is a retrograde step and that, if Rob's patch is not accepted and assuming CRLDP processing remains incomplete, they will not get the EV UI in FF3.1.
But, on the other hand, if they do include the OCSP URL in the certificates they issue today then those certificates do not get the EV chrome (and do not even get the padlock) in today's FF3.0.x.
NetSol may well think that they are better off getting EV chrome today by removing the OCSP URL and taking their chances with FF3.1 because (as Charlie said) the majority of their issued certificates do not have OCSP URLs anyway.  
The certificates which you characterized as "the ones which lack the revocation info" are standards compliant and do include revocation info (CRLDP) as far as I can tell.

To put it another way, let's say you launch FF3.1 with no CRLDP processing and no default OCSP patch.  90%+ of Charlie's EV certificates won't get EV chrome.  That gives him a customer relationship nightmare in a few weeks/months time when FF 3.1 comes out.
Until he started adding OCSP URLs to his certs, he had 100% of his (correctly installed, unrevoked, unexpired, etc) EV certs getting EV chrome in FF3.0.x.
He can only make his certificates work (at least we guess they will work, there are no guarantees) in a yet-to-be-scheduled FF3.1 by breaking them in the current FF3.0.x.  You have him between a hard place and another hard place.
Sorry, but I think we need some simple clarification.
What's the point of the "drop OCSP extension" idea?

Certs that have both OCSP AIA and CRLDP extensions MUST made to work.

If you are aware of a bug that today causes such certs to be rejected, we must work very very hard to get this fixed immediately, with the highest priority.

No cert shall be rejected because it has multiple revocation sources.
Please don't drop revocation URLs.
Another note to this long thread: First see comment 1. In the same token I believe that such a fine CA like Network Solutions should have had an OCSP responder right from the start. And it behooves the #2 too as well, though I recognize that as a so-called legacy CA such things may take perhaps some more time.

I think Mozilla's shortcoming in all this is that they didn't insisted on an OCSP requirement at the CA/Browser forum - fully knowing that their software has no means of revocation checking back then without OCSP. There are some lessons to be learned here by all sides I think.

Besides that, I understand the CRLDP will be hopefully working in FF 3.5 (3.1 will become 3.5 I think) and the OCSP problem is correctable.
Please let's clarify what technical bug exactly causes you to consider dropping the OCSP extensions from your certs.

The only explanation I've noticed so far was example site https://www.softballoutlet.com/ which does not trigger EV UI.

I got some confusing test results using that site, see my comments in bug 482996.

Please clarify whether https://www.softballoutlet.com/ is the only reason, or whether there are additional reasons for dropping OCSP extensions from your certs.
Should this new comment answer my own questions for clarification correctly, please ignore my earlier questions for clarification.

I think I understand the dependencies better now...


Firefox 3.0.x currently uses NSS 3.12.2
Bug 479029 is not fixed in NSS 3.12.2
Bug 479029 is seen with NetSol's certs that point to OCSP.

The same is true for current Firefox 3.1 beta, 
because it currently uses the same NSS release.

In order to unlock NetSol,
we would need to deliver a newer NSS (with bug 479029 fixed) to both FF 3.0 and 3.1

Unfortunately, at this time, delivering a newer NSS is not possible.
It would break additional EV sites, because of bug 474606
(NSS >= 3.12.3 detecting lack of CRL, but lacking CRLDP fetching support).


In my personal opinion, it's reasonable for Firefox to deny including the updated NSS 3.12.3 at this time, because the side effect in behavior is not acceptable. It's reasonable to delay landing of NSS 3.12.3 until both CRL-require and CRL fetching are available.


On the other hand, we urgently need this small correctness fix that OCSP revocation checking work with the certs that NetSol uses (bug 479029).

This is a very unfortunate situation, we kind of shot ourselves in the foot.


I think this unusual situation (being blocked to go to a newer NSS) requires an unusual solution.

I performed tests.
I found that the patch contained in bug 479029 seems to be isolated from the other changes that happened after NSS 3.12.2.
In my tests I applied that patch to a Firefox 3.0.x build, and to a Firefox 3.1 beta build.
In  both tests, the patch applied cleanly, and it fixed the NetSol bug for site www.softballoutlet.com
With the patch applied on top, I got green EV.


I would like to propose that the NSS team makes an exception from its usual convenience rule, "never pick individual patches, only go forward to newer NSS snapshots".

I propose that a NSS 3.12.2.1 release gets produced, that is a combination of the NSS 3.12.2 release and bug 479029, and have it delivered ASAP into Firefox 3.0.8 and the next Firefox 3.1 beta release.


Assuming that www.softballoutlet.com and bug 479029 is the only reason for our recent side discussion in this bug, I propose that all related discussion gets moved over to bug 479029, including the discussion what strategy is best to potentially get that fix delivered earlier into FF 3.0 / 3.1 (e.g. using a NSS 3.12.2.1 release)


The discussion in this bug should remain focused on the potential plan to embed a list of CRLs in a Firefox release, whether it is necessary or not.
In reply to comment #82:
> (From update of attachment 364297 [details] [diff] [review])
> I support this patch.  I also support just doing this workaround in NSS so
> that all NSS users can benefit from it without extra work, provided that the
> myDefaultOCSPResponders array contains only entries blessed by the CAs.

Thanks Wan-Teh.  My patch certainly has the blessing of both Comodo and NetSol.

In reply to comment #90:
> The discussion in this bug should remain focused on the potential plan to
> embed a list of CRLs in a Firefox release, whether it is necessary or not.

Kai, I agree.

Let's move all further discussion on the idea of embedding default OCSP Responder URLs into NSS and/or PSM to Bug #483168, which I've just filed.
In reply to comment #88:
> Another note to this long thread: First see comment 1. In the same token I
> believe that such a fine CA like Network Solutions should have had an OCSP
> responder right from the start.

Eddy, please re-read comments #58 and #59.  "should have had" is unfair.  No applicable standard requires NetSol to use OCSP at all yet.

> And it behooves the #2 too as well

I think this comment is intended as a criticism of Comodo.  Again, this is entirely unfair.  No applicable standard requires us to use OCSP at all yet.  Nevertheless, we did roll out OCSP over a year ago and would have done so several months earlier if Bug #419030 had been fixed more quickly.
Rob, the intend of the EV guidelines makes it clear that OCSP is the prefer revocation checking method. The short period which still allows CAs not to operate OCSP responders was most likely accepted in order to allow for a smother transition, mostly for legacy CAs. So there is a standard which requires OCSP.

But you've introduced a responder a year ago which is good. It's not a criticism, but would you have introduced and made some testings earlier, some bugs might have been detected earlier too, allowing for more time to analyze such problems. You've been involved at the CAB Forum and you knew about its upcoming requirement even well before its approval. 

But this all isn't important right now for fixing this problem. I simply noted that lessons can be learned here by *all* sides. You may or may not agree with that.
> Rob, the intend of the EV guidelines makes it clear that OCSP is the prefer
> revocation checking method.

Post-2010, yes.  But we are not there yet.  CDP and OCSP are both equally valid until then!

In fact, it could be argued that CDP is the preferred revocation checking method until the end of 2010, since the EV Guidelines say:
"Subordinate CA Certificate...
cRLDistributionPoint MUST be present...
authorityInfoAccess SHOULD be present...
Subscriber Certificate...
cRLDistributionPoint SHOULD be present...
authorityInfoAccess SHOULD be present"

Read RFC 2119 if you don't see what I'm getting at.

> You've been involved at the CAB Forum and you knew about its upcoming
> requirement even well before its approval.

Yes.  Hence why we deployed our OCSP Responder 3 YEARS before the end-of-2010 deadline specified in the EV Guidelines!

NetSol have recently been attempting to roll out OCSP, almost 2 YEARS ahead of the end-of-2010 deadline.

It's possible that the other OCSP-less EV CAs haven't even started thinking about deploying OCSP yet.

Also, as I mentioned in comment #59, even post-2010 there is no absolute requirement to include OCSP Responder URL(s) in EV certificates.  The EV Guidelines only say that:
"CAs MUST support an OCSP capability for Subscriber Certificates that are
issued after Dec 31, 2010".
Comodo and NetSol already meet that requirement.  We both operate OCSP Responders that are capable of returning authoritative OCSP Responses for all the EV certificates we've issued, including those certificates that do not contain OCSP Responder URLs.  This is "an OCSP capability", IMHO.

> The short period which still allows CAs not to operate OCSP responders was 
> most likely accepted

Exactly!  It was accepted!

> in order to allow for a smother transition

Was that typo deliberate?  If FF 3.5 cannot show the EV UI for CDP-only EV certificates, the affected CAs will indeed feel smothered!

A "smoother" transition would of course require Mozilla to avoid this worst case scenario from occurring in the first place.

> So there is a standard which requires OCSP.

Sigh.  I said "No applicable standard requires us to use OCSP at all *YET*".  I did not say that there is no standard that requires us to use OCSP in the future.
In comment #63, Johnathan wrote:
> I agree.  If Nelson & Kai find Rob's patch acceptable technically, I will
> contact the other CAs to ask whether they would prefer this approach.  Without
> committing them to anything or speaking for them, I suspect that some, but not
> all, of the remaining 3 will be amenable to this approach.

Johnathan, please follow up on this at bug #483168 if/when Nelson and Kai give the nod.  Thanks.

Also, you might like to add Verizon/CyberTrust to your list of CDP-only EV CAs to talk to about both this bug and bug #483168.  They're not EV-enabled in PSM yet, but I see that https://wiki.mozilla.org/CA:Schedule has 3 of their Roots queued for public discussion soon (with the comment "EV, no OCSP").
Travel for a week and all kinds of crap happens!

Rob/Robin/Eddy - Thanks for all of your dedication to exploring the policy space here, but let's try to focus on the bugs we can solve in the short term. I don't think any CA wants to drop revocation mechanisms, and no browser wants them to do so, so let's take it as granted that it is better for all concerned to have proper revocation checking in place, and shelve the discussions about dropping such info - it slows us down on fixing things.

Kai - I agree that regardless of whether FF3.5 takes a new NSS tag, bug 479029 is important, and likewise important on the FF3.0 branch if indeed it is well-scoped.  We should probably open a separate bug to track that discussion, and add dveditz & sam sidler (and myself) to the cc list.  Did I miss, in all this bugmail, you opening that bug?

As for CRLDP conversations, that's over in bug 321755 and while I have hope that the recent activity on that bug, and the realization that limited CRLDP support can be implemented without solving the related CIDP issues, I think it behooves us to continue to look at alternatives in the meantime.  For at least two of the impacted CAs, that work is in bug 483168, so I'll go catch up on that bug next.
In reply to comment #15:
> I object to relaxing the revocation requirements

Nobody has yet answered Kaspar's objections to Kai's "Patch to relax requirements on intermediate certs".
https://wiki.mozilla.org/CA:EV_Revocation_Checking still has 3 ?s on the matter.

When will a decision be made?  It may well have implications for this bug and bug #483168.

Perhaps this discussion should be moved to bug #423665 or bug #155481, and then that bug marked as blocking this bug?
(In reply to comment #96)
> Travel for a week and all kinds of **** happens!

I know the feeling!  I was traveling during the end of February and begining of March and returned to find my newly issued EV Certs failing to display *any* SSL indicators at all in Firefox!  Unfortunately, Network Solutions has had to make the difficult decision to remove the OCSP URL from all newly issued EV Certs -- unfortunately it was the only option available to us to continue to receive EV treatment by Firefox.
(In reply to comment #59)
> Also, note that the EV Guidelines *NEVER* absolutely require the Authority Info
> Access extension to be present in an EV Certificate!
> 
> Even when a CA does operate an OCSP Responder, and even after 2010, EV
> Certificates are not required to include OCSP Responder URLs (as long as they
> do include a CRL Distribution Point URL)!
> 

From the EV Guidelines section 26:

It is strongly RECOMMENDED that all CAs support OCSP when a majority of
deployed Web servers support the TLS 1.0 extension in accordance to RFC 3546,
to return “stapled” OCSP responses to EV-enabled applications. CAs MUST
support an OCSP capability for Subscriber Certificates that are issued after Dec
31, 2010.

Your statement in comment 59 is wrong.
See bug #483168 comment #24 for my reply to comment #99.
Comment on attachment 364297 [details] [diff] [review]
Patch NSS to use default OCSP Responders for EV certificate chains from Comodo and Network Solutions

Moved to bug #485052.
Attachment #364297 - Attachment is obsolete: true
Depends on: 483168, 485052
No longer depends on: 418924
Can this bug now be marked as RESOLVED INVALID, given that 4 of the 5 affected CAs have now taken the Bug #485052 approach?
Yes. Though WONTFIX is more appropriate. The bug's not invalid, it just contemplates a behaviour change we have decided we don't want.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: