501866 - SecomTrust EVSSL fails to provide green UI in Firefox 3.5

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Gen Kanai [:gen]]

Bug 394419 and bug 477145 outline the work that was done to implement EV support for SecomTrust in NSS 3.12.3.

SecomTrust was testing through all of the RCs with no problems but once the 3.5 official build was released, the EV UI was gone and went back to the SSL UI (see attachment.)  

SecomTrust does not support OCSP at this time, which may be the issue. Tangentially related is the GlobalSign EV cert, which I am told also is the same situation: EV but not supporting OCSP.

Comment 1

[Gen Kanai [:gen]]

Attachment: SecomTrust EV UI failure

Comment 2

[Masatoshi Kimura [:emk]]

(In reply to comment #0)
> SecomTrust was testing through all of the RCs with no problems but once the 3.5
> official build was released, 
Really? RC3 binary is exactly the same as official release.

Comment 3

[Hisashi Kamo]

Dear Gen-san,
Thank you for file a new bug on this issue.

Dear memebrs on Bugzilla,
Unfortunately, we can not see the change color in Firefox3.5.

It seems that the specification is changed from Firefox3.0.11.
Because of this, we found GlobalSing's green address bar in ver3.0.11 before, however can not find green address bar in Firefox3.5.

In case if you still use the same specification in Firefox3.5 as ver3.0.11, I believe Secom's address bar is hopefully to change for green.

Could you please let me know the release schedule for Secom?

As you know, we tested the build below and it worked all right for Windows, Linux and MacOS.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 4

[Hisashi Kamo]

This is the critical issue.
We have big customers using our EV SSL.
Would you please let us know the target version or when this issue will get be resolved.

Comment 5

[Eddy Nigg (StartCom)]

Does SecomTrust have OCSP responders for the certificates in the chain?

Comment 6

[Gen Kanai [:gen]]

I do not believe SecomTrust supports OCSP at this time.

Comment 7

[Hisashi Kamo]

Gen-san is correct.
Based on the guideline, CRL DP is acceptable by the end of year 2010.
We are going to support OCSP by the deadline.
I believe Firefox3.0.11 supports CRL DP, that is why Globalsign worked properly despite of not supporting OCSP.

Comment 8

[Eddy Nigg (StartCom)]

The case is different. FF3 doesn't *enforce* revocation checking, however FF3.5 does. Now, since the CA doesn't operate an OCSP responder and Firefox doesn't know to fetch CRLs automatically yet, the UI can't treat the certificates as EV.

It's apparently planned in the future to support the fetching of CRLs and your CA apparently plans to operate an OCSP responder. Either of these actions most likely will be sufficient to display the EV UI.

I'm marking the bug as invalid because it depends on the actions outline above. Once your CA operates an OCSP responder, bug 483168 might be helpful for you in case CRL fetching isn't enabled by then.

Comment 9

[Masatoshi Kimura [:emk]]

(In reply to comment #8)
Then bug 474606 and bug 477244 should also be marked as INVALID, no? What's the difference?

Comment 10

[Eddy Nigg (StartCom)]

Bug 483168 was the solution for 477244 - I guess that bug 477244 can be resolved at some point. I think bug 474606 was resolved otherwise.

Some CAs operate OCSP responders, but don't have the OCSP URI embedded in the certificates, bug 483168 is a temporary solution for those CAs.

Comment 11

[Hisashi Kamo]

We checked Firefox3.6-alpre 02 July, 2009 at the URL below.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 

We found "green bar" for all of the environments such as Windows, Linux and MacOS.

Would you please let us know when this will be released?

Comment 12

[Gen Kanai [:gen]]

(In reply to comment #11)
> We checked Firefox3.6-alpre 02 July, 2009 at the URL below.
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 
> 
> We found "green bar" for all of the environments such as Windows, Linux and
> MacOS.
> 
> Would you please let us know when this will be released?

3.6 is the nightly build of trunk which will become the next major version.  We cannot expect this in 2009.

Comment 13

[Gen Kanai [:gen]]

Attachment: 20090702 Minefield 3.6a1pre

Comment 14

[Gen Kanai [:gen]]

Can someone please explain what makes 3.6a1pre provide the EV UI when 3.5 does not? 

SecomTrust was testing with the 3.5 betas and 3.5 RCs successfully and only after the final build was released did the UI fall back to SSL.  Can someone explain what the situation is here?  They were waiting patiently for the 3.5 release and need to have the EV UI for their customers who've bought EV certs.

Comment 15

[IIDA Yosiaki]

(In reply to comment #2)
> (In reply to comment #0)
> > SecomTrust was testing through all of the RCs with no problems but once the 3.5
> > official build was released, 
> Really? RC3 binary is exactly the same as official release.

I see there exist some confusing and/or misunderstanding.
I saw WHITE location bar with 3.5RC3 for Windows, while I saw no problems with the followings:
MD5                              TIMESTAMP           FILENAME
-------------------------------- ------------------- ----------------
cc554a7677302010ef5bdcf5a572e42f 2009-05-27Z01:22:13 firefox-3.6a1pre.en-US.linux-i686.tar.bz2
80e9211bfb7d3afbc145c39f179c3797 2009-05-27Z01:27:36 firefox-3.6a1pre.en-US.win32.installer.exe
The timestamp may not be correct.
It is very likely that above is newer than the real timestamp, by touching on download.

Comment 16

[Masatoshi Kimura [:emk]]

(In reply to comment #14)
> Can someone please explain what makes 3.6a1pre provide the EV UI when 3.5 does
> not? 
Because bug 490864 was landed only on the trunk. NSS 3.12.4.1 seems to include CRL DP support. I don't think it can be landed on stable branch.
> SecomTrust was testing with the 3.5 betas and 3.5 RCs successfully and only
> after the final build was released did the UI fall back to SSL.
Why do you ignore my comment #2? There is NO difference between
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5rc3/win32/ja/Firefox%20Setup%203.5%20RC%203.exe
and
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/ja/Firefox%20Setup%203.5.exe
AT ALL. Moreover, I saw DV SSL UI using 3.5 RC3 which is supposed to be the same as release (and actually is the same), so I didn't update.

(In reply to comment #15)
> I saw WHITE location bar with 3.5RC3 for Windows, 
Location bar is always white since Firefox 3.0 (not 3.5). Do you mean to say "WHITE favicon background"? I saw WHITE location bar and BLUE favicon background with effective TLD (that is, the cert is recognized as DV) using 3.5RC3 for Windows.

Comment 17

[Eddy Nigg (StartCom)]

Firefox 3.5 RC and some beta builds didn't change in respect to revocation checking. Are you saying you saw the green EV UI with FF3.5 and now you don't?

In any case the bug is not valid per se, because the current behavior is intentional when the status of the certificates can not be performed.

Comment 18

[IIDA Yosiaki]

(In reply to comment #17)
> In any case the bug is not valid per se, because the current behavior is
> intentional when the status of the certificates can not be performed.

Do you mean that FF3.5 intentionally does *enforce* revocation checking, instead of being enforcable?
I see that this case started on EV, but this enforceness affects to all of the  SSL/TLS sites even non-EV, which are almost all of them.
I do not want to insist on sites with certification issued from SECOM, but I want to insist on all the sites with certification issued from CA which does NOT provide OCSP.

Comment 19

[Eddy Nigg (StartCom)]

Yes, FF 3.5 enforces revocation checking for EV. If there are certificates in the path about which no revocation status exists, the EV UI will not show. As indicated previously, FF 3.5 has no means to check via CRL at the moment, OCSP is the only option (minor updates to Firefox like 3.5.1 or similar might start to support CRLs though).

This doesn't effect regular SSL certificates (even though revocation checking is done in the same way), it only degrades EV to regular SSL.

Does this help? Can we close the bug?

Comment 20

[Hiro]

(In reply to comment #8)

Hi, Eddy
I am supprized and what do you mean your comment?

I checked FF 3.0.11, 3.5, 3.6a1pre(Minefield) for revocation check
functionality.

3.0.11: not get CRL in CRLDP(no check revocation)
3.5: not get CRL in CRLDP(no check revocation)
     but access OCSP responder(check revocation)
3.6a1pre: get CRL in CRLDP(check revocation)
     and access OCSP responder(check revocation)

I think you mistook support revocation release check timing for revocation
check functionality.
You supported partial revicatin check only OCSP at release 3.5. It occuers
ctirical problems for some EV-CA venders(like GlobalSign) without OCSP
Responder. Before 3.0.11, their EV-sites changed green bar, but 3.5 is not.
It seems that their customers are in trouble.  

Since 3.6a1pre supports fullCRL and OCSP for revocation check, I think you
should maybe *enforce* revocation checking at 3.6.
And at next release version of 3.5, you should maybe support getting fullCRL
automaticaly or stop enforcement like 3.0.11.

What do you think my comment?

Comment 21

[Eddy Nigg (StartCom)]

It's not me, it's the responsible people which made those decisions. I'm just telling you what I already know. To recap, 

Firefox 3.0.x did not enforce revocation checking as a requirement to show the EV UI; 

Firefox 3.5 does enforce revocation checking, but RIGHT NOW can do so only via OCSP;

Firefox 3.6 is an pre alpha nightly release which has already support for CRLs;

As indicated, a future updated version of Firefox 3.5.x might support CRLs as well. Hope this helps.

Comment 22

[Masatoshi Kimura [:emk]]

I've also tested 3.1b1, 3.1b2, 3.1b3, 3.5b4, 3.5b99, 3.5rc1, and 3.5rc. None of them displays the EV UI, although latest Miefield does.
I strongly doubt SecomTrust did the test correctly.
Also, IIDA-san says 
> I saw WHITE location bar with 3.5RC3 for Windows, 
Which is correct?

Comment 23

[Masatoshi Kimura [:emk]]

(In reply to comment #19)
> (minor updates to Firefox like 3.5.1 or similar might start
> to support CRLs though).
If so,
> Does this help? Can we close the bug?
I don't understand why are you in such a hurry. I think this should remain open this bug until Fx 3.5.x supports CRL DP or until 31 Dec. 2010.

Comment 24

[Eddy Nigg (StartCom)]

Because this is not a bug, this is intentional by design, expected behavior and the implications are well known. There are other bugs which track CRL support. There are bugs which track default OCSP responders for CAs which have them.

But you can leave the bug open if you think this helps anything.

Comment 25

[Johnathan Nightingale [:johnath]]

I'm sorry I didn't find this bug sooner - I wasn't CC'd so I only got it through the less direct "johnathan follows lots of bugs" system.

Much of what is said above is correct, but I will recap in the interests of clarity and completeness.

Background: 

Firefox (via NSS, it's crypto library) has not historically had the ability to automatically fetch CRLs using the CRLDP fields of a certificate. Historically, the methods for doing so were covered by patents. In the second half of last year, we received a sufficiently broad license to implement this support, and the NSS team began working to that end.  That support was implemented too late to be included in Firefox 3.5, although it is already on our central development branch (aka Firefox 3.6a1).

EV Behaviour Change:

In Firefox 3, we would check OCSP revocation information, and downgrade from EV to regular SSL indicators if we didn't get a satisfactory response.  But CRL-based certificates implicitly passed that check, since there was no OCSP responder. Obviously, EV is a high level of validation, and revocation information is an important part of that. So in Firefox 3.5 we decided to enforce mandatory revocation checking for EV certs. This is a problem for CRL-based issuers, though, since we still lacked the ability to fetch those revocation lists - since we cannot, they do not have a successful revocation check, and hence are not treated as EV.

Let me be clear here: at no point in the 3.5 development cycle has CRL-fetching been supported.  At no time since the requirement for revocation was put in place (circa Jan 2009) have CRL-only CAs gotten EV treatment in the 3.5 browser. In 3.0, yes, because the revocation rules were more lenient.  In 3.6, yes (since April, anyhow) because that development branch already includes the new CRLDP support for checking CRLs. It is certainly not the case that any late beta or RC of Firefox 3.5 should have shown EV indicators in that case, though, nor can I confirm that behaviour in my own testing.

Going Forward:

There are a few options here. A couple of CAs have said that they have OCSP responders online, but they do not wish to re-issue their existing certificates to deal with this limitation. To that end, we have implemented support for associating issuers with a "default OCSP responder" in bug 485052. This allows a CA to say "For my certificates that don't otherwise specify an OCSP responder, please use this one." That helps them bridge the gap until their existing certificate base has expired and all their active certs have OCSP responders specified.

The second option is to wait for CRLDP support to be landed in a 3.5.x point release. Our hope is to get support for CRL fetching into the browser within the first couple point releases (e.g. 3.5.1 or 3.5.2). Once support is landed for checking CRLs as well as OCSP, EV certificates which specify a CRL should get EV treatment (assuming that the revocation check succeeds, of course).

I appreciate that this is not a pleasant situation - it's why we've included things like "default OCSP responder" support. But I expect that everyone here would agree that the integrity of EV certificates is important, and that it's not really appropriate for us to continue to treat as EV certificates whose validity we can't (albeit for our own technical limitations at the moment) verify.

If SECOM wants to produce a patch to add a default OCSP responder (as Globalsign has done in bug 497172, for instance) we can use this bug to track that work.  If SECOM wishes to wait for CRLDP support to be landed in the 3.5 product, this bug can be closed since it tracks no additional work.

Comment 26

[Masatoshi Kimura [:emk]]

(In reply to comment #24)
> Because this is not a bug, this is intentional by design, expected behavior and
> the implications are well known.
Do you say that CRL DP support will cause an unintentional, unexcpected behavior?
If you dislike to call this a bug, feel free to change the severity to "enhancement".
> There are other bugs which track CRL support.
Ok, I agree to close this bug as a duplicate of that (rather than invalid) if SECOM has no plan to provide a default OCSP responder.

Comment 27

[Hisashi Kamo]

Everyone, thank you for the comments on this bug.
Let us wait you to release CRLDP support, the second option Johathan-san described.
We urge you to release at the first couple point releases (e.g. 3.5.1 or 3.5.2). 
It is all right you close this bug.
However, before closing this, please let us know your release schdule.
Unless it will be clarified, we just lose a method to contact you on this.
We are so depressed for losing business opportunities because of 3.5, and actually, all of our big customers are waiting and some of them have a terrible upset.
Please Johnathan-san, decide to release CRLDP support at 3.5.1.
Thanks again for your concern.

Comment 28

[IIDA Yosiaki]

I would like to add one more comment from the viewpoint of general security issue of freely redistributable web browsers, not on behalf of interest for SECOM.

I think we can agree that all the Firefox should support CRL checking.
There are couple of reasons:
 1. IE has already supported it.  Early versions of IE defaulted not to check CRL, but eager users could enable this feature.
 2. Some of the later versions of IE enable it, by default.
 3. All---or at least almost all---of CAs approved by WebTrust support full CRL, while some "WebTrust"ed CAs still have no support for OCSP.
 4. There should be lots of CAs, which do not issue EV, which do not support OCSP, but which publishes full CRL, after all the EV certifications have OCSP information.

IMHO, *enforce*ment of revocation checking by only OCSP in Firefox 3.5 is a kind of misfeature, like "flying" of swimming race.  I agree that OCSP checking in general is a good idea, but because OCSP and CRL checking complements each other, even if it supported no CRL checking at all, it could check OCSP optionally, not mandatory, just like early versions of IE did it on CRL.

Comment 29

[Kai Engert (:KaiE:)]

Using the latest nightly development snapshot I get green on test site
https://ev1st.secomtrust.net/secom/ssl.html

Resolving bug

Comment 30

[Gen Kanai [:gen]]

Can we wait until the build with this support is out to users before resolving the bug?

Comment 31

[Masatoshi Kimura [:emk]]

Bugzilla is not a release tracker.

Comment 32

[Daniel Veditz [:dveditz]]

status1.9.1.4-fixed means it will appear in Firefox 3.5.4, to be released mid-to-late October.

Comment 33

[Al Billings [:abillings - ex-MoCo]]

Verified fixed for 1.9.1 in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090930 Shiretoko/3.5.4pre on https://ev1st.secomtrust.net/secom/ssl.html.