493709 - Combined EV enablement

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Eddy Nigg (StartCom)]

This bug is a single address for enabling EV according to the following bugs:

bug 449394 (WellsSecure)
bug 477145 (SECOM Trust)
bug 490492 (StartCom)
bug 492077 (SwissSign)
bug 493259 (Cybertrust)
bug 493265 (DigiNotar)

Comment 1

[Eddy Nigg (StartCom)]

Attachment: Combined EV OID patch

Tested against URLs:

https://nerys.wellsfargo.com/
https://repo2.secomtrust.net/
https://cert.startcom.org/
https://testevg2.swisssign.net/
https://secure.ichotelsgroup.com/
https://www.polisdirect.nl/

(Latest doesn't show the EV UI, reason might be OCSP or CRL?)

Bob or Kai, please review and approve.

Comment 2

[Kai Engert [:KaiE:]]

Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

I verified that all fingerprints and all EV OIDs match the information in the respective 6 bugs, and that a reasonable OID name is used in the patch.

r=kaie

I trust that Eddy did correct testing and added the right encodings of subject/serials.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

a191=beltzner after it's had a green cycle on mozilla-central

Comment 4

[Eddy Nigg (StartCom)]

Mike, my wanted1.9.1 ? flag coincided with your approval above. Shall I remove it?

Comment 5

[Johnathan Nightingale [:johnath]]

Yeah, clearing that - this has approval once we get our ducks here, and in bug 494236 into a row.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I think the patch author may not have a CVS account, and so a checkin will
be needed by someone who does.  I hope it's not too late now.

Comment 7

[Kaspar]

For the sake of consistency, I would recommend to add new myTrustedEVInfos entries at the end (before the sample entry), rather than insert them before the existing ones.

Comment 8

[Johnathan Nightingale [:johnath]]

Landed on central along with bug 493660

http://hg.mozilla.org/mozilla-central/rev/0b821db9a67e

After baking on central for a cycle, I will land this with bug 493660's branch version.

Comment 9

[Johnathan Nightingale [:johnath]]

*that should read bug 494236, not bug 493660

Comment 10

[Johnathan Nightingale [:johnath]]

mozilla-central was clean (minus known oranges) - landed on mozilla-1.9.1

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/269ebc5616a1

Forgot the a=beltzner comment.  :(

Comment 11

[Onno Witvliet]

This isn't fixed in the latest 1.9.1 nightly: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090523 Shiretoko/3.5pre ID:20090523044232

Only 2 of the 6 URL's show the EV UI

Works:
https://nerys.wellsfargo.com/
https://cert.startcom.org/

Does not work
https://repo2.secomtrust.net/
https://testevg2.swisssign.net/
https://secure.ichotelsgroup.com/
https://www.polisdirect.nl/

All URL's work in the latest Minefield:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090523 Minefield/3.6a1pre ID:20090523042428

Comment 12

[Eddy Nigg (StartCom)]

One of the solutions for this behavior might be in bug 477244. CyberTrust and SecomTrust don't provide an OCSP URL (and working OCSP responder) including EE cert, the others don't provide and OCSP URL in the chain. Firefox doesn't fetch yet CRLs to all of my knowledge.

The EV UI works correctly with this patch and latest FF3 which has a different policy on revocation checking.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 11,
These behavioral differences are known and understood.  
We've intentionally chosen to delay the fix for some of them until after 
FF 3.5.0 is released.  They will probably be fixed in an early update 
fix for FF 3.5, e.g. FF 3.5.1 (or 3.5.0.1 :).

Comment 14

[Freddy Kaiser]

Hi,

what is not ok for the https://testevg2.swisssign.net ?

Initially we created ourself a patch in order to verify that all will be fine. That worked already with FF 3.0.4.:
diff -ru firefox-3.0.4/security/manager/ssl/src/nsIdentityChecking.cpp firefox-3.0.4-swisssign/security/manager/ssl/src/nsIdentityChecking.cpp
--- firefox-3.0.4/security/manager/ssl/src/nsIdentityChecking.cpp	2008-10-23 01:06:29.000000000 +0200
+++ firefox-3.0.4-swisssign/security/manager/ssl/src/nsIdentityChecking.cpp	2008-12-06 18:24:07.000000000 +0100
@@ -82,6 +82,16 @@
 
 static struct nsMyTrustedEVInfo myTrustedEVInfos[] = {
   {
+    // CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH
+    "2.16.756.1.89.1.2.1.1",
+    "SwissSign EV OID",
+    SEC_OID_UNKNOWN,
+    "D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61",
+    "MEUxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxHzAdBgNVBAMTFlN3aXNzU2lnbiBHb2xkIENBIC0gRzI=",
+    "ALtAHEP1Xk+w",
+    nsnull
+  },
+  {
     // CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
     "2.16.840.1.113733.1.7.23.6",
     "VeriSign EV OID",

What is making now the issue, especially that our Endcertificates have CRL and OCSP information in it?

Comment 15

[Eddy Nigg (StartCom)]

The specific issue with your CA is, that your intermediate CA which issues the EV certificates doesn't have an OCSP responder URI in the AIA extension of the certificate (not sure if an OCSP responder exists). In FF 3.5 (as opposed to FF 3.0.x) a different policy for revocation status checking is applied. Because Firefox currently can only check revocation status with OCSP responders, the status of the intermediate CA certificate is unknown and therefore refuses to show the EV UI.

Possible solution would be to issue an intermediate CA with OCSP URI in the AIA extension. At some point, a future version of NSS will apparently support also CRL fetching. Also, if this patch is going to be applied to the FF 3.0.x version, the EV UI will most likely show as well (due to the different policy). Hope this helps.

Comment 16

[Freddy Kaiser]

Ok I'll submit this internaly to create a new intermediate issuing CA with OCSP in it. In the meantime is it possible to add the fix also to the FF 3.0.x branch?

Comment 17

[Eddy Nigg (StartCom)]

I suppose that if and once bug 495033 is approved for checkin, we could apply this patch also to 1.9.0.12? I'll file a new bug for this.

Comment 18

[Freddy Kaiser]

Do you recommend to create new issuing CA and reissue all issued EV Certfificates in order to get the Green Bar with FF 3.5 or is there a quicker answer from your side in order to have FF 3.5 working lie FF 3.0?

Comment 19

[Eddy Nigg (StartCom)]

Filed bug 495044 for 1.9.0.x branch.

Comment 20

[Eddy Nigg (StartCom)]

FF 3.5 will not have the same policy as FF 3.0, but NSS is supposed to support CRL fetching at some point - and with it the EV UI should show again with your CA. Maybe Nelson can give some estimates when this potentially could be, as per comment 13. His answer could give you some indication if it's worth the effort to re-issue all EV certificate, but I'd recommend to issue a new EV issuer with an OCSP URI in the AIA extension and issue any new EV certificate from there (if that's possible for you).

Comment 21

[Freddy Kaiser]

Thanks for the infos - where will this be visible in Firefox 3.0? Update 11 or 12?

Comment 22

[Freddy Kaiser]

Hi we added the OCSP to our Issuing CA, could you just check and confirm that this will be fine now?
 https://testevg2.swisssign.net

Comment 23

[Eddy Nigg (StartCom)]

All green ;-)

Comment 24

[Kai Engert [:KaiE:]]

Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

It has been requested in bug 495044 to add this patch to Firefox 3.0.x, requesting approval for 1.9.0.x

Comment 25

[Samuel Sidler (old account; do not CC)]

Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

1.9.0.14 is frozen right now, so moving request to 1.9.0.15.

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 378295 [details] [diff] [review]
Combined EV OID patch

Approved for 1.9.0.15, a=dveditz for release-drivers

Comment 28

[Kai Engert [:KaiE:]]

fixed 1.9.0.15

Checking in nsIdentityChecking.cpp;
/cvsroot/mozilla/security/manager/ssl/src/nsIdentityChecking.cpp,v  <--  nsIdentityChecking.cpp
new revision: 1.26; previous revision: 1.25

Comment 29

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

(In reply to comment #1)
> Tested against URLs:
> 
> https://nerys.wellsfargo.com/
> https://repo2.secomtrust.net/
> https://cert.startcom.org/
> https://testevg2.swisssign.net/
> https://secure.ichotelsgroup.com/
> https://www.polisdirect.nl/

Looking at these in the 1.9.0.15pre build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15pre) Gecko/2009092205 GranParadiso/3.0.15pre (.NET CLR 3.5.30729), the following do not show the EV UI:

https://secure.ichotelsgroup.com/
https://repo2.secomtrust.net/

https://nerys.wellsfargo.com/ shows the EV UI but is a 404 page.

Is there a better way to test all of this for 1.9.0?

Comment 30

[Johnathan Nightingale [:johnath]]

(In reply to comment #29)
> Looking at these in the 1.9.0.15pre build (Mozilla/5.0 (Windows; U; Windows NT
> 5.1; en-US; rv:1.9.0.15pre) Gecko/2009092205 GranParadiso/3.0.15pre (.NET CLR
> 3.5.30729), the following do not show the EV UI:
> 
> https://secure.ichotelsgroup.com/
> https://repo2.secomtrust.net/

These two use CRLs for revocation information instead of OCSP, and 1.9.0 doesn't support CRLs. In the absence of revocation information, we downgrade from EV (green) to DV (blue), so these certs, despite their roots being "EV enabled" aren't going to show up as EV unless and until NSS 3.12.4 is backported to 1.9.0.