295474 - Add CATCert root CA certificate (Spain)

Status: RESOLVED FIXED

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

Description

[Francesc Ferrer]

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

We are the Catalan Agency of Certification (Agència Catalana de Certificació or 
CATCert). Our aim is to provide digital certification services and promote the 
usage of digital signature in order to make safer the communications within the 
Catalan government and the communications (within and for) the Catalan 
government.

Reproducible: Always

Comment 1

[Francesc Ferrer]

Attachment: The request letter

The request letter with the explanation about how CATCert fulfills the
requirements stablished on the Mozilla CA Certificate Policy.

Comment 2

[Francesc Ferrer]

Attachment: English version of CATCert's CPS

Comment 3

[Francesc Ferrer]

Attachment: The .crt files with the certificates of every CA from CATCert

Comment 4

[Francesc Ferrer]

Attachment: Latest version of CATCert's CPS (in catalan)

Comment 5

[Francesc Ferrer]

Attachment: CATCert's Policy Statement

Comment 6

[Francesc Ferrer]

Attachment: Audits' comments

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request. :)

Comment 8

[Francesc Ferrer]

Dear Sir, do you have any schedule for the bug to get fixed, i.e., or CA certificates to be included on your products?. We haven't had activity related to this issue since 2005 as you can see on this webpage meanwhile other colleagues from other spanish CAs do have had activity and even resolved their cases. We would gladly like to hear from you soon. 

Comment 9

[Gervase Markham [:gerv]]

As you may know, the mozilla.org CA certificate policy:
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
states: "We require that all CAs whose certificates are distributed with our software products provide some service relevant to typical users of our software products."

Both bug 295474 and bug 342503 are on hold, pending the formulation of a policy on whether certificate authorities who deal with a constituency smaller than a country meet this requirement. Without limitation, possible resolutions include shipping the roots to everyone, shipping them only in a subset of builds, and deciding not to ship them at all.

I will post in this bug again when we've decided what to do. Thank you for your patience.

Gerv

Comment 10

[Toni Hermoso Pulido]

Dear Gervase,
I will find some time to read these documents as well. 
However, as the main Catalan localizer, who is also well aware of Mozilla products usage in his territory, the inclusion of this feature will be highly desirable and would also be useful to extend Mozilla products usage in local and regional administrations. 
Best regards,

Comment 11

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 12

[Luca Olivetti]

Maybe this is a new development, but since cacert, through the idcat initiative, is distributing certificates free of charge to any citizen that request them, and these certificates are accepted by various national agencies and can be used for encrypting and signing emails, I think this is a valuable service.
On top of that they distribute the certificate with an usb memory stick in a specially encrypted partition and provide a pkcs11 module both for firefox and thunderbird (though it crashes thunderbird here, but that's another matter).

Comment 13

[Luca Olivetti]

in my previous comment s/cacert/catcert/

Comment 14

[Gervase Markham [:gerv]]

We have decided that applications from sub-country governmental organisations will be considered after all the others have been processed.

Please could you provide data about your CA and certificates in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again.

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, 
                   academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy, 
   i.e. what you plan to do with the root
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity/organisationally-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):
URL of website using certificate chained to this root (if applying for SSL):

Thanks for your help in this matter. :-)

Gerv

Comment 15

[Gervase Markham [:gerv]]

Information has not been provided - resolving INCOMPLETE.

Gerv

Comment 16

[Francesc Ferrer]

CA Details
--------------

CA Name: EC-ACC

Website: www.catcert.net

One Paragraph Summary of CA, including the following:
- General nature (e.g., commercial, government, academic/research, nonprofit)

The Catalan Agency of Certification (Agència Catalana de Certificació - CATCert) is providing digital certification services and promoting the usage of digital signature in order to make safer the communications within and for the Catalan government.

- Primary geographical area(s) served

The Region of the Autonomic Community of Catalunya. 

- Number and type of subordinate CAs

Seven subordinate CAs, six of them issuing end entity certificates. 

Audit Type (WebTrust, ETSI etc.): Web Trust CA, ETSI TS 101 456

Auditor: Ernst &Young

Auditor Website: www.ey.com/es

Audit Document URL(s): El document de la ETSI i el document de la WEB Trust

WEB TRUST: https://cert.webtrust.org/SealFile?seal=466&file=pdf 
ETSI TS 101 456: http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101456v010101p.pdf
(Policy requirements for certification authorities issuing qualified certificates)
 

Certificate Details
-------------------

Certificate Name: EC-GENCAT

Summary Paragraph, including the following:

EC-GENCAT is providing digital certification services and promoting the usage of digital signature in order to make safer the communications within and for the Regional Catalan government.

Certificate HTTP URL (on CA website):
http://www.catcert.net/descarrega/gencat.crt

Version: V3

SHA1 Fingerprint: f0 b7 5b b7 93 11 b0 e5 d0 10 f1 ed 8d c7 e5 8f 15 be 68 fd

Modulus Length (a.k.a. "key length"):	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2003-01-08
Valid To (YYYY-MM-DD): 2027-01-08

CRL HTTP URL: 	
http://epscd.catcert.net/crl/ec-acc.crl
http://epscd2.catcert.net/crl/ec-acc.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV): 
Organisationally validated

Certificate Policy URL: 

EC-AL  http://www.catcert.net/descarrega/doc_legal/EC-AL_pdc_general.pdf
EC-IDCAT  http://www.catcert.net/descarrega/doc_legal/idCAT_pedc.pdf
EC-UR  http://www.catcert.net/descarrega/doc_legal/EC-UR_pedc.pdf
EC-SAFP  http://www.catcert.net/descarrega/doc_legal/EC-SAFP_pdc_general.pdf
CPS URL: https://www.catcert.net/verCIC-1

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):
https://login.diba.cat  


Certificate Details
-------------------

Certificate Name: EC-AL

Summary Paragraph, including the following:

EC-AL’s certificates are not issued to general public, but only to the civil servants and computers or devices of the Catalan government: this is city and town councils, regional councils, county councils, as well as autonomous agencies and public funded companies. 

Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/al_csrs.crt

Version: V3

SHA1 Fingerprint: a4 1a 5e 9b d2 ff 6d 52 be 21 e5 eb 35 fe 56 07 77 12 47 0a

Modulus Length (a.k.a. "key length"): 	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2003-01-08
Valid To (YYYY-MM-DD): 2019-01-08

CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl
http://epscd2.catcert.net/crl/ec-acc.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV): 
Organisationally validated

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-AL_dpc.pdf

CPS URL: https://www.catcert.net/verCIC-2

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):
https://login.diba.cat 


Certificate Details
-------------------

Certificate Name: EC-SAFP

Summary Paragraph, including the following: 

EC-SAFP’s certificates are not issued to general public, but only to the civil servants and computers or devices of agencies and departments of the Catalan Regional Government and public funded companies of the Catalan Regional Government (depending on the Secretaria d’Administració i Funció Pública). 


Certificate HTTP URL (on CA website):
http://www.catcert.net/descarrega/safs_csrs.crt

Version: V3

SHA1 Fingerprint: 09 55 ab 72 a8 3b 37 34 c3 89 07 e1 1f d2 95 66 42 71 56 e6

Modulus Length (a.k.a. "key length"):	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2003-01-08
Valid To (YYYY-MM-DD):2019-01-08

CRL HTTP URL: http://epscd.catcert.net/crl/ec-gencat.crl
              http://epscd2.catcert.net/crl/ec-gencat.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV): 
Organisationally validated

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-SAFP_dpc.pdf

CPS URL: https://www.catcert.net/verCIC-2

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):

https://www.e-ajrubi.net/ 

 
Certificate Details
-------------------

Certificate Name: EC-PARLAMENT

Summary Paragraph, including the following:

EC-PARLAMENT’s certificates are not issued to general public, but only to the civil servants and computers or devices of the Catalan Parliament. 

Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/parlament_csrs.crt

Version: V3

SHA1 Fingerprint: 82 70 f2 9f db 1f a3 1c 2a 85 46 11 a4 9d fa 6f c8 8d 06 90

Modulus Length (a.k.a. "key length"): 	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2004-06-30
Valid To (YYYY-MM-DD): 2020-06-29

CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl
              http://epscd2.catcert.net/crl/ec-acc.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV): 
Organisationally validated

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-AL_pdc_general.pdf


CPS URL: https://www.catcert.net/verCIC-2

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):

NONE 


Certificate Details
-------------------

Certificate Name: EC-UR

Summary Paragraph, including the following:

EC-UR’s certificates are not issued to general public, but to employees, students and computers or devices of Catalan universities and research centres connected to the “Anella Científica” group. 


Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/ur_csrs.crt

Version: V3

SHA1 Fingerprint: d7 af fd f4 7f df f6 86 5d db f1 46 d8 86 4c 70 6c fa 00 32

