720326 - Add SHA-256 EC-ACC root certificate and Enable EV

Status: RESOLVED WONTFIX

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

Description

[Manel Rella]

Now that the recognition of standard SSL certificates from CATCert is already scheduled we would like to begin with the EV recognition, so as first step we answer the main questions: 
 
1) URLs and section numbers of the CP/CPS documentation regarding verification of organization identity and domain name ownership/control for EV certs.

The main verification controls are the same as for the standard SSL certificates, explained at https://bugzilla.mozilla.org/show_bug.cgi?id=295474#c73 

In addition the issuance of EV certificates is centralized and restricted only to the central office of CATCert, and it is done by internal and expert personnel that verify all the documentation. This documentation is also a bit more complex, especially for our “high level” EV certificates, in which we make our clients to generate the keys and store the EV certificates in a verified and registered HSM.

At the public catalog of certificates: http://catcert.cat/descarrega/tarifes.pdf  

On page 9 it is said:
 
“** Degut als estrictes requisits de seguretat aquest certificats només podran ser sol•licitats a   l’Entitat de Registre de  CATCert ... ”
 
That translated means:

“** Due to the high security requirements this kind of certificates can be only be requested to the registry entity of CATCert ...”
 
Summing up: the existence of the server and property of the domain is tested with the help of whois database. The existence of the organization to be certificated is also very well known, because they are public administrations with public creation statements. The identification of the rols of persons that can request EV SSL certificates to CATCert is also well known using the clients database, and the authentication of theses requestors is done with their personal certificates (stored in a cryptographic smartcard).  In the case of our “high level” EV certificates there is also the verification of configuration of the HSM that will store it: model, serial number, secure authentication protocol, secure keys creation protocol etc.       
 
 
2) EV Policy OID(s)
 
There are three extended validation profiles of certificates (these kind of certificates are also directly associated with the specials controls defined by spanish law 11/2011,  for offering electronic secure public services for citizens).  The only certification authorities that are habilitated for issuing EV certificates are: EC-AL, EC-SAFP, EC-UR, EC-PARLAMENT and EC-URV, for all these certification authorities the OIDs of the EV certificates are the same:
 
-	CDS-1 Seu electrònica nivell mig EV – Certificat de dispositiu servidor segur, seu electrònica nivell mig Extended Validation  (Certificate for secure server for an electronic place of a public administration, middle level, extended validation) 
      o	OID: 1.3.6.1.4.1.15096.1.3.1.51.2
 
-	CDS-1 Seu electrònica nivell alt EV – Certificat de dispositiu servidor segur, seu electrònica nivell alt Extended Validation (Certificate for secure server for an electronic place of a public administration, high level, extended validation) the difference with the former is that these is issued only for certificates stored securely in an audited HSM. 
      o	OID: 1.3.6.1.4.1.15096.1.3.1.51.3
 
-	CDS-1 EV- Certificat de dispositiu servidor segur Extended Validation (Certificate for secure server extended validation). This is an EV certificate, but has not the implications defined in the 11/2007 law.
      o	OID: 1.3.6.1.4.1.15096.1.3.1.51.4
 
If you need you can find the definition of the OID in the CPS of each certification authority:
 
-	EC-AL  http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-DPC-EC-AL_v3r7_cat.pdf   (at the end of page 19).
 
-	EC-UR  http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-DPC-EC-UR_v5r5_cat.pdf    (at the end of page 19).
 
-	EC-SAFP   http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-DPC-EC-SAFP_v3r7_cat.pdf   (at the end of page 19).
 
-	EC-PARLAMENT   http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-DPC_EC-Parlament_v1r6_cat.pdf   (at the end of page 19).
 
-	EC-URV   http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-DPC-EC-URV_v3r5_cat.pdf  (at the end of page 19).
 
 
3) URL to a website whose EV SSL cert chains up to this root (may be a test site).

We have three test URLs, one for each EV profile: 

CDS-EV:                    https://test_ev_cds.catcert.cat 
SEU-E NIVELL MIG:          https://test_ev_seu_mig.catcert.cat  
SEU-E NIVELL ALT:          https://test_ev_seu_alt.catcert.cat 
 
In this case these test certificates are issued by the EC-SAFP authority.
 
 
         4) EV Audit statement:

Here is the URL of the EV audit statement:  https://cert.webtrust.org/ViewSeal?id=1189
 
 
        5) Updated CA Hierarchy info (e.g. differences from what is described in the attached Information Gathering Document).

The Hierarchy is the same that the explained for the basic recognition, this is: https://bugzilla.mozilla.org/show_bug.cgi?id=295474#c16 but the only authorities that are allowed to issue EV certificates are:  EC-AL, EC-SAFP,   EC-UR, EC-PARLAMENT and EC-URV.
 
Thank you

Comment 1

[Kathleen Wilson]

