420760 - Enable existing Verisign, GeoTrust and thawte roots for EV

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Jay Schiavo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: 

EV-enable the existing Thawte, VeriSign, and GeoTrust roots, and associate the appropriate EV oids with them. Here is the necessary information:

VeriSign:
---------
Assign these all to VeriSign's EV OID: 2.16.840.1.113733.1.7.23.6 All the same CP/CPS/WebTrust info as in (https://bugzilla.mozilla.org/show_bug.cgi?id=402947) should apply to this as well

> VeriSign Class 3 Primary CA (aka PCA3 - G1)
Country = US
Organization = VeriSign, Inc.
Organizational Unit = Class 3 Public Primary Certification Authority
--
Serial Number: 70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf Operational Period: Mon Jan 29, 1996 to Tue Aug 01, 2028 Certificate SHA1 Fingerprint: 742c 3192 e607 e424 eb45 4954 2be1 bbc5 3e61 74e2 

> VeriSign Class 3 Primary CA - G2 (aka PCA3 - G2)
Country = US
Organization = VeriSign, Inc.
Organizational Unit = Class 3 Public Primary Certification Authority - G2 Organizational Unit = (c) 1998 VeriSign, Inc. - For authorized use only Organizational Unit = VeriSign Trust Network
--
Serial Number: 7d d9 fe 07 cf a8 1e b7 10 79 67 fb a7 89 34 c6 Operational Period: Mon May 18, 1998 to Tue August 01, 2028 Certificate SHA1 Fingerprint: 8537 1ca6 e550 143d ce28 0347 1bde 3a09 e8f8 770f 

> VeriSign Class 3 Primary CA - G3 (aka PCA3 - G3)
Country = US
Organization = VeriSign, Inc.
Organizational Unit = VeriSign Trust Network Organizational Unit = (c) 1999 VeriSign, Inc. - For authorized use only Common Name = VeriSign Class 3 Public Primary Certification Authority - G3
--
Serial Number: 00 9b 7e 06 49 a3 3e 62 b9 d5 ee 90 48 71 29 ef 57 Operational Period: Fri October 1, 1999 to Wed July 16, 2036 Certificate SHA1 Fingerprint: 132d 0d45 534b 6997 cdb2 d5c3 39e2 5576 609b 5cc6 


Thawte:
-------
Assign these all to Thawte's EV OID: 2.16.840.1.113733.1.7.48.1 All the same CP/CPS/WebTrust info as in (https://bugzilla.mozilla.org/show_bug.cgi?id=407163) should apply to this as well

> Thawte Premium Server CA
Country = ZA
State = Western Cape
Locality = Cape Town
Organization = Thawte Consulting cc
Organizational Unit = Certification Services Division Common Name = Thawte Premium Server CA Email = [e-mail]
--
Serial Number: 01
Operational Period: 7/31/1996 17:00:00 PM to 12/31/2020 15:59:59 PM Certificate SHA1 Fingerprint: 627f 8d78 2765 6399 d27d 7f90 44c9 feb3 f33e fa9a


GeoTrust:
---------
Assign these all to GeoTrust's EV OID: 1.3.6.1.4.1.14370.1.6 All the same CP/CPS/WebTrust info as in (https://bugzilla.mozilla.org/show_bug.cgi?id=407168) should apply to this as well

> Equifax Secure Certificate Authority
Organization:	Equifax
Country:		US
--
Serial Number:	35:DE:F4:CF
Validity Period:	Sat Aug 22, 1998 to Wed Aug 22, 2018 (GMT)
Certificate Fingerprint (MD5):	67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
Certificate Fingerprint (SHA-1):	D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jean-Marc Desperrier]

You should split this request in three, one per entity and explain why the audits that have already been done apply to all the CA.
If everything was the same, why would there be several CAs ?

Comment 2

[Frank Hecker]

Attachment: VeriSign Class 3 Primary CA (aka PCA3 - G1) certificate

Comment 3

[Frank Hecker]

Attachment: VeriSign Class 3 Primary CA - G2 (aka PCA3 - G2) certificate

Comment 4

[Frank Hecker]

Attachment: VeriSign Class 3 Primary CA - G3 (aka PCA3 - G3) certificate

Comment 5

[Kathleen Wilson]

Is this request still needed?

Comment 6

[Frank Hecker]