Modulus Length (a.k.a. "key length"): 	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2003-12-17
Valid To (YYYY-MM-DD): 2019-12-17

CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl
              http://epscd2.catcert.net/crl/ec-acc.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV): 
organizationally validated 

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-UR_dpc.pdf

CPS URL: https://www.catcert.net/verCIC-2

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):

https://www.catcampus.org/ 


Certificate Details
-------------------

Certificate Name: EC-URV

Summary Paragraph, including the following:

EC-UR’s certificates are not issued to general public, but to employees, students and computers or devices of the Universitat Rovira i Virgili (URV). 

Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/urv_csrs.crt

Version: V3

SHA1 Fingerprint: 01 55 fe c9 a2 21 7b b2 2a 0f 57 76 4b 30 e8 03 03 51 85 14

Modulus Length (a.k.a. "key length"): 	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2005-05-03
Valid To (YYYY-MM-DD): 2013-05-03

CRL HTTP URL: http://epscd.catcert.net/crl/ec-ur.crl
               		http://epscd2.catcert.net/crl/ec-ur.crl

OCSP URL: http://ocsp.catcert.net
	
Class (domain-validated, identity/organisationally-validated or EV): 
Organisationally validated.

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/EC-URV_dpc.pdf

CPS URL: https://www.catcert.net/verCIC-3

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):

https://actes.urv.cat
 

Certificate Details
-------------------

Certificate Name: EC-idCat

Summary Paragraph, including the following:

EC- idCAT’s certificates are issued to catalan citizens. 

Certificate HTTP URL (on CA website): http://www.catcert.net/descarrega/ec-idcat.cer

Version: V3

SHA1 Fingerprint: 50 49 88 bd b7 df e0 dd a8 eb f6 98 e0 b5 c4 65 02 fb 41 fc

Modulus Length (a.k.a. "key length"): 	RSA (2048 bits)

Valid From (YYYY-MM-DD): 2003-1-31
Valid To (YYYY-MM-DD): 2019-10-31

CRL HTTP URL: http://epscd.catcert.net/crl/ec-acc.crl
              http://epscd2.catcert.net/crl/ec-acc.crl

OCSP URL: http://ocsp.catcert.net

Class (domain-validated, identity/organisationally-validated or EV):	
Identity validated

Certificate Policy URL: http://www.catcert.net/descarrega/doc_legal/idCAT_dpc.pdf

CPS URL: https://www.catcert.net/verCIC-2

Requested Trust Indicators (email and/or SSL and/or code): all of them: e-mail, SSL and Code. 

URL of website using certificate chained to this root (if applying for SSL):

https://www.idcat.net/

Comment 17

[Gervase Markham [:gerv]]

This should not be assigned to me at the moment - reassigning to default owner.

Gerv

Comment 18

[Frank Hecker]

Accepting this bug.

Comment 19

[Toni Hermoso Pulido]

Any advance on this?
Is the information complete, isn't?
Different Spanish certificate bugs seem to be stalled by no apparent reason for years.

Comment 20

[Eddy Nigg (StartCom)]

It might be that the scope of this is CA is limited (and might be a regional government CA). Priority for those are low.

Comment 21

[Toni Hermoso Pulido]

Eddy, the regional aspect was discussed a couple of years ago in a Mozilla newsgrop:

http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/7ed60b1c316e9ae8/e5760202586c443c?hl=ca&lnk=gst&q=catcert#e5760202586c443c

Microsoft is including these regional certificates, which are actually used by most citizens, administrations and universities of densely populated areas such as Barcelona for several years.
Anyway, the Spanish FNMT, which is not so widely used in some areas, is not even approved yet.

So please, any help would be appreciated so we can offer a product in equal conditions regarding this aspect.

I think that more than two years is a significant dramatic amount of time.

I'm at your disposal to anything that I could offer in order to help to unblock this situation.

Comment 22

[Eddy Nigg (StartCom)]

I'm not aware of a change in policy concerning regional CAs. There are two issues of concern. The Mozilla CA Policy requirement and regionally limited CAs. I'm copying Kathleen to this bug in order for her to look at it and start eventual document gathering. However please take into account that this bug most likely will have a lower priority.

Comment 23

[Toni Hermoso Pulido]

Eddy, thanks for adding Kathleen to this bug, so she can try to advance this.
If there were any Mozilla policy document about this regional aspect, could you point it to me? 
As I commented in the linked newsgroup thread, we should take into account that some regional governments Catalonia (7,5 million potential people) can have a larger impact than some national ones. For instance, in case there were a certificate for Andorra (100.000 potential people).
I understand that priorities must be drawn, but after such a long time, and direct browser competetion in such an advanced situation, I think we should not make it delay longer (all Spanish certificates).
As I commented again, I'm at your disposal for anything and I can act as intermediary if needed.
Thanks!

Comment 24

[Eddy Nigg (StartCom)]

Toni, please see https://wiki.mozilla.org/CA:Schedule#General_Priority

Comment 25

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

A discussion in mozilla.dev.security.policy called “Accepting root CA
certificates for regional government CAs”, indicates that we can proceed with
processing the Spain regional government CAs.

I realize that some of the information has been gathered previously, but
Mozilla procedures have changed and some of the existing information needs to
be updated. As such, we will proceed with the Information Gathering and
Verification Phase as described in https://wiki.mozilla.org/CA:How_to_apply.

Attached is the Initial Information Gathering document which summarizes the
information that has been gathered, with highlights in yellow where additional or updated information is needed. Please review the document for accuracy and completeness. I will also summarize below where further clarification or updates are needed.

1) CA Hierarchy
a) Please verify the information in the document. Is this the full list of subordinate CA chaining up to this EC-ACC root? Which of these sub-CAs are operated internally, and which of these are operated by external third parties?
b) Please list all of the subordinate CAs that are operated by external third parties.
c) Has this root been involved in cross-signing with any other roots?

2) Please either provide pointers to the text/sections in the English CPS, or provide translations into English of the sections of the appropriate CP/CPS documents pertaining to:
Verification of ownership/control of domain name
Verification of ownership/control of email address
Section 7 of http://www.mozilla.org/projects/security/certs/policy/
Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices

3) When I enforce OCSP in Firefox, I get errors trying to access https://actes.urv.cat and https://www.idcat.net/.  Please investigate.

4) The WebTrust audit is from 2005. Do you have a more recent audit?

Comment 26

[Francesc Ferrer]

Attachment: Hierarchy map

Relation between Root and subordinate CA's

Comment 27

[Francesc Ferrer]

(In reply to comment #25)
> Created an attachment (id=371567) [details]
> Initial Information Gathering Document
> 
> A discussion in mozilla.dev.security.policy called “Accepting root CA
> certificates for regional government CAs”, indicates that we can proceed with
> processing the Spain regional government CAs.
> 
> I realize that some of the information has been gathered previously, but
> Mozilla procedures have changed and some of the existing information needs to
> be updated. As such, we will proceed with the Information Gathering and
> Verification Phase as described in https://wiki.mozilla.org/CA:How_to_apply.
> 
> Attached is the Initial Information Gathering document which summarizes the
> information that has been gathered, with highlights in yellow where additional
> or updated information is needed. Please review the document for accuracy and
> completeness. I will also summarize below where further clarification or
> updates are needed.
> 
> 1) CA Hierarchy
> a) Please verify the information in the document. Is this the full list of
> subordinate CA chaining up to this EC-ACC root? Which of these sub-CAs are
> operated internally, and which of these are operated by external third parties?

This is the full list of Subordinate CA Chaining. Find attached Hierarchy Map.
There are not Sub-CA's operated by third parties. Just the Registration Authorities.

> b) Please list all of the subordinate CAs that are operated by external third
> parties. There ar no CA's operated by external third parties.

> c) Has this root been involved in cross-signing with any other roots? NO
> 
> 2) Please either provide pointers to the text/sections in the English CPS, or
> provide translations into English of the sections of the appropriate CP/CPS
> documents pertaining to:
> Verification of ownership/control of domain name
> Verification of ownership/control of email address
> Section 7 of http://www.mozilla.org/projects/security/certs/policy/
> Potentially Problematic Practices,
> http://wiki.mozilla.org/CA:Problematic_Practices
> 

All the information we receive in CATCert to issue certificates (including domains and e-mails of CDS) come in a document signed by a representative of the corresponding organisation, which has public faith (as in the case of council secretaries ), or has been entitled to such action. In this case, the legitimacy is signed by the mayor (highest authority within the body) or similar charges in the case of EC-SAPF.

> 3) When I enforce OCSP in Firefox, I get errors trying to access
> https://actes.urv.cat and https://www.idcat.net/.  Please investigate.

OCSP answers are signed by EC-ACC. In order to our tests, when the certificate to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example), Firefox's implementations does not follow the hierarchy path, and so an error is given (SECERROR OCSP UNAUTHORIZED RESPONSE)