I have been thinking about this request, because I am concerned about enabling EV for the old root certificate, which has several issues that were noted during the discussion.

Since you are planning to create a new root certificate that will address the concerns that were raised, I would like to propose that the EV-enablement be for the new root certificate only.

According to my notes, the new root certificate and hierarchy will address the following:
- Non-negative serial number
- Restrict OIDs generated by sub-CAs
- Use UTF-8 string, not T61 
- The authority key ID will not include both the key ID and the issuer's issuer name and serial number
- Comply with 3166 ISO 2-letter country code format

When you create the new root certificate and hierarchy, please also take into account the CA/Browser Forum Baseline Requirements (http://www.cabforum.org/).

Comment 2

[Manel Rella]

Hi, we have already addressed the problem with the EV OIDs, taking advantage to adapt our hierarchy to RFC5280.

More in detail we have "cloned" all our hierarchy, and we have:

- Applied the “anypolicy” to the policy constraints

- Maintained the same private and public keys RSA2048 for all the CA certificates (root and intermediate CAs)to allow validation of final certificates with the two hierarchies at the same time.

- Maintained the same distinguished names for all the CA certificates (root and intermediate CAs)

- Applied the SHA-256 algorithm for all the CA certificates (root and intermediate CAs)

- Simplified the Authority Key Identifier in order to have only the keyID

- Changed some codifications to UTF8

- Changed the serial numbers of the CA certificates assuring they are positive integers

So we have now two valid and equivalent hierarchies, the one with SHA-1 and the new with SHA-256, these are the SHA-256 certificates:

http://www.catcert.cat/descarrega/acc_sha2.crt
http://www.catcert.cat/descarrega/gencat_sha2.crt
http://www.catcert.cat/descarrega/safp_sha2.crt
http://www.catcert.cat/descarrega/al_sha2.crt
http://www.catcert.cat/descarrega/idcat_sha2.crt
http://www.catcert.cat/descarrega/parlament_sha2.crt
http://www.catcert.cat/descarrega/ur_sha2.crt
http://www.catcert.cat/descarrega/urv_sha2.crt

This means that we need to include to your database the new root “EC-ACC” with SHA-256 algorithm to continue with the Firefox EV recognition.

In other hand we have made an actualization of the Extended Validation test URLs, so they now make the push of the intermediate SHA-256 CA certificates:

https://test_ev_cds.catcert.cat
https://test_ev_seu_mig.catcert.cat
https://test_ev_seu_alt.catcert.cat

Do you think it will a problem with EV validation if the two equivalent roots "EC-ACC" with SHA-1 and "EC-ACC" with SHA-2 are charged at the same time, is possible to set the priority of validation to the new "EC-ACC SHA2" for the EV certificates?

Thank you

Comment 3

[Kathleen Wilson]

(In reply to Manel Rella from comment #2)
> In other hand we have made an actualization of the Extended Validation test
> URLs, so they now make the push of the intermediate SHA-256 CA certificates:
> 
> https://test_ev_cds.catcert.cat
> https://test_ev_seu_mig.catcert.cat
> https://test_ev_seu_alt.catcert.cat

The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.

Certificate authorities MUST advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates.


> 
> Do you think it will a problem with EV validation if the two equivalent
> roots "EC-ACC" with SHA-1 and "EC-ACC" with SHA-2 are charged at the same
> time, is possible to set the priority of validation to the new "EC-ACC SHA2"
> for the EV certificates?
> 

I don't understand the questions.

Are you requesting that EV be enabled for both the SHA-1 root and for the new SHA-256 root?

Comment 4

[Manel Rella]

(In reply to Kathleen Wilson from comment #3)
> (In reply to Manel Rella from comment #2)
> > In other hand we have made an actualization of the Extended Validation test
> > URLs, so they now make the push of the intermediate SHA-256 CA certificates:
> > 
> > https://test_ev_cds.catcert.cat
> > https://test_ev_seu_mig.catcert.cat
> > https://test_ev_seu_alt.catcert.cat
> 
> The certificate is not trusted because no issuer chain was provided.
> (Error code: sec_error_unknown_issuer)
> 
> Intermediate CA certificates are expected to be distributed to the
> certificate subjects (the holders of the private keys) together with the
> subjects' own certificates. Those subject parties (e.g. SSL servers) are
> then expected to send out the intermediate CA certificates together with
> their own certificates whenever they are asked to send out their
> certificates. That is required by SSL/TLS.
> 
> Certificate authorities MUST advise their subscribers that all intermediate
> certificates should be installed in the servers containing the dependent
> subscriber certificates.
> 
> 


In fact the SSL Server is sending the intermediate SHA-2 certificates, you can test it with the command:  

openssl s_client -connect test_ev_cds.catcert.cat:443 -showcerts 

But we think that the problem is not (or not only) the server configuration because we have tried also to import directly the EC-ACC SHA-2, EC-Gencat SHA-2 and EC-SAFP SHA-2 at the authorities tab, and one SSL EV certificate at the servers tab, and the SHA-2 certificate chain is not build correctly for that EV certificate.

We have tried in other systems and navigators and the SHA-2 certificate chain is build, so we don't know if this is a problem with the certificate codification or a problem with de validation protocol of Firefox, would it be possible to get some logs of the validation done with firefox?, please for doing this validation take the certificates in this URL because they are the last profile version:

http://www.catcert.cat/content/download/6700/16189/file/EV_certificate.zip


> > 
> > Do you think it will a problem with EV validation if the two equivalent
> > roots "EC-ACC" with SHA-1 and "EC-ACC" with SHA-2 are charged at the same
> > time, is possible to set the priority of validation to the new "EC-ACC SHA2"
> > for the EV certificates?
> > 
> 
> I don't understand the questions.
> 
> Are you requesting that EV be enabled for both the SHA-1 root and for the
> new SHA-256 root?


Well, the fact is that our final SSL EV certificate in theory can technically be validated at the same time with the SHA-1 or the SHA-2 root (because the private keys have no changed in the clonation of the hierarchy), and our doubt is what happens if the two roots are charged and only the SHA-2 is enabled for EV? the EV certificates will be validated first with the SHA-2 root (green bar OK) o with the SHA-1 one (green bar KO)?  

We were not asking for enabling EV also to the SHA-1 root, but maybe if the two roots are enabled for EV there will be no problems with the branch used to validate the EV certificates.

Comment 5

[Kathleen Wilson]

(In reply to Manel Rella from comment #4)
> (In reply to Kathleen Wilson from comment #3)
> > (In reply to Manel Rella from comment #2)
> > > In other hand we have made an actualization of the Extended Validation test
> > > URLs, so they now make the push of the intermediate SHA-256 CA certificates:
> > > 
> > > https://test_ev_cds.catcert.cat
> > > https://test_ev_seu_mig.catcert.cat
> > > https://test_ev_seu_alt.catcert.cat
> > 
> > The certificate is not trusted because no issuer chain was provided.
> > (Error code: sec_error_unknown_issuer)
> > 
> > Intermediate CA certificates are expected to be distributed to the
> > certificate subjects (the holders of the private keys) together with the
> > subjects' own certificates. Those subject parties (e.g. SSL servers) are
> > then expected to send out the intermediate CA certificates together with
> > their own certificates whenever they are asked to send out their
> > certificates. That is required by SSL/TLS.
> > 
> > Certificate authorities MUST advise their subscribers that all intermediate
> > certificates should be installed in the servers containing the dependent
> > subscriber certificates.
> > 
> > 
> 
> 
> In fact the SSL Server is sending the intermediate SHA-2 certificates, you
> can test it with the command:  
> 
> openssl s_client -connect test_ev_cds.catcert.cat:443 -showcerts 
> 


Please try re-setting your cert8.db as described here:
https://wiki.mozilla.org/CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings

I allowed the security exception so that I could browse to the website, then viewed the certificate, and no chain is displayed (as normally would be). To do this: click on the blue bar, then "More Information", then "View Certificate", then "Details". Normally the intermediate and root certs would also be listed. I also checked the Certificate Manager, and saw that no intermediates were loaded. Therefore, I must conclude that the webserver is not offering up the intermediate. 

You may have tried on other systems, but you may also have already imported the intermediate into them. You need to test by re-setting the cert8.db first, so that you can truly see if the intermediate is being offered up by the webserver.

Comment 6

[Kathleen Wilson]

PS: After re-setting my cert8.db I imported the SHA-256 EC-ACC root, and turned on the websites trust bit.

Comment 7

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 8

[Manel Rella]

By now we have filed a new bug about the problem of building the certification chain we have detected, because this can improve the interoperability of the NSS: 

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

Comment 9

[Kathleen Wilson]

(In reply to Manel Rella from comment #8)
> By now we have filed a new bug about the problem of building the
> certification chain we have detected, because this can improve the
> interoperability of the NSS: 
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=755227

I marked that bug as a duplicate of #386871 (which has been open since 2007).

See https://bugzilla.mozilla.org/show_bug.cgi?id=755227#c3
and https://bugzilla.mozilla.org/show_bug.cgi?id=398153#c3

Based on this, my recommendation is to re-issue so that the intermediate and end-entity certs have the same encodings.

Comment 10

[Kathleen Wilson]

Audit: https://cert.webtrust.org/ViewSeal?id=1417
EV Audit: https://cert.webtrust.org/ViewSeal?id=1418

Comment 11

[Aaron Wu]

There's no update from CA for more than 1.5 year. Closing this bug for now as Won't fix.
If CA ever provide further information, this bug will be re-opened.