(In reply to comment #5)
> Is this request still needed?

I don't believe that this is actually needed, since the EV-specific roots for VeriSign, GeoTrust, and thawte have been EV-enabled, and to my knowledge EV certs issued by VeriSign, GeoTrust, and thawte are being recognized by Firefox et.al. without problems. I'm therefore resolving this bug as WONTFIX.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Frank, I'm reopening this request.  That's highly unusual for me; I don't
generally meddle in root CA decisions, but I think that perhaps there is
more information that warrants consideration for this bug.  This RFE contains 
no description of the motivation for the request, and so it was not apparent 
why this was requested, and no discussion of that motivation took place in this RFE.  Now, some reasons for that motivation have come to light.  I'd like you 
to consider them, and if you then make the same decision as before, I'll know 
that it was with done with consideration for this information.

Today, There is one Verisign root CA cert recognized in PSM as valid for EV,
and that is Verisign's "G5" root, which has a 2k bit RSA public key.  
It's absolutely true that this is entirely adequate for users of Mozilla 
browsers, whether on desktops or PDAs (Mozilla Mobile).  

But in Asia, there are many people whose only Internet connection and only browser is on a wireless device (commonly a mobile phone) that has a 
limitation making it unable to handle public keys (and their respective 
signatures) that are 2k bits in length.  This puts the owners of Asian web 
sites, who wish to reach users of those limited devices, as well as users
of more capable desktop computers, in a bind.  They wish to have a single 
web site (a single URL) that is accessible by BOTH the limited mobile 
devices and the more capable machines, and they want it to display EV UI 
on those more-capable machines that are capable of displaying EV UI.  

If they get an EV cert that chains up to a 2k bit root (or has any 2k bit
keys anywhere in the cert chain), they get nice EV UI with Mozilla, but 
it doesn't work AT ALL with the limited mobile devices.  They want an EV
cert that has only 1k bit keys throughout the cert chain.  They want this
to display EV on Mozilla and more capable browsers, and to just do basic 
SSL (without EV) on the less capable ones.  

Today, Verisign offers EV certs that have no 2k bit keys anywhere in the 
cert path for that Asian market.  Those certs chain up to their older roots.
I believe that is why they have asked that their older roots also be retroactively enabled for EV.  

Verisign is now selling those certs with 1k-bit chains in Asia.  Visits to sitse with those certs do NOT display EV UI in Firefox, because they chain 
up to root certs that are not approved as issuers for Verisign's EV policy 
OID.  That, in turn, means that there is an Asian market in which users will
see EV UI with certain other browsers, but not with Firefox.

Here are two example sites:
https://diskunion.net/
https://www.oisix.com/xxx

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

It has been observed that there is a way for a site to have BOTH 1k bit certs
that work with limited devices, and 2k bit certs that display EV UI with 
Firefox.  The technique requires having two (virtual) servers with two DNS
names and two certs.  The site owner puts the 1k cert on its www site, and 
advertises the www site.  The www server observes ("sniffs") the User-Agent
string in incoming https requests, and redirects them to a second server (e.g. www2) if the User Agent string shows that the client is capable of handling 
2k bit certs.  However, this scheme requires twice the servers and twice the 
certs, and (IMO) is not likely to be as widely accepted in Asia as a one-cert-fits-all solution.

Comment 9

[Eddy Nigg (StartCom)]

Nelson, I think one server can send a complete set of CA certificates chaining to different roots. When the certificate chains to the 2K root it would show the EV UI, in case the devices doesn't support keys of this size, it would choose most likely the path to the 1K root. Can you confirm this?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Eddy, each cert can only have one issuer name.  It would be possible to have
multiple issuer certs with the same name but different keys, chaining up 
to different roots. but it appears to me that Verisign didn't do that.

Taking the diskunion.net example, the EE cert is issued by 
          CN = VeriSign Class 3 Extended Validation 1024-bit SSL SGC CA
          OU = Terms of use at https://www.verisign.com/rpa (c)07
          OU = VeriSign Trust Network
           O = VeriSign, Inc.
           C = US
(notice the "1024-bit" in the CN string)  The issuer cert with that subject 
name chains to the old root root.

The EV intermediate CA that chains to their "G5" root has the name
          CN = VeriSign Class 3 Extended Validation SSL SGC CA
          OU = Terms of use at https://www.verisign.com/rpa (c)06
          OU = VeriSign Trust Network
           O = VeriSign, Inc.
           C = US
The differences between those certs include the CN and OU attributes.
So it would do Firefox users no good for the server admin to include 
both of those chains in the list of certs sent out by the server.

Now, perhaps Verisign could issue another CA cert from the old root, one 
with the "1024-bit" name and the same public key as the "1024-bit" cert.
Then server admins could use the trick you described.  But I don't know
if their CP/CPS would allow that.

Comment 11

[Eddy Nigg (StartCom)]

Thanks for the clarification. In any case I think it might need some more research in order to confirm your suggestion from comment 7. There might be also other considerations Frank took into account? I'm sure he'll tell us...

Comment 12

[Frank Hecker]

Nelson: My apologies for the delay in responding to this. I'm trying to catch up on CA stuff this week.

I knew that in general there could be issues with mobile devices and 2048-bit roots, but I mistakenly assumed that this would not be a problem in our context. I wasn't thinking of the scenario you've described.

I think it is indeed worth looking into this issue, and potentially reconsidering this request. I'll ask Jay and the other VeriSign folks about it, as before we do anything I want to get a formal request from them to proceed. (I've been in correspondence with them off and on regarding other things, but they haven't mentioned this issue recently.)

Also, I'd like to see if we really need to EV-enable legacy roots for all three of VeriSign, GeoTrust, or thawte, or if we could address the problem by just EV-enabling the VeriSign legacy root.

Comment 13

[Kathleen Wilson]

Based on an email exchange, VeriSign's preference is to EV-enable the SHA1 version of the PCA3-G1 root, which is being requested for inclusion in bug #490895.