> 
> 4) The WebTrust audit is from 2005. Do you have a more recent audit?

No, but the requirements have not changed. A new  security plan is being deployed, and as soon it is completed, a new audit will be done.

Comment 28

[Kathleen Wilson]

> All the information we receive in CATCert to issue certificates (including
> domains and e-mails of CDS) come in a document signed by a representative of
> the corresponding organisation, which has public faith (as in the case of
> council secretaries ), or has been entitled to such action. In this case, the
> legitimacy is signed by the mayor (highest authority within the body) or
> similar charges in the case of EC-SAPF.

I don’t understand how this meets section 7 of the Mozilla CA Policy.  Please…

a) Explain how the ownership/control of the domain name is verified.

b) Explain how the ownership/control of the email address is verified.

c) Review the list of Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones are relevant.  Provide further information (including pointers to CP/CPS section numbers when relevant).

>> 3) When I enforce OCSP in Firefox, I get errors trying to access
>> https://actes.urv.cat and https://www.idcat.net/.  Please investigate.
> OCSP answers are signed by EC-ACC. In order to our tests, when the certificate
> to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example),
> Firefox's implementations does not follow the hierarchy path, and so an error
> is given (SECERROR OCSP UNAUTHORIZED RESPONSE)

I’m not an OCSP expert. Perhaps someone on this bug notification can provide some guidance?  If not, we can proceed, and this should get resolved in the discussion phase.

>> 4) The WebTrust audit is from 2005. Do you have a more recent audit?
> No, but the requirements have not changed. A new  security plan is being
> deployed, and as soon it is completed, a new audit will be done.

What is the frequency of your audits?
When do you expect the new audit to be complete?
Please make sure that the new audit is compliant with sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/.

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #27)
> > 3) When I enforce OCSP in Firefox, I get errors trying to access
> > https://actes.urv.cat and https://www.idcat.net/.  Please investigate.
> 
> OCSP answers are signed by EC-ACC. In order to our tests, when the certificate
> to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example),
> Firefox's implementations does not follow the hierarchy path, and so an error
> is given (SECERROR OCSP UNAUTHORIZED RESPONSE)

Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560.
NSS strictly enforces the 3 rules at the bottom of page 10, and gives the error
code you cited above when the response does not conform to those rules.

Comment 30

[Francesc Ferrer]

Attachment: Operative Procedure

Comment 31

[Francesc Ferrer]

Attachment: idCAT Audit

Comment 32

[Francesc Ferrer]

Attachment: T-CAT Audit

Comment 33

[Francesc Ferrer]

(In reply to comment #28)
> > All the information we receive in CATCert to issue certificates (including
> > domains and e-mails of CDS) come in a document signed by a representative of
> > the corresponding organisation, which has public faith (as in the case of
> > council secretaries ), or has been entitled to such action. In this case, the
> > legitimacy is signed by the mayor (highest authority within the body) or
> > similar charges in the case of EC-SAPF.
> 
> I don’t understand how this meets section 7 of the Mozilla CA Policy.  Please…
> 
> a) Explain how the ownership/control of the domain name is verified.

Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of the domain name is verified. 
"The responsible of the service must verify the URL of the server and the data using the WHOIS service (www.whois.net). With this procedure, it is verified that the server exists."

> 
> b) Explain how the ownership/control of the email address is verified.
> 
It is not a requirement of the spanish Law, to include the e-mail field on the certificate, that's why an specific procedure for the verification of the e-mail is not defined at the procedure. Anyway, as explained in item 1.3.2.6of the operative procedure, the information related to the identity of the user is supplied by a previously authirozed third part.

> c) Review the list of Potentially Problematic Practices,
> http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones
> are relevant.  Provide further information (including pointers to CP/CPS
> section numbers when relevant).
> 
CATCert does not operate with any of the potentially problematic practices.

> >> 3) When I enforce OCSP in Firefox, I get errors trying to access
> >> https://actes.urv.cat and https://www.idcat.net/.  Please investigate.
> > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate
> > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example),
> > Firefox's implementations does not follow the hierarchy path, and so an error
> > is given (SECERROR OCSP UNAUTHORIZED RESPONSE)
> 
> I’m not an OCSP expert. Perhaps someone on this bug notification can provide
> some guidance?  If not, we can proceed, and this should get resolved in the
> discussion phase.
> 
> >> 4) The WebTrust audit is from 2005. Do you have a more recent audit?
> > No, but the requirements have not changed. A new  security plan is being
> > deployed, and as soon it is completed, a new audit will be done.
> 
> What is the frequency of your audits?
> When do you expect the new audit to be complete?
> Please make sure that the new audit is compliant with sections 8, 9, and 10 of
> http://www.mozilla.org/projects/security/certs/policy/.

Comment 34

[Francesc Ferrer]

(In reply to comment #28)
> > All the information we receive in CATCert to issue certificates (including
> > domains and e-mails of CDS) come in a document signed by a representative of
> > the corresponding organisation, which has public faith (as in the case of
> > council secretaries ), or has been entitled to such action. In this case, the
> > legitimacy is signed by the mayor (highest authority within the body) or
> > similar charges in the case of EC-SAPF.
> 
> I don’t understand how this meets section 7 of the Mozilla CA Policy.  Please…
> 
> a) Explain how the ownership/control of the domain name is verified.
> 
> b) Explain how the ownership/control of the email address is verified.
> 
> c) Review the list of Potentially Problematic Practices,
> http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to which ones
> are relevant.  Provide further information (including pointers to CP/CPS
> section numbers when relevant).
> 
> >> 3) When I enforce OCSP in Firefox, I get errors trying to access
> >> https://actes.urv.cat and https://www.idcat.net/.  Please investigate.
> > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate
> > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example),
> > Firefox's implementations does not follow the hierarchy path, and so an error
> > is given (SECERROR OCSP UNAUTHORIZED RESPONSE)
> 
> I’m not an OCSP expert. Perhaps someone on this bug notification can provide
> some guidance?  If not, we can proceed, and this should get resolved in the
> discussion phase.
> 
> >> 4) The WebTrust audit is from 2005. Do you have a more recent audit?
> > No, but the requirements have not changed. A new  security plan is being
> > deployed, and as soon it is completed, a new audit will be done.
> 
> What is the frequency of your audits?
> When do you expect the new audit to be complete?
> Please make sure that the new audit is compliant with sections 8, 9, and 10 of
> http://www.mozilla.org/projects/security/certs/policy/.

Find attached the last audits which were made this year, for idCAT and T-CAT products.

Comment 35

[Francesc Ferrer]

(In reply to comment #29)
> (In reply to comment #27)
> > > 3) When I enforce OCSP in Firefox, I get errors trying to access
> > > https://actes.urv.cat and https://www.idcat.net/.  Please investigate.
> > 
> > OCSP answers are signed by EC-ACC. In order to our tests, when the certificate
> > to validate is issued by a subordinate CA (EC-URV, or EC-idcat in example),
> > Firefox's implementations does not follow the hierarchy path, and so an error
> > is given (SECERROR OCSP UNAUTHORIZED RESPONSE)
> 
> Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560.
> NSS strictly enforces the 3 rules at the bottom of page 10, and gives the error
> code you cited above when the response does not conform to those rules.

We use delegation, so we accomplish the following:
OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate

Regarding the three possible rules:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or
 
   2. Is the certificate of the CA that issued the certificate in
   question; or
 
   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

We don't accomplish number 2. But we do accomplish "1" and "3" so that should be enough.

Comment 36

[David E. Ross]

In comment #33, it is stated that: 
"Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of
the domain name is verified.  'The responsible of the service must verify the URL of the server and the data using the WHOIS service (www.whois.net). With this procedure, it is verified that the server exists.'

This merely verifies the existence of the domain name.  It does not verify that the person, company, or organization requesting a site certificate actually owns and controls that domain and is authorized to request a certificate for the domain.

Comment 37

[Francesc Ferrer]

Item 1.3.2.1. explains how the application forms and the corresponding documentation es received and registered.

Item 1.3.2.2. explains how the service responsible verifies that the application form has been handwritten signed by the applicant. If not, the application is denied.

Item 1.3.2.3. Explains that is verified that all the documentation has been supplied, and that it is correct

Items 1.3.2.4 and 1.3.2.5, explain that it si verified the identity of the applicant and organization specified at the application form

- If the documentation is sent by e-mail, it must be digitally signed by the authorized applicant.
- If it is sent by traditional mail, the signature of the applicant will be handwritten.
- For some kind of certificates, images as company-logo in example are required.

Item 1.3.2.6 explains that the identity of the Key holder is verified indirectly by the applicant.

Comment 38

[Kathleen Wilson]

In regards to Comment #35
> We use delegation, so we accomplish the following: 
> OCSP signing delegation SHALL be designated by the inclusion of 
> id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the
> OCSP response signer's certificate
> Regarding the three possible rules:
>   1. Matches a local configuration of OCSP signing authority for 
>      the certificate in question; or
>   2. Is the certificate of the CA that issued the certificate in question; or
>   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension 
>      and is issued by the CA that issued the certificate in question.
> We don't accomplish number 2. But we do accomplish "1" and "3" so that 
> should be enough.

I believe that before including the root in NSS, the websites with SSL certs chaining to this root must work, even when OCSP is enforced. According to Comment #29, NSS strictly enforces all 3 of the rules, and gives the error when the response does not conform to those rules.

Is this something CATCert can resolve?

> idCAT Audit: https://bugzilla.mozilla.org/attachment.cgi?id=387879
> T-CAT Audit: https://bugzilla.mozilla.org/attachment.cgi?id=387880

It’s not clear to me which of the following audit criteria were used, as per section 8 of http://www.mozilla.org/projects/security/certs/policy/
ETSI TS 101 456
ETSI TS 102 042
WebTrust Principles and Criteria for Certification Authorities

It’s also not clear to me what the tables are saying (being in a language other than English doesn’t help).  It would be better to have a statement from an auditor that states what the criteria were (as per one or more of the above list), which roots and sub-CAs were audited, which documents were included in the audit, when the audit was performed, what issues were noted, and if all of the criteria were reasonably met.

Note that the audit statement needs to be from an auditor that meets sections 9 and 10 of http://www.mozilla.org/projects/security/certs/policy/.

> Item 1.3.2.7 of the Operative Procedure

I have used Google Translate on all of section 1.3 of the Operative Procedure, and I did not find anything about how the output of WHOIS is used or compared to the data of the applicant in order to verify that the applicant owns/controls that domain.

> It is not a requirement of the spanish Law, to include the e-mail field on  
> the certificate, that's why an specific procedure for the verification of 
> the e-mail is not defined at the procedure. Anyway, as explained in item 
> 1.3.2.6 of the operative procedure, the information related to the identity 
> of the user is supplied by a previously authirozed third part.

Section 7 of the Mozilla CA Policy (http://www.mozilla.org/projects/security/certs/policy/) is about verifying that the applicant owns/controls the email address referenced in the certificate. Verification of the identity of the applicant does not completely satisfy this requirement. If CATCert does not have an audited procedure for verifying the ownership of the email address, then I recommend that you not request to enable the Email trust bit. 

Based on the information I have been able to review for this request, I think that only the Websites trust bit should be requested. I don’t think that there are documented/audited procedures that meet the requirements for enabling the Email and Code Signing trust bits. Is CATCert OK with proceeding with only requesting the Websites trust bit?

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #38)
> I believe that before including the root in NSS, the websites with SSL certs
> chaining to this root must work, even when OCSP is enforced. 

I fully and absolutely agree.

Comment 40

[Kathleen Wilson]

There has been no activity in this bug for almost 8 months.

Is this request obsolete?

Comment 41

[Kathleen Wilson]

Closing bug due to no recent response from CA.

Comment 42

[Francesc Ferrer]

Hi Kathleen, sorry for the delay giving feedback. We have been working hard in order to accomplish your requirements. Currently, the situation is the following:

- Regarding to the first pending point, we recently passed a Webtrust audit. See the certificate on the following link:
https://cert.webtrust.org/ViewSeal?id=1063
- About the second pending point, we will have a technical solution for the OCSP matter on september.

The purpose of this entry is to let you know that we are working on it, and once solved the complications, would like to reopen the bug. For CATCert it is very important to get our certificates included in your distribution, and for that purpose, have our Director's support. 

Is it possible to reopen the bug?

Comment 43

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Yes, we can continue with this request. 

Attached is an updated Information Gathering Document which reflects our current process, as described here: https://wiki.mozilla.org/CA:How_to_apply

Please review this document for accuracy and completeness, update the information that has changed, and provide further information or clarification as indicated by the items highlighted in yellow.

Comment 44

[Francesc Ferrer]

Attachment: Current Webtrust audit in English

This is the webtrust audit statement in English.

Comment 45

[Kathleen Wilson]

Thanks for translating the audit into English.  Please see the attached "Updated Information Gathering Document" for the other information/clarifications that are still needed.

Comment 46

[Francesc Ferrer]

Hi Kathleen, we have reviewed the documentation you mentioned, and we have taken some decisions:

1.- We only request for the Websites trust bit.
2.- Our CPS (in catalan) can be found online at http://www.catcert.cat/registre 
Our CPS (in spanish) can be found online at http://www.catcert.cat/web/cas/5_0_regulacio.jsp (we are defining the alias).
3.- Some time ago we explained how the domain checking was done and documented in our internal procedure.
We add the same explanation, but this time we add the translation of the procedure referred part. If you agree that this procedure complies with your requirements we will refer it from the CPS (or we will add this part of the procedure to our CPS if this is necessary).

Summarizing next steps: 
1.- Only authorized personal from Catalan Administration can request a certificate (Domain Server Certificate).
2.- (Items 1.3.2.1 – 1.3.2.5) It’s checked the applicant is an authorized person.
3.- (Item 1.3.2.7) It is checked using www.whois.net the existence of the server and the ownership.
Regarding the step 3, in your recommended practices it’s mentioned it can be correlated the whois information with other sources. At this moment we only use one source because only authorized people can be applicants, but it’s not a problem for us to add another source if this is not enough for you.

We add some glossary in order to make the understanding of the described processes easier:
Subscriber: It is the person in charge of the public entity (subscriber entity) authorized to apply for certificates (for us, they are our clients, all of them are people who holds a public office).
Subscriber Card: This is the form to be filled in by the Subscriber. In this form it is requested all the information in order to know who can apply for certificates. 
Application Form: This is the form to be filled in order to apply for certificates.

Item 1.3.2.1. explains how the application forms and the corresponding documentation is received and registered.

1.3.2.1 Reception and registry of the documentation.
Once the documentation referring to a request arrives to the Registration Entity, it is registered as entrance for the person entrusted of the registry. Afterwards, this documentation is delivered to the person in charge of the service, and this person continues with the formality.

Item 1.3.2.2. explains how the person in charge of the Registration Entity verifies that the application form has been handwritten signed by the applicant. If not, the application is denied.

1.3.2.2 Checking the existence of subscriber card.
The person in charge has to verify that the Subscriber has signed the subscriber card. In case the Subscriber has not signed it, the person in charge of the Registration Entity will send an electronic mail (digitally signed and with acknowledgment of receipt) to the person in charge of the subscriber entity briefing him of it is required having previously signed the subscriber card in order to go on.
Until the subscriber card is not formalized the process of request will remain stopped (in "pending" state) and the action carried out will be registered by the person in charge of the Registration Entity.

Item 1.3.2.3. Explains that it is verified that all the documentation has been supplied, and that it is correct

1.3.2.3 Checking the documentation and notification to the subscriber
The person in charge of the Registration Entity will have to verify that the person in charge of the subscriber entity gives all the documentation required and in a proper format.
In case any document was missing or any error was detected, it would be communicated to the person in charge of the subscriber entity by signed electronic mail and with acknowledgment of receipt. The reasons why the process and the actions have been halted will be indicated, and  the action carried out will be registered.
The process of Request will remain stopped (request in "pending" state) until all the documentation required is received. In case the request is accepted, the person in charge of the Registration Entity will notify to the person in charge of the subscriber entity by signed electronic mail that the request is being processed.

Items 1.3.2.4 and 1.3.2.5, explain that it is verified the identity of the applicant and organization are the specified ones at the application form

1.3.2.4 Validation of the identity and authority of the applicant
The person in charge of the Registration Entity has to check out that who makes the request for obtaining a digital certificate is authorized, it means that he/she is who was specified in the subscriber card. The valid methods for receiving the information required of a request for obtaining a certificate are detailed next:

1) By electronic mail:
The person in charge of the subscriber entity sends an electronic mail to the person in charge of the Registration Entity digitally signed, and he/she attaches the electronic documents, also digitally signed, by the people indicated in the subscriber card. It means, the person in charge of the Registration Entity has to check out that the applicant indicated in the card has signed the request.
In case that the Registration Entity does not have telematic registry, the documentation will be printed after being verified the signature and will be sealed with the indication “It is exact copy of an electronic document, which I have verified that the electronic signature is correct". Also it will be necessary that the person in charge of the Registration Entity signs at the foot of the seal.

2) By postal mail:
The person in charge of the subscriber entity makes to arrive at the person in charge of the Registration Entity the documentation in paper signed by the people indicated in the subscriber card. In case the authentication and authorization of the applicant is not correct, the person in charge of the Registration Entity will reject the request and will send a signed electronic mail to the person in charge of the entity subscriber. Otherwise, the process continues. 

1.3.2.5 Validation of the identity and authority of the certifier
The person in charge has to check out that who delivers the documental justification really is authorized, it means this person is the Certifier that it was specified in the subscriber card. The valid methods for receiving the information required of a request for obtaining a certificate are detailed next:
1) The person in charge of the subscriber entity sends an electronic mail to the person in charge of the Registration Entity signed digitally, and the electronic documents are attached, also digitally signed by the people indicated in the subscriber card. It means, the person in charge of the Registration Entity has to check out that the certifier indicated in the card is who has signed the certificate.
In case that the Registration Entity does not have telematic registry, the documentation will be printed after being verified the signature and will be sealed with the indication “It is exact copy of an electronic document, which I have verified that the electronic signature is correct". Also it will be necessary that the person in charge of the Registration Entity signs at the foot of the seal.
2) By postal mail:
The person in charge of the subscriber entity makes to arrive at the person in charge of the Registration Entity the documentation in paper signed by the people indicated in the subscriber card. 
In case the authentication and authorization of the applicant is not correct, the person in charge of the Registration Entity will reject the request and will send a signed electronic mail to the person in charge of the entity subscriber. Otherwise, the process continues. 

Item 1.3.2.7 of the Operative Procedure, explains how the ownership/control of
the domain name is verified.
1.3.2.7 Checking of the certificate data (Domain Server Certificates)
In case of Domain Server Certificates requests, the person in charge of the Registration Entity will verify the existence and ownership of the server URL and the registration data using the WHO IS (www.whois.net). This way he/she verifies the existence of the server.
The result will be converted to pdf format and it will be signed digitally by de person in charge of the Registration Entity. A digital copy will be stored and another will be printed and attached to the request, stored into the Registration Entity archive.

This procedure can be find in catalan on:
http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip

Comment 47

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thanks for the information and translations.

Please see the newly attached "Updated Information Gathering Document". The items highlighted in yellow indicate where further information or clarification is still needed.

Comment 48

[Francesc Ferrer]

1. OCSP Responder URL:

We are working on it. In our development environment it works properly, so we will migrate the production environment soon. We will let you know when the OCSP works properly.


2. CP/CPS: 

When we created the CPS it was translated to English, but we have not updated the English version since then. It means this document is obsolete.

The same document in Spanish can be downloaded from: http://www.catcert.cat/web/cas/5_0_regulacio.jsp --> http://www.catcert.cat/web/cas/5_1_politica_general.jsp --> http://www.catcert.cat/descarrega_cas/oficina_politicas/D1111_N-PGDC_v3r3_cast.pdf

We have defined 2 alias (Catalan: www.catcert.cat/registre and Spanish: www.catcert.cat/registro) in order to access to the last release of the regulations (you have called it “Document Repository”).

If you need the translation to English of some parts I can do it.

3. Domain Name. Ownership / Control

Comment #36: 

Comment #38: 

CATCert only generates website certificates for Catalan Public Administrations. As mentioned before (1.3.2.1-1.3.2.7 of the Operative Procedure document) only authorized people can apply for certificates, and it is checked. 

Registration Entity contacts the owner listed in the whois (http://www.whois.net/ and http://www.internic.net/whois.html for domains .cat) to verify that the applicant has the right to use the domain or subdomain.

In order to verify it, the person in charge of the Registration Entity extracts the admin data and sends an e-mail asking if the applicant owns/controls the subdomain.

Once the confirmation is received, the certificate  is generated.

4. Potentially Problematic Practices.

   4.1. RAs are external to CATCert but they belong to the Catalan Public Administration. It means they have in common the application of the controls specified at the Spanish Law 30/92 about procedures of the Public Administration. These RAs sign a contract with CATCert, and their way of working is periodically audited using the clauses of the contract.

   4.2. Certificates referencing hostnames or private IP addresses: NO.

   4.3. Issuing SSL Certificates for Internal Domains: NO

Comment 49

[Kathleen Wilson]

>> 1. OCSP Responder URL:
>> We are working on it. In our development environment it works properly, so we
>> will migrate the production environment soon. We will let you know when the
>> OCSP works properly.

OK. Please post a comment in this bug when ready.

>> 2. CP/CPS: 

Thank you for the clarification about the documents. 

Please provide translations into English of Section 3.2.2 and 3.2.3 of Política General de Certificación Agència Catalana de Certificació. (http://www.catcert.cat/web/cas/5_1_politica_general.jsp)

>> 4.1. RAs are external to CATCert but they belong to the Catalan Public
>> Administration. It means they have in common the application of the controls
>> specified at the Spanish Law 30/92 about procedures of the Public
>> Administration. These RAs sign a contract with CATCert, and their way of
>> working is periodically audited using the clauses of the contract.

Is this documented in the CP/CPS? If yes, please provide corresponding url, page/section numbers, and translations.

Comment 50

[Francesc Ferrer]

Attachment: Translation from http://www.catcert.cat/descarrega/oficina_politiques/D1111_N-PGDC_v3r3_cat.pdf

Comment 51

[Francesc Ferrer]

Attachment: translations into English of Section 3.2.2 and 3.2.3 of Política General de Certificación Agència Catalana de Certificació. (http://www.catcert.cat/web/cas/5_1_politica_general.jsp)

Comment 52

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thank you for the translations.

Please post an update in this bug when the OCSP issues have been resolved, as per Comment #48.

Comment 53

[Francesc Ferrer]

Finally our OCSP service is working properly.

We have tested firefox in the next URLs:

SAFP
https://contractaciopublica.gencat.cat/ecofin_pscp/AppJava/notice.pscp?reqCode=searchCn&idCap=203732 

AL
https://seu.badalona.cat/portalWeb/badalona.portal?_nfpb=true&_pageLabel=seu_electronica

UR
https://seuelectronica.upc.edu/ 

URV
https://portal.urv.cat/portal/dt 

Until now we have never generated Server Certificates for: Parlament and Gencat
It means these ones can not be tested using Firefox if I’m right.

Comment 54

[Toni Hermoso Pulido]

Sorry for the whining but, can we move this quickly, Francesc & Kathleen? After so long, Catalan community of Firefox users would be highly benefited by this, and we would love to have this available, at latest, by the time new Firefox 4 would be released.

Thanks!

Comment 55

[David E. Ross]

To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  

This request was closed TWICE because the certificate authority failed to provide necessary information in a timely manner.  See comment #15 and comment #41.  Thus, the problem lies in the hands of CATCert and not Mozilla.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.

Those who are anxious for this root certificate -- those who already trust it and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificate themselves.  The link is at <http://www.mozilla.org/projects/security/certs/pending/#CATCert>.

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there.

Note well:  These are my personal comments.  I do not work for either the Mozilla Foundation or the Mozilla Corporation.  Thus, these comments do not reflect the position of either organization.

Comment 56

[Toni Hermoso Pulido]

(In reply to comment #55)

Thanks for the informative comments, Dave. 
I'm well aware of the delay of response from CatCert and their responsibility.

According to comment 53, all necessary information seems to be already finished, http://www.mozilla.org/projects/security/certs/pending/#CATCert —changing the color from red to green—. If not, I would appreciate a comment about.

Note: I don't work for neither Mozilla nor CatCert. I'm a 6 years member of Mozilla Catalan community interested in helping Mozilla to progress in my society.

Comment 57

[Kathleen Wilson]

I am able to browse to the websites listed in Comment #53. I have OCSP enforced, and I confirmed that the SSL cert for each site has http://ocsp.catcert.net as the OCSP URI in the AIA.

Comment 58

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 59

[Kathleen Wilson]

This request is already in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

The goal is to have each discussion take about two weeks. However, that time varies dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 60

[Toni Hermoso Pulido]

Thanks Kathleen for your work.

From now on, I would encourage interested parts to join ongoing discussions in the mailing list (as described in the links above)
https://lists.mozilla.org/listinfo/dev-security-policy

Comment 61

[Francesc Ferrer]

We'd like to start Extended Validation Certificates recognition. What steps must we follow? Thanks.

Comment 62

[Kathleen Wilson]

Please provide the following information regarding EV...

1) URLs and section numbers of the CP/CPS documentation regarding verification of organization identity and domain name ownership/control for EV certs.

2) EV Policy OID(s)

3) URL to a website whose EV SSL cert chains up to this root (may be a test site).

4) EV Audit statement

5) Updated CA Hierarchy info (e.g. differences from what is described in the attached Information Gathering Document).

Comment 63

[Francesc Ferrer]

Thanks Kathleen, we are preparing the required information. As a reference of our progress, we have already obtained Webtrust's EV seal:
https://cert.webtrust.org/ViewSeal?id=1189

Anyway, we want to be sure that EV recognition, does not delay the recognition process for the rest of our certificates, as we've been working on for a long time. We'd like to finish the current process as fast as possible, so will start with EV certificates recognition only if it's a parallel process and doesn't delay the recognition of the rest of certificates. Could you confirm us this point, please?

Comment 64

[Kathleen Wilson]

I am planning to start this discussion the week of August 15.

When do you expect to have the rest of the EV information available as per comment #62?

Comment 65

[Kathleen Wilson]

I am re-reviewing this request to prepare it for the upcoming public discussion.  

Regarding Comment #46:
> 3.- Some time ago we explained how the domain checking was done and
> documented in our internal procedure.
> We add the same explanation, but this time we add the translation of the
> procedure referred part. If you agree that this procedure complies with your
> requirements we will refer it from the CPS (or we will add this part of the
> procedure to our CPS if this is necessary).
> 
> Summarizing next steps: 
> 1.- Only authorized personal from Catalan Administration can request a
> certificate (Domain Server Certificate).
> 2.- (Items 1.3.2.1 – 1.3.2.5) It’s checked the applicant is an authorized
> person.
> 3.- (Item 1.3.2.7) It is checked using www.whois.net the existence of the
> server and the ownership.
> Regarding the step 3, in your recommended practices it’s mentioned it can be
> correlated the whois information with other sources. At this moment we only
> use one source because only authorized people can be applicants, but it’s
> not a problem for us to add another source if this is not enough for you.
> 


Please let me know where I can find these 3 items in the CP or CPS documents. 

According to the Mozilla CA Certificate Policy, this information must be in publicly available and audited documentation.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Comment 66

[Francesc Ferrer]

Regarding Comment #64: 

These are fantastic news Kathleen! answering your question, we hope to have all EV information at the end of september or at maximum at october (we have to delay the creation of the test URLs in order to apply minimal changes to the certificates profile in order to acomplish with new Spanish Industry Ministery requirements).

Comment 67

[Francesc Ferrer]

Regarding Comment #65:


The points 1 and 2: 
-------------------

are specified in each CPS, you can find all them at the link: http://www.catcert.cat/web/cas/5_2_declaracio.jsp . 

There you have a different CPS for each certification authority (they are in Spanish): 

-	EC-ACC: is the root entity and is offline
-	EC-AL :  this entity only issues certificates to “local government” of Catalonia (these are the city councils).
-	EC-GENCAT and EC-SAFP: they only issue certificates to “autonomic government of Generalitat”. 
-	EC-UR: only issues certificates to public universities (in Spain, universities are also public administration).
-	EC-URV: only issues certificates to the public Rovira Virgili University (is public administration).
-	EC-Parlament: only issues certificates to the Catalonia Parliament.
-	EC-idCAT: only issues certificates to citizens of Catalonia and it does not issue SSL server certificates to other administrations (except itself SSL certificate for the  www.idcat.cat domain).

So all server certificates are only issued to the limited well-known public governments and administrations of Catalonia.

In each CPS you can find the authorization requirements, for example in the EC-AL: 

--------------------
4.1 SOLICITUD DE EMISIÓN DE CERTIFICADO .... 38 
4.1.1 Legitimación para solicitar la emisión .... 38 
4.1.2. Procedimiento de alta; Responsabilidades .... 38 
4.2 PROCEDIMIENTO DE SOLICITUD DE CERTIFICACIÓN .... 39 
4.2.1 Requisitos generales para todos los certificados .... 39 
4.2.2. Requisitos específicos para el CEIXSA .... 40 
4.2.3.Informaciones adicionales para el CDS, el CDSCD y el CDS-1 de Sede Electrónica .... 40 
4.2.4 Informaciones adicionales para el CIPISR.... 40 
4.2.5. Otros certificados.... 41
---------------------


To sum up: each client administration sends us a client data form with the information of the authorized people that can request the issue of certificates for that administration. This form is typically signed and sealed by the mayor or some other high government organ of that administration. We verify the data in the form, address, public composition of the organization, and so on, with the database of public organizations (maintained by the Public administrations department of the Catalonia Government).

Then, the authorized people can request certificates in most of cases online with EACAT (the Catalonian Extranet for administration) (www.eacat.cat), signing the application form with its own digital certificate through Internet (only people with the correct assigned role can do it, this is verified automatically in online requests or manually in the residual paper ones).

Then, some automatic verification is done (included for EV) to check the correct domain format, no appearance in anti-phishing list, etc.

And finally, before the issue of certificate, there is a manual verification, searching the WHOIS database to see the ownership of the domain, as explained later.
   
This is the same in all the other certification authorities.


The point 3:
------------

can be found at the public procedure, applied by all the ER-TCAT (Registration Entities) at the URL: http://www.catcert.cat/web/cas/1_0_2_er_tcat.jsp  , there is a “Procediments” link that goes directly to:  http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip . Inside the ZIP file there is the operative procedure for the registration entities: D1132-PO-00-procediment_operatiu_20070920.pdf, and in the title
“1.3.2.7 Verificació de les dades del certificat CDS i CDSDC” you can find the requirement to validate the existence and server ownership using WHOIS services, doing a quick translation it says: 

In the case of a request for a CDS (“server certificate”), the responsible of the SCD (“Digital Certificate Service”) will verify the URL of the server with WHO IS (www.whois.net), in order to verify its existence.

The resulting page will be converted to PDF format and will be signed digitally. It is saved one printed copy and one in electronic format in the file of that request.

---
If you need any further information or more detail in some part, please let us know. Thank you.

Comment 68

[Kathleen Wilson]

(In reply to comment #67)
> Regarding Comment #65:
> 
> 
> The points 1 and 2: 
> -------------------
> 
> are specified in each CPS, you can find all them at the link:
> http://www.catcert.cat/web/cas/5_2_declaracio.jsp . 
> 
> There you have a different CPS for each certification authority 
> <snip>
> In each CPS you can find the authorization requirements, for example in the
> EC-AL: 
> --------------------
> 4.1 SOLICITUD DE EMISIÓN DE CERTIFICADO .... 38 
> 4.1.1 Legitimación para solicitar la emisión .... 38 
> 4.1.2. Procedimiento de alta; Responsabilidades .... 38 
> 4.2 PROCEDIMIENTO DE SOLICITUD DE CERTIFICACIÓN .... 39 
> 4.2.1 Requisitos generales para todos los certificados .... 39 
> 4.2.2. Requisitos específicos para el CEIXSA .... 40 
> 4.2.3.Informaciones adicionales para el CDS, el CDSCD y el CDS-1 de Sede
> Electrónica .... 40 
> 4.2.4 Informaciones adicionales para el CIPISR.... 40 
> 4.2.5. Otros certificados.... 41
> ---------------------
> 
> 
> To sum up: each client administration sends us a client data form with the
> information of the authorized people that can request the issue of
> certificates for that administration. This form is typically signed and
> sealed by the mayor or some other high government organ of that
> administration. We verify the data in the form, address, public composition
> of the organization, and so on, with the database of public organizations
> (maintained by the Public administrations department of the Catalonia
> Government).
> 
> Then, the authorized people can request certificates in most of cases online
> with EACAT (the Catalonian Extranet for administration) (www.eacat.cat),
> signing the application form with its own digital certificate through
> Internet (only people with the correct assigned role can do it, this is
> verified automatically in online requests or manually in the residual paper
> ones).
> 
> Then, some automatic verification is done (included for EV) to check the
> correct domain format, no appearance in anti-phishing list, etc.
> 
> And finally, before the issue of certificate, there is a manual
> verification, searching the WHOIS database to see the ownership of the
> domain, as explained later.
>    
> This is the same in all the other certification authorities.
> 
> 

I am looking in the EC-AL DPC (using Google Translate) to try to find the sections about correct domain format, anti-phishing, and whois. I cannot find this text. What section(s) should I be looking in?

Comment 69

[Francesc Ferrer]

Hi Kathleen, first of all thank you for the effort of using Google Translate; you are right, in the current CPS there is not the low level information for the items requested, but we are applying them:


-	Domain format controls: our application verifies automatically that the domain is in FQDN form. If not, the certificate cannot be issued.

-	Anti-phishing controls: the application verifies automatically that the domain is neither in the public list of phishing (www.phishtank.com) nor in the internal database of certificates issued by CATCert and revoked by phishing reason. 

-	Registration of domain: the manual validation of whois is only mentioned in the public procedure of register entity operation, which I mentioned in my last post. 


Nowadays, the detail of the information about the automatic controls (verification of domain format and anti-phishing) is only in the administration procedure (document not public for security reasons). We should quickly add the information about those automatic controls  in the public operating procedure, but changing the CPS would require a little more time, because in order to change CPS we need the final approval of all the political partners associated to each certification authority, and maybe some of them are now on holidays. 
Would be the option of putting the information in the public operating procedure valid for you (meanwhile we put it on all CPS, get the approval to publish, and so on)?

Comment 70

[Kathleen Wilson]

> -	Domain format controls: our application verifies automatically that the
> domain is in FQDN form. If not, the certificate cannot be issued.
> -	Anti-phishing controls: the application verifies automatically that the
> domain is neither in the public list of phishing (www.phishtank.com) nor in
> the internal database of certificates issued by CATCert and revoked by
> phishing reason. 


When does the application for verifying domain format and anti-fishing actually get run? e.g. is it when someone requests the certificate creation? 


> -	Registration of domain: the manual validation of whois is only mentioned
> in the public procedure of register entity operation, which I mentioned in
> my last post. 

Thank you for the clarification.

> 
> Nowadays, the detail of the information about the automatic controls
> (verification of domain format and anti-phishing) is only in the
> administration procedure (document not public for security reasons). We
> should quickly add the information about those automatic controls  in the
> public operating procedure, but changing the CPS would require a little more
> time, because in order to change CPS we need the final approval of all the
> political partners associated to each certification authority, and maybe
> some of them are now on holidays. 
> Would be the option of putting the information in the public operating
> procedure valid for you (meanwhile we put it on all CPS, get the approval to
> publish, and so on)?


I think the operating procedure is fine. Our requirement is that the information be available in a public and audited document.


I have another question...

In the CPS there is information about class 1 and class 2 certificates. Are SSL certificates issued for both class 1 and class 2? I'm not sure I understand what class 1 certificates are.

Comment 71

[Francesc Ferrer]

(In reply to Kathleen Wilson from comment #70)
> > -	Domain format controls: our application verifies automatically that the
> > domain is in FQDN form. If not, the certificate cannot be issued.
> > -	Anti-phishing controls: the application verifies automatically that the
> > domain is neither in the public list of phishing (www.phishtank.com) nor in
> > the internal database of certificates issued by CATCert and revoked by
> > phishing reason. 
> 
> 
> When does the application for verifying domain format and anti-fishing
> actually get run? e.g. is it when someone requests the certificate creation? 
> 

Yes it is, but also done when the registry entity operator does the internal approbation to allow the generation, and also when the effective certificate generation is done by other operator.



> 
> > -	Registration of domain: the manual validation of whois is only mentioned
> > in the public procedure of register entity operation, which I mentioned in
> > my last post. 
> 
> Thank you for the clarification.
> 
> > 
> > Nowadays, the detail of the information about the automatic controls
> > (verification of domain format and anti-phishing) is only in the
> > administration procedure (document not public for security reasons). We
> > should quickly add the information about those automatic controls  in the
> > public operating procedure, but changing the CPS would require a little more
> > time, because in order to change CPS we need the final approval of all the
> > political partners associated to each certification authority, and maybe
> > some of them are now on holidays. 
> > Would be the option of putting the information in the public operating
> > procedure valid for you (meanwhile we put it on all CPS, get the approval to
> > publish, and so on)?
> 
> 
> I think the operating procedure is fine. Our requirement is that the
> information be available in a public and audited document.

That’s perfect, on Monday we will work on completing the public procedure and hope to have it uploaded to the web on Tuesday (I will post when it’s done).     


> 
> 
> I have another question...
> 
> In the CPS there is information about class 1 and class 2 certificates. Are
> SSL certificates issued for both class 1 and class 2? I'm not sure I
> understand what class 1 certificates are.

Well, class 1 are certificates issued only to public administrations or to people that have a direct work contract with them (these are public employees). And class 2 are certificates issued to citizens. In the specific case of server certificates we only issue class 1 certificates; for example when we get a request for a class 2 server certificate we redirect them to another certification authorities such as: camerfirma, firmaprofesional, verisign etc.

Comment 72

[Kathleen Wilson]

(In reply to Francesc Ferré from comment #71)
> > 
> > In the CPS there is information about class 1 and class 2 certificates. Are
> > SSL certificates issued for both class 1 and class 2? I'm not sure I
> > understand what class 1 certificates are.
> 
> Well, class 1 are certificates issued only to public administrations or to
> people that have a direct work contract with them (these are public
> employees). And class 2 are certificates issued to citizens. In the specific
> case of server certificates we only issue class 1 certificates; for example
> when we get a request for a class 2 server certificate we redirect them to
> another certification authorities such as: camerfirma, firmaprofesional,
> verisign etc.


In the General CP: "3.2.2.3.1 Requirements for class 1 certificates
It is not required to carry out an authentication procedure of the titular organization of the certificate for class 1 certificates, because these are corporative certificates where the subscriber organization of the certificate is the same than the Registration Entity."

I don't understand what this means. My notes indicate that SSL certs are OV, but that would mean that the organization verification is performed as well as the domain ownership/control verification.


Then section, 3.2.2.3.2 "Requirements for class 2 certificates", provides a high level description of identity, organization, and domain name verification. Is it correct to say that this section does not apply to the issuance of SSL certificates because CATCert does not issue class 2 SSL certs?

Comment 73

[Francesc Ferrer]

(In reply to Francesc Ferré from comment #71)

> > Nowadays, the
> detail of the information about the automatic controls
> > (verification of
> domain format and anti-phishing) is only in the
> > administration procedure
> (document not public for security reasons). We
> > should quickly add the
> information about those automatic controls  in the
> > public operating
> procedure, but changing the CPS would require a little more
> > time,
> because in order to change CPS we need the final approval of all the
> >
> political partners associated to each certification authority, and maybe
> >
> some of them are now on holidays. 
> > Would be the option of putting the
> information in the public operating
> > procedure valid for you (meanwhile
> we put it on all CPS, get the approval to
> > publish, and so on)?
> 
> 
> I
> think the operating procedure is fine. Our requirement is that the
>
> information be available in a public and audited document.

> That’s perfect,
> on Monday we will work on completing the public procedure and hope to have
> it uploaded to the web on Tuesday (I will post when it’s done).     

We have already uploaded a more complete public operation procedure for registry entities, you can found it on URL: http://www.catcert.cat/web/cas/1_0_2_er_tcat.jsp and clicking at the "Procedimientos" link at the end of the page, inside you will find the document: D1132-PO-00-procediment_operatiu_ER _T-CAT_20110808.pdf , and inside of the document at point 1.3.2.6 there is the next explanation (translated to english): 



1.1.1.1 Verification of the data of server certificates containing public URLs 

When receiving requests for server certificates that include a public URL, the person in charge of the ER T-CAT will verify the server URL and the data using the WHO IS service (http://www.whois.net and http://www.internic.net/whois.html for domains .cat).The result will be converted to PDF format and digitally signed. A copy in digital format will be saved and another one will be printed and attached to the request file.

The person in charge will validate that the domain belongs to the same organization that requests the certificate. If it does not, the process must be stopped and the owner of the domain indicated by WHOIS and the responsible for the certificate requesting organization  must be contacted in order to validate the correctness of the domain before generating the certificate.

Otherwise the application also performs automatic controls on the quality of the URL domain, such as:

- the automatic validation that the domain is a Fully Qualified Domain Name (FQDN) as the syntax: <subdomain>. <domain>. <tld> , for example: "www.catcert.cat"

- it is  automatically validated that the URL of the domain is:
            • not included in the AntiPhishing list  www.phishtank.com
            • not included in any previous certificate issued by CATCert and  
              revoked by phishing reason

This anti-phishing control is done in each step of the flow, from the initial request to the final generation, because a domain can enter the anti-phishing lists  at any time.

Comment 74

[Francesc Ferrer]

(In reply to Kathleen Wilson from comment #72)
> (In reply to Francesc Ferré from comment #71)
> > > 
> > > In the CPS there is information about class 1 and class 2 certificates. Are
> > > SSL certificates issued for both class 1 and class 2? I'm not sure I
> > > understand what class 1 certificates are.
> > 
> > Well, class 1 are certificates issued only to public administrations or to
> > people that have a direct work contract with them (these are public
> > employees). And class 2 are certificates issued to citizens. In the specific
> > case of server certificates we only issue class 1 certificates; for example
> > when we get a request for a class 2 server certificate we redirect them to
> > another certification authorities such as: camerfirma, firmaprofesional,
> > verisign etc.
> 
> 
> In the General CP: "3.2.2.3.1 Requirements for class 1 certificates
> It is not required to carry out an authentication procedure of the titular
> organization of the certificate for class 1 certificates, because these are
> corporative certificates where the subscriber organization of the
> certificate is the same than the Registration Entity."
> 
> I don't understand what this means. My notes indicate that SSL certs are OV,
> but that would mean that the organization verification is performed as well
> as the domain ownership/control verification.
> 


Yes, this point refers to the case that the Registry entity organization requests certificates to itself. In this case, the organization doesn’t have to apply controls to authenticate to itself because this identity is already well known. For example, when the registry entity of the Barcelona Council has to request certificates to itself it doesn’t have to verify the existence of the Barcelona Council as an organization. 

Furthermore, there are specific requirements to SSL sever certificates in each CPS that complement the general CP, for example if you go to point 3.2.2.1.1.3 at the EC-AL CPS (http://catcert.cat/descarrega_cas/oficina_politicas/D1111_N-DPC-EC-AL_v3r6_cas.pdf), you can see that in case of server certificates it must be validated, in all cases, that:

-	The server exists 
-	The domains ownership
-	The authorization of the organization in order to issue the certificate



> 
> Then section, 3.2.2.3.2 "Requirements for class 2 certificates", provides a
> high level description of identity, organization, and domain name
> verification. Is it correct to say that this section does not apply to the
> issuance of SSL certificates because CATCert does not issue class 2 SSL
> certs?

Yes, it is, but if some day the “comercial” strategy of CATCert changes in order to issue certificates to private corporations, then they would apply (I don’t think this is going to happen).

Comment 75

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 76

[Kathleen Wilson]

I am now opening the first public discussion period for this request from CATCert to add the “EC-ACC” root certificate, and turn on the websites trust bit.

For a description of the public discussion phase, see 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “CATCert Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of CATCert must promptly respond directly in the discussion thread to all questions that are posted.

Comment 77

[andreawngfld]

Attachment: Wrong issued certificates

see first discussion

Comment 78

[andreawngfld]

Attachment: wrong issued certificates

See first discussion

Comment 79

[Francesc Ferrer]

(In reply to andreawngfld from comment #78)
> Created attachment 556371 [details]
> wrong issued certificates
> 
> See first discussion

The controls that verify the correctness of the domain names where implanted this year just before the EV seal achievement, but unfortunately these are certificates issued before. On Monday we are going to investigate the number of certificates issued with internal IP or with incorrect FQDN form, and will discuss with our direction in order to find the way to revoke them with the minimum technical and political impact for our clients, because some of these certificates are probably used in production environments that should not stop. We will inform here with the progress of each step to solve this problem.

Comment 80

[Kathleen Wilson]

Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 81

[Manel Rella]

(In reply to Kathleen Wilson from comment #80)
> Please review the CA Communication that was recently sent, and is available
> here: https://wiki.mozilla.org/CA:Communications
> 
> Please add a comment to this bug to provide your response to the action
> items listed in the CA Communication. For more information about action
> items #1 and #3, please see items #6 and #7 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices


Hi Katheleen, we have covered the basis of all the items, if you need more information we can prepare a sum up of the controls and send directly to your email address.

Comment 82

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Added info regarding controls for cert issuance and registry entities.

Comment 83

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “EC-ACC” root certificate and turn on the websites trust bit.

Section 4 [Technical]. I am not aware of instances where CATCert has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. CATCert appears to provide a service relevant to Mozilla users:  It is a public company that serves as the government CA of the Region of the Autonomic Community of Catalunya in Spain.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the CP, DPC for each subCA, and the Operative Procedure. The documents are in Spanish and Catalan. English translations of some sections have been provided.

Document Repository: http://www.catcert.cat/registre
CP: http://www.catcert.cat/web/cat/5_1_politica_general.jsp
DPC (Declaración de Prácticas de Certificación) for each sub-CA: 
http://www.catcert.cat/web/cat/5_2_declaracio.jsp
Operative Procedure: 
http://www.catcert.cat/descarrega/ER_T_CAT/Procediments.zip
File: D1132-PO-00-procediment_operatiu_ER _T-CAT_20110808.pdf

Section 7 [Validation]. CATCert appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: SSL certificates are only issued to the limited well-known public governments and administrations of Catalonia. The subCAs that can issue SSL certs are EC-SAFP, EC-AL, EC-UR, EC-URV, and EC-Parlamant. Their DPC documents have the following in section 3.2.2:  For device certificates secure server and domain controller, in addition to checking has been carried out by the organization responsible for the secure server is checked: 
** The existence of the server. 
** Ownership of the domain name from the registry. 
**Authorization for the organization of the issuance of the certificate on the server.
Verification of SSL certificate subscribers requires a manual step of identity/organization verification. Additionally,CATCert has automatic blocks in place for high-profile domain names.

* Email: N/A. Not requesting the email trust bit at this time.

* Code: N/A. Not requesting the code signing trust bit at this time. 

Section 15 [Certificate Hierarchy]. This root has internally-operated subordinate CAs. The subCAs are used to distinguish who the certificates are issued to.  
** The EC-idCAT subCA issues certificates to Catalan citizens. It does not issue SSL certificates to other administrations (except itself SSL certificate for the www.idcat.cat domain).  
** The EC-SAFP (sub-CA of EC-GENCAT), EC-AL (Administracions Locals de Catalunya), and EC-Parlament (Parlament de Catalunya) subCAs only issue certificates to the civil servants and computers or devices of the Regional Catalan government, the Catalan Government, and the Catalan Parliament.  Including city and town councils, regional councils, county councils, as well as autonomous agencies and public funded companies.
** The EC-UR (Universitats i Recerca) and EC-URV (Universitat Rovira i Virgili) subCAs only issue certificates to employees, students and computers or devices of Catalan universities and research centers connected to the “Anella Científica” group, and the Universitat Rovira i Virgili (URV).

* RAs are external to CATCert but they belong to the Catalan Public Administration. It means they have in common the application of the controls specified at the Spanish Law 30/92 about procedures of the Public Administration. These RAs sign a contract with CATCert, and their way of working is periodically audited using the clauses of the contract.

* Both CRL and OCSP are provided under this root
** CP section 4.9.7.2: The Certification Body shall issue a Linked CRL at least every 24 hours.

Section 8-10 [Audit]. Audits have been performed by Ernst & Young according to the WebTrust CA and WebTrust EV criteria. The audit reports are posted on the cert.webtrust.org website: https://cert.webtrust.org/ViewSeal?id=1063 and https://cert.webtrust.org/ViewSeal?id=1189 
Note: Not requesting EV treatment at this time.

Based on this assessment I intend to approve this request to add the “EC-ACC” root certificate and turn on the websites trust bit.

Comment 84

[Kathleen Wilson]

To the representatives of CATCert: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

As per the summary in Comment #83, and on behalf of Mozilla I approve this request from CATCert to include the following root certificate in Mozilla products:

* EC-ACC (websites)

I will file the NSS bug to effect the approved changes.

Comment 85

[Kathleen Wilson]

I have filed bug #707995 against NSS for the actual changes.

Comment 86

[Manel Rella]

I update the bug with the webtrust renew link:  https://cert.webtrust.org/ViewSeal?id=1238

Comment 87

[Kathleen Wilson]

EC-ACC is a "Builtin Object Token" in FF 11.

Comment 88

[Francesc Ferrer]

Dear Kathleen, 

Please, update Mozilla's spreadsheet of included root certificates with the following information: 

  URL to Test Website: https://www.aoc.cat/
  Company Website : http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert 
  Certificate Policy (CP) : http://www.aoc.cat/content/download/25607/46726/file/politicaGeneralCertificacioAngles.pdf 
  Certification Practice Statement (CPS): http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert/Regulacio 

  Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf
  Baseline Requirements Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf             
  EV Audit : https://cert.webtrust.org/SealFile?seal=1648&file=pdf        
  Auditor : Ernst & Young               
  Audit Criteria : WebTrust            
  Audit Statement Date : 2014/03/10

Comment 89

[Kathleen Wilson]

(In reply to Francesc Ferré from comment #88)
> Dear Kathleen, 
> 
> Please, update Mozilla's spreadsheet of included root certificates with the
> following information: 
> 
>   URL to Test Website: https://www.aoc.cat/
>   Company Website :
> http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert 
>   Certificate Policy (CP) :
> http://www.aoc.cat/content/download/25607/46726/file/
> politicaGeneralCertificacioAngles.pdf 
>   Certification Practice Statement (CPS):
> http://www.aoc.cat/Inici/SERVEIS/Signatura-electronica-i-seguretat/CATCert/
> Regulacio 
> 
>   Audit : https://cert.webtrust.org/SealFile?seal=1647&file=pdf

Done.

>   Baseline Requirements Audit :
> https://cert.webtrust.org/SealFile?seal=1647&file=pdf 


Maybe I'm missing something, but I don't see reference to the Baseline Requirements audit in this file.
http://www.webtrust.org/homepage-documents/item72056.pdf
            
>   EV Audit : https://cert.webtrust.org/SealFile?seal=1648&file=pdf        

This root is not enabled for EV.

Thanks,
Kathleen

Comment 90

[Francesc Ferrer]

Dear Kathleen,

We would like to enable this root for EV. How do we have to proceed?. Do we have to create a new bug for this request or we can just keep on using this one?. 

Thank you,

Francesc,

Comment 91

[Kathleen Wilson]

Please file a new bug.
https://wiki.mozilla.org/CA:How_to_apply#Enable_EV_for_an_included_root

Comment 92

[Kathleen Wilson]

Attachment: 2015-WebTrustCA-EC-ACC.PDF