361957 - Add Izenpe CA EV root certificate (Spain)

Status: RESOLVED FIXED

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

Description

[Iñigo Barreira]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1) Gecko/20061010 Firefox/2.0

Izenpe is a spanish CA which recently obtained the ISO 27001 and the ETSI TS 101 456 certificates and wants to be included in Mozilla

Reproducible: Always

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request.

Comment 2

[Gervase Markham [:gerv]]

Iñigo: as you may know, we have a policy defining how we accept root certificates into our store:
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html

Please, for your application, could you provide all the information requested in section 14?

Gerv

Comment 3

[Iñigo Barreira]

All,

I´ve send all the CA certificates requested to [e-mail], including the CPS and the ISO and ETSI certifications.

Everything is on the Izenpe web site for you to check.

Regards

Comment 4

[Gervase Markham [:gerv]]

Inigo: please can you post a copy of that message and information on this bug? Thanks :-)

Gerv

Comment 5

[Iñigo Barreira]

Hi,

you can find the root certificates available on the web site (www.izenpe.com). The web is only in Spanish and in Basque.
Anyway, here is a link to the certificates except one: https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp
The missing one is in: http://www.izenpe.com/s15-4812/es/contenidos/informacion/sw_instal_nr/es_software/arch_sw_instal_nr.html
And then click on the first one, called “certificado”. 

Attached you will find all the certificates (the same that you can download from the web site as mentioned above) we want to have included in a zip format.

Our CPS is on the web site public for everyone (you can check it out in www.izenpe.com/cps) and attached the ETSI TS 101 456 and ISO 27001 certifications (check out also the web site www.izenpe.com). The CPS is only in Spanish and Basque, but we have a new version to publish soon in english, do you want it?

I will update this info in the bug #361957 I submitted time ago.

I look forward to hearing from you soon

Best regards

Comment 6

[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."

This bug is 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 7

[Gervase Markham [:gerv]]

Attachment: CA certificates.zip

Comment 8

[Gervase Markham [:gerv]]

Attachment: IZENPE, S.A.IS 504989.Leg.En.doc

Comment 9

[Gervase Markham [:gerv]]

Attachment: IZENPE, S.A.IS 504989.Pres.En.doc

Comment 10

[Iñigo Barreira]

Hi Gerv,

thanks for your answer.

The only thing I can say related to this is that you can apply the same resolution you did with other Spanish CAs like Camerfirma (private company) and Catcert (public) for example. 

Looking forward to hearing from you

Regards,

Iñigo B.

Comment 11

[Gervase Markham [:gerv]]

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

Gerv

Comment 12

[Iñigo Barreira]

Hi Gerv,

what does it mean? What do I need to do?

regards

Comment 13

[Gervase Markham [:gerv]]

Iñigo: nothing, don't worry :-)

Gerv

Comment 14

[Iñigo Barreira]

Gerv,

what about Extended Validation on SSL certificates. What do we need to do?

Regards

Comment 15

[Gervase Markham [:gerv]]

Inigo: the Mozilla Foundation has not yet started enabling CAs for EV. When and if we do, I expect an EV audit will be required, as defined by the CAB Forum.

Note that membership of the CAB Forum is now open to CAs with an ETSI audit, which means you. Contact [e-mail].

Gerv

Comment 16

[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 17

[Iñigo Barreira]

Hi Gerv,

I´ll do it again. I will send what you ask for the CA root and the subordinates. All the info you can also find in the attachements and in the Izenpe web site. Some of the requests can´t be answered because we don´t have yet, for example EV. And about CPS, it´s only in spanish and basque but we´re preparing a new one in english.

CA DETAILS
----------

CA Name: izenpe.com

website: www.izenpe.com

Summary: We´re a public company belonging to the Basque Country Government so the general nature is government. The primary geographical area is the Basque Country but all of our certificates are recognized and accepted and validated by the totally of the PKIs in Spain, so the geographical area relates to Spain. We have 4 subordinates CAs, all of them dedicated to the citizenship or the companies.

audit type: ETSI TS 101 456

auditor: BSI

auditor website: www.bsi-global.com

audit documents URL: they´re kept locally.

CERTIFICATE DETAILS
-------------------

We have a root CA  and four second level CA that issue certificates for end users. 

Root CA 
-------
Subject	E = [e-mail]
CN = Izenpe.com
L = Avda del Mediterraneo Etorbidea 3 - 01010 Vitoria-Gasteiz
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
C = ES
Validity dates	from 31/1/2006 until 31/1/2018
SHA1 thumbprint	4a 3f 8d 6b dc 0e 1e cf cd 72 e3 77 de f2 d7 ff 92 c1 9b c7
Extended Key Usage	this root does nos issue user certificates, it only signs ARL and signs second level CA certificates
Key length	2048 bits
CPS URL	http://www.izenpe.com/cps

Certificate policy URL	http://www.izenpe.com/cps


Citizen and Entity CA, qualified certificates 
---------------------------------------------
Subject	E = [e-mail]
CN = Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades
OU = NZZ Ziurtagiri publikoa - Certificado publico SCI
L = Avda del Mediterraneo Etorbidea 3 - 01010 Vitoria-Gasteiz
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
C = ES
Validity dates	from 4/2/2003 until 4/2/2013
SHA1 thumbprint	b9 ca b0 0e 41 38 06 aa 3f ea 3a 5b 28 f9 bb 39 e7 ef 15 0a
Extended Key Usage	SSL client
e-mail
Key Length	2048 bits
CRL http URL	http://www.izenpe.com/cgi-bin/arl

OCSP URL	http://ocsp.izenpe.com:8094

CPS URL	http://www.izenpe.com/cps

Certificate policy URL	http://www.izenpe.com/cps



Citizen and Entity CA, non qualified certificates 
-------------------------------------------------
Subject	E = [e-mail]
CN = Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (2)
L = Avda del Mediterraneo Etorbidea 3 - 01010 Vitoria-Gasteiz
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
C = ES
Validity dates	From 14/6/2006 until 30/1/2018
SHA1 thumbprint	b0 6d b1 3a 6d ee 5a 3b 02 52 94 16 e0 b8 8c f2 26 8b 93 64
Extended Key Usage	SSL Server
SSL client
E-mail
code signing
Key Length	2048 bits
CRL http URL	http://www.izenpe.com/cgi-bin/arl

OCSP URL	http://ocsp.izenpe.com:8094

CPS URL	http://www.izenpe.com/cps

Certificate policy URL	http://www.izenpe.com/cps


Public Adminstration qualified certificates CA
----------------------------------------------
Subject	E = [e-mail]
CN = EAEko HAetako langileen CA - CA personal de AAPP vascas
OU = AZZ Ziurtagiri publikoa - Certificado publico SCA
L = Avda del Mediterraneo Etorbidea 3 - 01010 Vitoria-Gasteiz
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
C = ES
Validity dates	From 8/4/2003 until 8/4/2013
SHA1 thumbprint	85 6b ee 62 fc 8e 99 b9 a6 5c 15 29 02 09 be f9 87 ed e4 e4
Extended Key Usage	SSL client
e-mail 
Key length	2048 bits
CRL http URL	http://www.izenpe.com/cgi-bin/arl

OCSP URL	http://ocsp.izenpe.com:8094

CPS URL	http://www.izenpe.com/cps

Certificate policy URL	http://www.izenpe.com/cps








Public Adminstration non qualified certificates CA
--------------------------------------------------
Subject	E = [e-mail]
CN = EAEko Herri Administrazioen CA - CA AAPP Vascas
OU = AZZ Ziurtagiri publikoa - Certificado publico SCA
L = Avda del Mediterraneo Etorbidea 3 - 01010 Vitoria-Gasteiz
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
C = ES
Validity dates	From 4/2/2003 until 4/2/2013
SHA1 thumbprint	7b 11 62 cc 37 dc 3d 43 db ef 46 b9 d6 05 fb 6f 93 f2 18 38
Extended Key Usage	SSL Server
SSL client
E-mail
code signing
OCSP
TSA
Key length	2048 bits
CRL http URL	http://www.izenpe.com/cgi-bin/arl

OCSP URL	http://ocsp.izenpe.com:8094

CPS URL	http://www.izenpe.com/cps

Certificate policy URL	http://www.izenpe.com/cps

Comment 18

[Iñigo Barreira]

Attachment: CA Information

Comment 19

[Iñigo Barreira]

Gerv,

also included a new attachment with this info for you to read better. About audit done, ETSI, this is done by KPMG from The Netherlands, but it was adquired by BSI, that´s why I wrote it down. But the guys are from KPMG.

we also have a technical CA which is not mentioned in this report because it´s only for SSL certificates and I´m not sure this is related to this subject. Let me know, please

Regards

Comment 20

[Gervase Markham [:gerv]]

Thank you for that information. Some questions/points:

- It helps greatly if you fill in the form given rather than inventing your own :-)

- Note that we do not include intermediate certificates in our store. These need to be served by the webserver in question. (This is what the standard says should happen.)

- I need an HTTP URL to your root certificate on your website.

- Can I confirm that your root certificate is X509 version 3?

- Do you issue domain validation (DV) certificates as well as organisationally validated (OV) certificates? Do you have plans to issue extended validation (EV) certificates?
(Definitions: http://wiki.mozilla.org/EV)

- What type of certificates are you planning to issue (email/SSL/code)?

- We need a public statement from your auditor to prove that you passed the ETSI audit. Are there documents available to show this?

Thanks,

Gerv

Comment 21

[Iñigo Barreira]

Hi Gerv,

These are the answers:

- you can use the www.izenpe.com website and click on the "descarga de certificados" button on the left and you´ll see the complete tree of Izenpe´s certificates. Anyway, this is a direct link. https://servicios.izenpe.com/certificados/ca_raiz.crt
- Yes, I can confirm it. Just dowload the certificate and see in the details the version 3
- We don´t know what DV and OV are so I can´t answer. About EV, we´d like to issue it but I don´t know the procedure to do it. 
- As you can see in the certificate´s tree, we have defined 2 levels, the first one with the CA root and below it, 4 subordinates CAs. In these we issue email, SSL, code signing, etc.
- In the website (www.izenpe.com) you can check it out by clicking on the "certificaciones" link on the left. You´ll see the ETSI and the ISO certifications.

Thanks in advance

Iñigo B.

Comment 22

[Iñigo Barreira]

Gerv,

after reading the wikipedia, we can confirm that we issue DV and OV certificates. We check the domains and we also check the business entity that holds the certificate.

Now, i´m going to see what to do to have the EV.

Regards

Iñigo

Comment 23

[Iñigo Barreira]

Gerv,

after checking the EV information, we´d like to be part of the forum, to be a member and be included in the CAs members. We´d also like to know what to do exactly to issue EV certificates. What we should change in our certificates to do that, if needed?

Regards

Comment 24

[Gervase Markham [:gerv]]

Inigo: Contact [e-mail] for questions about EV. The version 1.0 standard and audit guidelines can be downloaded from cabforum.org.

Gerv

Comment 25

[Iñigo Barreira]

Gerv,

I did it on May the 9th and have no answer yet. I also downloaded the guidelines but don´t know exactly what to do.

I´ll try again

Thank you

Comment 26

[Gervase Markham [:gerv]]

Inigo: I missed one question. What would you like your certificate to be called (the "friendly name") in Firefox?

Does BSi make your ETSI certificate available from its website? Or provide any way of confirming that your certificate was, in fact, issued by them and continues to be valid?

Thanks,

Gerv

Comment 27

[Iñigo Barreira]

Hi Gerv,

we´d like the name "izenpe", easy isn´t it?

About the other question, I don´t really know. I know that there´s one about ISO 27001 (www.iso27001certificates.com). I asked the auditors (KPMG) and they don´t know if there´s any website where you can check the certifications.
Anyway, I keep searching

Regards

Comment 28

[Gervase Markham [:gerv]]

"izenpe" with a lower-case i?

Gerv

Comment 29

[Iñigo Barreira]

Yes

Comment 30

[Iñigo Barreira]

Gerv,

how this is going? Any news?

Regards

Comment 31

[Gervase Markham [:gerv]]

Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv

Comment 32

[Iñigo Barreira]

Attachment: new root CA with 2 certs with sha1 and sha2

We´ve have updated our root CA to be used with certs with sha256 algorithm for security reasons. We´ll keep the old one with sha1.

Comment 33

[Iñigo Barreira]

Franck,

attached is the new Izenpe root CA. There´re 2 certs with algorithms sha1 and sha2. 
Take into account this change for the Mozilla root program

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the information in this request is incomplete. 
The request is waiting for more information from the applicant.

Comment 35

[Iñigo Barreira]

Hi Nelson,

and what is left? I can´t see what you´re asking for. 
Please, let me know.

Regards

Comment 36

[Nelson Bolyard (seldom reads bugmail)]

Hi, I don't know why this bug is listed as incomplete on the pending page.
Frank, can you tell us what information is missing from this request?

Comment 37

[Iñigo Barreira]

Hi there,

this is an update of the CPS and in english for a better checking.
http://www.izenpe.com/s15-4812/es/contenidos/informacion/administracion_vasca/es_8927/adjuntos/DPC_4.1_in.pdf

Regards

Comment 38

[Iñigo Barreira]

Frank, Nelson,

I have another question that just sent to Johnathan and he forwarwed to you. We´ve just issued an EV SSL test certificate in our development system and I´d like to verify, prior to going into production and pass the webtrust audit, if it´s ok for you and could be pointed as an EV or you consider that somethig´s left.
Attached is the test certificate.

Regards

Comment 39

[Iñigo Barreira]

Attachment: SSL EV test cert done with an IIS6

Comment 40

[Nelson Bolyard (seldom reads bugmail)]

During its lifetime, this RFE has morphed into an EV cert request.

Comment 41

[Iñigo Barreira]

Nelson,

what I would like first is to have our CA root included in the firefox 3 release and after that we´ll apply for the inclusion of the EV.
We don´t have our EV certs in production yet so at the momento we only want to have our CA root included.

Would it be possible to be included asap? in the new release? I have to let my manager know the current situation

Regards

Comment 42

[Johnathan Nightingale [:johnath]]

I was talking to Iñigo today and he says that the WebTrust audit should be available shortly.  He will attach it here soon, as I understand it.

Comment 43

[Iñigo Barreira]

Attachment: Izenpe webtrust for EV audit report

Comment 44

[Iñigo Barreira]

Guys,
I´ve just attached the webtrust for EV audit report made by KPMG in order to speed up this processing (it´s more than 2 years to be included) and hopefully have our root in the Firefox asap

Regards,
Iñigo B.

Comment 45

[Iñigo Barreira]

What the hell is going on with this request? I can´t beleive this. I´m terrible upset with this situation.
We´re a government CA and we have lots of complaints of citizens asking for a solution and I can´t say anything but we´re working on it. We have lots of complaints saying that we work for Microsoft but I can only say we´re working on it. The politicians are asking us about the situation and I must answer the same. I´m tired of this situation.
In the CAB Forum Jonathan told me that the EV request were going to be treated as urgente when the new release 3 is on the market. I´m waiting for almost 3 years and a couple of months since I sent the webtrust for EV audit. What else can I do? Just let the citizens know the way you work? 
This is frustating.
I´d like to have an answer ASAP!!! an answer that says, eh, this is going to be in this date and have that date for sure so I could say something realistic and not like now in which I can´t say anything.

Bye now

Comment 46

[Julen Ruiz Aizpuru]

Apart from that, this situation affects directly to the users of the Basque (eu) localization, and probably to some of the Spanish (es-ES) too, providing a bad feeling in the user experience and all kinds of complaints.

CC'ing Staś. Staś: I'm not sure if you have something to do in this aspect but maybe you can help us to accelerate this process.

Comment 47

[Kathleen Wilson]

Accepting this bug, so we can procede with the information gathering and verification phase as described in
https://wiki.mozilla.org/CA:How_to_apply

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.

Comment 48

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attaching the initial information gathering document, which summarizes the information that has been gathered and verified.

Please review this document for accuracy and completeness, and respond to the questions/requests that are highlighted in yellow.

Comment 49

[Iñigo Barreira]

Hi there,

attached is the document with the answers. I think I´ve answered everything.

Regards

Comment 50

[Iñigo Barreira]

Attachment: Answers

Comment 51

[Kathleen Wilson]

Thank you for the information. 

1) Just to make sure I understand… Are there three roots that you want to include?
Specifically: 
One old root: Izenpe.com (4a:3f:8d:6b:dc:0e:1e:cf:cd:72:e3:77:de:f2:d7:ff:92:c1:9b:c7)
Two new roots, with EV-enablement for both:
Izenpe.com (30:77:9E:93:15:02:2E:94:85:6A:3F:F8:BC:F8:15:B0:82:F9:AE:FD)
And
Izenpe.com (2F:78:3D:25:52:18:A7:4A:65:39:71:B5:2C:A2:9C:45:15:6F:E9:19)

2) ARL/CRLs
Both http://crl.izenpe.com/cgi-bin/arl2 and http://crl.izenpe.com/cgi-bin/arl result in Error Code:ffffe095 when I try to import them into Firefox.
 ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION
Anyways, these look like the ARLs for the roots. Can you provide the URLs to the CRLs for the sub-CA’s, it’s probably better if I try those.

3) Additional info needed for EV
a) English translations of the Verification steps for EV certs, demonstrating compliance with 
http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 
b) EV Policy OID
c) Maximum OCSP response time, as pertaining to Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”

4) Please provide pointers to the sections (and translations into English) in the CP/CPS that demonstrate that reasonable measures are taken to verify the following information for end-entity certificates chaining up to these roots, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a)for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
b)for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; 
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

5) Test site for EV SSL cert
https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp
This website cert chains up to the old root. You can see this in Firefox by double clicking on the lock icon at the bottom right corner of the window.  I also need a website that uses an EV cert that chains up to the new root.

6) New (or date for new) ETSI audit
The ETSI 101.456 audit certificate is old.
http://www.izenpe.com/s15-12020/es/contenidos/informacion/acreditaciones/es_acredita/adjuntos/certificado_etsi.pdf
Do you have a new one, or when do you expect to have the new one?

Comment 52

[Iñigo Barreira]

Hi,

here are my answers:

1) yes, but technically the new root Izenpe 2007 is just one but signed with 2 algorithms, one is with SHA1 and the other is with SHA256. If you find any problem with this one, just not ship it.

2) Yes, you´re right. I thought you wanted the CRL/ARL of the root CA that you can find in the sub CA cert. For the CRL of the sub CA you must go to the end certs in which you can find the pointers to those CRLs. We have five sub CAs for the Izenpe root 2007 as you can check on the https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp
The number (2) is for the new hierarchy, the Izenpe 2007.

     
       1.- CA of CCEE rec: http://crl.izenpe.com/cgi-bin/crl
                           http://crl.izenpe.com/cgi-bin/crl(2)
       2.- CA of CCEE no rec: http://crl.izenpe.com/cgi-bin/crlscinr
                              http://crl.izenpe.com/cgi-bin/crlscinr(2)
       3.- CA of AAPP rec: http://crl.izenpe.com/cgi-bin/crlscar
                           http://crl.izenpe.com/cgi-bin/crlscar(2)
       4.- CA of AAPP no rec: http://crl.izenpe.com/cgi-bin/crlinterna
                              http://crl.izenpe.com/cgi-bin/crlinterna(2)
       5.- CA of SSL EV: http://crl.izenpe.com/cgi-bin/crlsslev


3) a.- attached in a word format
   b.- EV OID: 1.3.6.1.4.1.14777.6.1.1
   c.- The OCSP response time is inmediatly (when you revoke a certificate the  VA knows instantly) and it´s updated permantly because it´s asking the CA and gets all the information so no need to sincronize. The nextupdate is an optional field and our VA only uses that field if we use the CRL. Right now there´s no response in the nextupdate because we don´t need to update it because it´s always update at any time.

4) You can check our CPS in english in our web site but the CPS is in general, for specific certificates we have specific documentation. You can check point 4.2 in the CPS. But in general as we are a government CA and only issue certificates to the government entities most of the checks are performed by law, so we have to meet all the requirements that the spanish legislation provides.
For the SSL EV you can also check the attachment mentioned in you request 3a.

5) For testing poruposes, we have issued just 2 EV certificates. You can check www.ermua.es and mail.osatek.es

6) The ETSI certificate is not old, it has a validity of 3 years, and every year we have had audit surveillances from KPMG. This year, 2009, we have re-certification for another 3 years if we meet all the requirements and it´s scheduled for July. In the URL you mention, the ETSI document you can see the expiry date for August 1st 2009, so our ETSI audit is still valid.

Comment 53

[Iñigo Barreira]

Attachment: SSL EV validation procedure

Comment 54

[Iñigo Barreira]

Hi again,


The CRLs for the new hierarchy are wrong. The number (2) is not like that is just 2, here are the new CRLs, sorry for the mistake

1.- CA of CCEE rec: http://crl.izenpe.com/cgi-bin/crl
                           http://crl.izenpe.com/cgi-bin/crl2
       2.- CA of CCEE no rec: http://crl.izenpe.com/cgi-bin/crlscinr
                              http://crl.izenpe.com/cgi-bin/crlscinr2
       3.- CA of AAPP rec: http://crl.izenpe.com/cgi-bin/crlscar
                           http://crl.izenpe.com/cgi-bin/crlscar2
       4.- CA of AAPP no rec: http://crl.izenpe.com/cgi-bin/crlinterna
                              http://crl.izenpe.com/cgi-bin/crlinterna2
       5.- CA of SSL EV: http://crl.izenpe.com/cgi-bin/crlsslev

Also included an example of the fields of the OCSP

Certificate Status: revoked 
Revocation Time: 2006-03-21 08:25:16 
Revocation Reason: superseded 
Serial Number: 0x00A9E1 
This Update: 2009-05-05 22:12:13 
Next Update: Optional field not present 

And finally, the translation of the validation process for the EV is translated using the google translator as I was sick and couldn´t make it well I´ve just tried to do it faster. If there´s something you don´t understand, just let me know. We decided at Izenpe, translate the documentation into Enlgish just for you to have an easy way to check it and also for the auditors of the webtrust.

Regards

Comment 55

[Kathleen Wilson]

Thanks for the information.

>> including both the Sha256 and the Sha1 version of the same root
I’ll have to look into it and get back to you.

>> Translated SSL EV validation procedure
Please also provide a link to the original document (and the section or page number) where this text was translated from.

>> Audit
When audit reports are provided by the company requesting CA inclusion rather than having an audit report posted on the website such as cert.webtrust.org, the Mozilla process requires doing an independent verification of the authenticity of audit reports that have been provided.
Please send me the KPMG email address of the auditor who can confirm the authenticity of the WebTrust EV audit.  

>> section 7 of http://www.mozilla.org/projects/security/certs/policy/
This is always a sticking point for CA inclusion requests. There must be text in the CP/CPS for SSL end-entity cert issuance that states how the domain ownership is verified. There also must be text in the CP/CPS for email end-entity cert issuance that states how the email ownership is verified.  For code signing certs, there must be text in the corresponding CP/CPS that states how the cert requester is identified and verified to have authority to request the cert.
Please provide the corresponding document links, section numbers, and translated text.

The translated document for SSL EV validation procedure meets the requirement in regards to verification of domain ownership. However, this only applies to EV SSL certs. I also need the translated text for SSL (non-EV) verification procedures.
“The Internet domain (not applicable to internal domains) Query the whois database, verify that the domain is registered, consulting registrars valid. A copy of the printed record of the whois query validation.  There is a list of registrars supported by domain type (http://www.iana.org/domains/root/db/) and are generic (gTLD's) or country (country-code, ccTLDs), indicating Delegate is the official record for each domain. In particular, one can see the whois for the more usual  Domains. Com. Net. Org. Http://www.networksolutions.com/whois/index.jsp info Network Solutions Dominos. EsNIC is http://www.nic.es 
It verifies that the owner (registrant) agrees with the applicant organization. If no match, the applicant must provide documentation to support the right of use by the owner. IZENPE contact the owner listed in the whois to verify that the applicant has the right to use the domain or subdomain.”


>> CRL
I have tried to import the CRLs into Firefox. Here are the results that I get.
1.- CA of CCEE rec: 
http://crl.izenpe.com/cgi-bin/crl (imported without error, valid for 1 month)
http://crl.izenpe.com/cgi-bin/crl2 (Error Code:ffffe095)
2.- CA of CCEE no rec: 
http://crl.izenpe.com/cgi-bin/crlscinr (Error Code:ffffe095)
http://crl.izenpe.com/cgi-bin/crlscinr2 (Error Code:ffffe095)
3.- CA of AAPP rec: 
http://crl.izenpe.com/cgi-bin/crlscar (imported without error, valid for 1 month)
http://crl.izenpe.com/cgi-bin/crlscar2 (Error Code:ffffe095)
4.- CA of AAPP no rec: 
http://crl.izenpe.com/cgi-bin/crlinterna (imported without error, valid for 1 month)
http://crl.izenpe.com/cgi-bin/crlinterna2 (Error Code:ffffe095)
5.- CA of SSL EV: 
http://crl.izenpe.com/cgi-bin/crlsslev (Error Code:ffffe095)

Error code ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION
Please see https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

Also, the CRLs that I could import have a nextupdate of about 1 month. From Comment #50 I thought they would only be valid for 24 hours. Perhaps I misunderstood?

>> OCSP
When I go to the following website in Firefox with OCSP not enforced, it works.  However, when I enforce OCSP, I get the following error.
https://www.ermua.es/
Secure Connection Failed
An error occurred during a connection to www.ermua.es.
Invalid OCSP signing certificate in OCSP response.
(Error code: sec_error_ocsp_invalid_signing_cert)

Comment 56

[Iñigo Barreira]

Hi Kathleen,

we´re working on the new requests but one thing about the CRLs and the error code you´re getting.
As per RFC 5280 this extension must be set as critical and that´s what we´ve done although some of them (the old ones) are not set as critical due to the configuration process. Attached is the point in which is explained. So, I can change the configuration in order to improve the interoperability but I´d like to know if this is needed. Just let me know.

RFC 5280

5.2.5.  Issuing Distribution Point 

   The issuing distribution point is a critical CRL extension that 
   identifies the CRL distribution point and scope for a particular CRL, 
   and it indicates whether the CRL covers revocation for end entity 
   certificates only, CA certificates only, attribute certificates only, 
   or a limited set of reason codes.  Although the extension is 
   critical, conforming implementations are not required to support this 
   extension.  However, implementations that do not support this 
   extension MUST either treat the status of any certificate not listed 
   on this CRL as unknown or locate another CRL that does not contain 
   any unrecognized critical extensions.

Comment 57

[Nelson Bolyard (seldom reads bugmail)]

Iñigo,
The issue is not that the extension is critical.  
The issue is that it is _present_ in a full CRL.

Comment 58

[Kathleen Wilson]

Hi Iñigo,

I posted the question about whether or not to include both the SHA-1 and the SHA-256 roots to the Mozilla.dev.tech.crypto discussion board:

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/092212e4e21b1458#

The short answer is that there is benefit to including both roots.

Please review the discussion thread for the details, which include useful information.

Comment 59

[Kathleen Wilson]

After further investigation and discussion, we have the following information.

The notBefore and notAfter dates of the SHA1 root are 
12/13/2007 5:08:27 AM 
12/13/2037 0:27:25 AM 

The notBefore and notAfter dates of the SHA256 root are 
12/13/2007 5:08:28 AM 
12/13/2037 0:27:25 AM 

NSS will always pick the SHA256 root, because its NotBefore date is one second later than that of the SHA1 root. Therefore, there does not appear to be any benefit in including both the SHA1 and the SHA256 roots.

Please review the discussion thread for the details, and for information about the benefit/downside of including either the SHA256 root or the SHA1 root.

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/092212e4e21b1458#

After reviewing the discussion, please indicate here whether you want to include the SHA1 root or the SHA256 root.

Comment 60

[Iñigo Barreira]

Ok, it´s perfect for me, the same happened with Microsoft Internet explorer and Opera, so include only the SHA-256

Comment 61

[Iñigo Barreira]

About the missing answers, here they are (sorry for the delay).

1.- CRLs

I think there´s been a misunderstood. Let me explain. Our CRLs have a validity of 10 days now (1 month when I wrote last post) and are refreshed every 1 day, so, if there aren´t revocations, everday we have a new CRL and if there´s one revocation, inmediatly we issue a new CRL.
About the problems with the CRLs (the critical extension), those must be fixed. We´ve followed your recommendations. Please, try and let me know.

2.- OCSP
The problem with the OCSP is more complex. We have a Technical CA that signs the VA and TSA, but this is for the old hierarchy, we can´t migrate to the new 4k hierarchy until all the applications of our partners and clients are migrated because if we do, we can have inconsistencies and issues. So at the moment, that´s what we have.

3.- Specific documentation in english.
Attached. It´s translated very quick and I think it´s not a good one, by maybe enough. I haven´t had enough time.

4.- Contacts at KPMG
Patrick Paling: [e-mail]
Emmanuel Van der Huslt: [e-mail]

5.- CPS
In the CPS we don´t mention specific information of any certificate, that´s why we have the specific documentation.

I think this is everything, please let me know aditional requirements.

Best regards
Iñigo

Comment 62

[Iñigo Barreira]

Attachment: SSL EV specific documentation

Comment 63

[Kathleen Wilson]

Attachment: Old Root

Comment 64

[Kathleen Wilson]

Attachment: New Root Sha-256

Comment 65

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Attaching the updated Information Gathering Document, indicating what information has been gathered and verified, and the highlighted sections indicate where further clarification or information is still needed.

> CRLs
I can now import the CRLs into Firefox without error.

> WebTrust EV Audit
I have sent email to KPMG to confirm the authenticity of the audit report as per Mozilla policy.

> In the CPS we don´t mention specific information of any certificate, 
> that´s why we have the specific documentation.
Please provide the specific urls to the CP/CPS for issuance of email, SSL, EV SSL, and code signing certs. For each document, please clearly indicate the types of certs that it covers. Please also indicate which sections refer to the validation procedures for each type of cert.

Comment 66

[Iñigo Barreira]

Hi Kathleen,

I don´t understand your last question. The CPS is available in www.izenpe.com/cps but the specific documentation of any certificate issued by Izenpe is not in the web and it´s not available in general. It´s only information on how to proceed for us, our 3rd parties and the auditors, and you if you request, as I did it with the EV specific documentation. But for those certificates, everything is in spanish. By the way , what do you mean with "issuance of email"?. We have specific documentation for SSL , SSL EV and Code signing and it covers those certs. The validation procedure is always the same for all the certs issued by Izenpe and it´s reflected in the CPS.

Regards

Comment 67

[Eddy Nigg (StartCom)]

Hi Iñigo,

I had a quick look at your CPS and it appears that it doesn't disclose how your CA validates the various attributes of the certificates. This might be a problem as disclosure in the practice statements is usually required. This is what the auditor confirms. Without disclosure, Mozilla can't know for certain if your CA complies to the Mozilla CA policy. Hope this helps.

Comment 68

[Kathleen Wilson]

I have exchanged email with KPMG to confirm the authenticity of the WebTrust EV Readiness audit report.

Eddy’s statement in comment #67 is correct. In order to proceed, there needs to be publicly accessible and audited documentation about the verification procedures that meet section 7 of the Mozilla CA Certificate Policy at http://www.mozilla.org/projects/security/certs/policy/.

Section 7 is as follows:
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: 
a) for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; 
b) for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf; 
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; 
d) for certificates to be used for and marked as Extended Validation, the CA complies with Guidelines for the Issuance and Management of Extended Validation Certificates (as modified by the erratum published by the CAB Forum) (or, for CA requests submitted on or before June 30, 2008, draft 11 of these guidelines), and has its compliance attested to in accordance with the requirements of Section J of that document. 
--

I believe that you have provided the English translation of the part of a document that satisfies part d, for EV. However, I still need the pointer to the original (Spanish, publicly available and audited) version of this text.

For part a, if the Email trust bit is to be enabled, there needs to be publicly available and audited text (the original, Spanish version) that demonstrates verification of the ownership/control of the email account to be included in the certificate.

For part b, if the Websites trust bit is to be enabled, there needs to be publicly available and audited text (the original, Spanish version) that demonstrates verification of the ownership/control of the domain referenced in the certificate.

For part c, if the Code Signing trust bit is to be enabled, there needs to be publicly available and audited text describing the procedures for verifying the identity/authorization of the entity referenced in the certificate.

Comment 69

[Iñigo Barreira]

Hi Kathleen,

this annoys me, you´re making me a paralell audit.

Anyway, all the verification process is the same for all the certifications. Attached is a brief description sent to the spanish ministy of industry. I will also try to attach all the technicall information of our VA, which is connected via NTP to the Royal Observatory of the Spanish navy (an atomic clock) which at the same time is connected to the atomic clock sited in Switzerland in the measures and weights organization (I can´t remember the exact name). Besides, we also have a GPS anthenna in the roof for "comparing" the times.
Anyway, now I´m in Frankfurt and can´t provide all the information but i´ll do it on monday.

According to all the certificates we issue, all the info is available in the Izenpe web site, procedures, request form, revocation form, etc. They´re only in spanish and in basque, and we´re not going to translate them into english. I did only with the SSL EV because you were asking a lot of questions, and to facilitate your work but we are limited by law to issue certificates only in Spain.
In this link

http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/solicitar_certificado_digital.html

you can find all the specific CPS (we call DPC because it´s the spanish translation) of all the certs we issue.

Izenpe provides CRL and OCSP validation for free and it´s indicated into the attributes of the certificates, in the crl distribution point and in the authority info acces respectivily in which we provide the access method and the access location.

About the audit you mention, Izenpe is certified in ETSI TS 101 456, among others, which only applies to issue qualified certificates, and code signing and SSL Certs are not qualified.

Regards

Comment 70

[Iñigo Barreira]

Attachment: OCSP brief description

Comment 71

[Iñigo Barreira]

Hi again,

that happens for not sleeping enough due to the jet lag and that´s why i misunderstood your question.

You´re requesting for the procedures to validate the information of the signer, well, then you can follow the same link and it indicates the validation of the information required.

But, in any case, this is very simply. Izenpe, is a government CA, a we have to fulfill all the requirements of the spanish legislation plus the basque government legislation. In Spain there´s a electronic signature law from year 2003 (which is aligned with the european directive of 1999) in which it explains perfectly the procedures to verify the information.

For qualified and nonqualified certificates we must accomplish the law, but additioanly, we are certified in ETSI 101 456 for issuing qualified certificates, in this audit, the auditors verify and audit all the issuance procedure, which includes, the verification of the information.
For non-qualified certs, SSL and code signing, we have the same procedure but as they are not qualified, the spanish legislation don´t ask you to have the information published in the web site, so if you need it or anyone which needs this info, then I can send it to you.

Regards

Comment 72

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #71)
> Izenpe, is a government CA, a we have to fulfill all the requirements of 
> the spanish legislation plus the basque government legislation. 

Yes, your government has its own criteria, and presumably you meet those, 
and consequently, if your government made a browser or an email client, you 
would be qualified to be included in those products.  But Mozilla has its 
own criteria for its own browsers and email clients, and those criteria are 
not identical to your government's criteria.  So, the fact that you meet 
your government's criteria does not automatically mean that you also meet 
Mozilla's criteria.  The purpose of Kathleen's questions is to determine if 
you actually do meet Mozilla's criteria. 

Thanks for your answers.

Comment 73

[Kathleen Wilson]

> About the audit you mention, Izenpe is certified in ETSI TS 101 456, among
> others, which only applies to issue qualified certificates, and code signing
> and SSL Certs are not qualified.

I’m not sure I understand this statement.

Were the Code Signing and SSL certs/CAs included in the audit against the ETSI 101.456 criteria?

Will the Code Signing and SSL certs/CAs be included in the audit against the ETSI 101.456 criteria that is happening this summer?

> According to all the certificates we issue, all the info is available in the
> Izenpe web site, procedures, request form, revocation form, etc. They´re only
> in spanish and in basque, and we´re not going to translate them into english. I
> did only with the SSL EV because you were asking a lot of questions, and to
> facilitate your work but we are limited by law to issue certificates only in
> Spain.
> In this link
> http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/solicitar_certificado_digital.html
> you can find all the specific CPS (we call DPC because it´s the spanish
> translation) of all the certs we issue.

Would you please provide the direct URL to each relevant and specific DPC and state what it is? 

Please don’t assume that I can find the documents myself from a website with several links on it, because of the language barrier. Please provide the specific link for each relevant document.

Once I have the actual documents, I can use Google Translate on the text that I think corresponds to section 7 of the Mozilla CA Policy. However, it would be nice if you could tell me which section numbers to do the Google Translate on.

> For non-qualified certs, SSL and code signing, we have the same procedure but as they are not qualified, 
> the spanish legislation don´t ask you to have the information published in the web site, so if you need it 
> or anyone which needs this info, then I can send it to you.

Yes, according to Mozilla policy, the DPC documents for the SSL and Code Signing certs also need to be publicly available. The document(s) may be attached to this bug.

Comment 74

[Iñigo Barreira]

Nelson, it´s not that easy as you say.

We´ve been talking some time about other issues more importants, but the fact that I have to meet all the spanish legal requirements to operate, if some of them are not the same than Mozilla´s requirements, i can´t do anything.

Comment 75

[Iñigo Barreira]

Kathleen,

here are my answers.

1.- The ETSI 101 456 is only for qualified certificates, so that means, that SSL or code signing certificates are excluded, are out of the scope. Last week, we had the re-certification for another 3 years in this one, plus the webtrust for Ev implementation audit which also have been passed.

2.- OK. Sorry for that, but i thought you or someone on the list would help you.
In that link you can go to any certificate that Izenpe issues, the document you have to click in any of them (most of the documents are quite similar) is the document called "declaracion de practicas de certificacion (DPC) especifica", this means, the specific CPS for this certificate. Because we have a common CPS for all the certificates, and one specific for each certificate.
So, in point 2 or 3 (it depends on the document, for example for ciudadano and entidad is point 2 and for the rest is point 3) "identificacion y autenticacion", which means "identification and authentication" we specify all the requirements to request a certificate.

3.- For the technical certificates (as we use to call tehem) they´re published in the web site, here: http://www.izenpe.com/s15-12020/es/contenidos/informacion/caracter_tecnico/es_tecnico/caracter_tecnico.html#01
The identification procedure is what is stated in the CPS

Regards

Comment 76

[Kathleen Wilson]

> The ETSI 101 456 is only for qualified certificates, so that means, that SSL  
> or code signing certificates are excluded, are out of the scope.
> Last week, we had the re-certification for another 3 years in this one, 
> plus the webtrust for Ev implementation audit which also have been passed.

I believe there may be a couple show-stoppers. It is very unfortunate that this wasn't realized before you started your recent audits.

Mozilla folks, please correct me if any of the information below is wrong.

To enable the SSL trust bit, the verification procedures and issuance process for the SSL certificates must be audited according to the requirements of sections 8, 9, and 10 of the Mozilla CA Certificate Policy, 
http://www.mozilla.org/projects/security/certs/policy/

My understanding is that the audit of the SSL certificates must be against one of the following three criteria:
ETSI TS 101 456
ETSI TS 102 042
WebTrust for CA

You have completed an audit for the SSL certificates against the WebTrust for EV criteria.

However, the Mozilla CA Certificate Policy states that the WebTrust EV audit is to be performed “in conjunction with WebTrust Principles and Criteria for Certification Authorities”.

My understanding is that the audit against the WebTrust EV criteria alone is not sufficient for enabling the SSL trust bit, but that an audit against one of the other three criteria listed above must also be performed.

It looks as though the verification and issuance of the code signing certificates has never been audited. This means that the code signing trust bit cannot be enabled.

I believe that there are email certificates also issued under the non qualified subCAs, so that their verification and issuance procedures also have not been audited. I believe that this could present a problem for enabling the email trust bit. Are the procedures for verification and issuance of email certificates identical whether qualified or non-qualified?

Before doing any additional audits, please make sure that there are publicly available documents that will be evaluated as part of the audit, which specify the verification procedures that satisfy section 7 of the Mozilla CA Policy.  Further information about verification of domain name and verification of control of the email address may be found at https://wiki.mozilla.org/CA:Recommended_Practices. It is also considered a show-stopper if the documented/audited verification procedures do not satisfy section 7 of the Mozilla CA Policy.

Kathleen

Comment 77

[Nelson Bolyard (seldom reads bugmail)]

Kathleen, I was under the (possibly very mistaken) impression that the 
"WebTrust for EV" criteria ARE criteria for CAs who certify EV, and might 
better be known as "Webtrust for EV CAs" criteria.  Is that mistaken?

Comment 78

[Kathleen Wilson]

From section 8 of the Mozilla CA Policy:
We consider the criteria for CA operations published in any of the following documents to be acceptable: ...
"WebTrust for Certification Authorities—Extended Validation Audit Criteria" in WebTrust for Certification Authorities—Extended Validation Audit Criteria (or, for CA requests received on or before June 30, 2008, the November 20, 2006 draft of these criteria) (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").

Clarification of my terminology:

WebTrust for EV = WebTrust for Certification Authorities—Extended Validation Audit Criteria

WebTrust for CA = WebTrust Principles and Criteria for Certification Authorities

Comment 79

[Nelson Bolyard (seldom reads bugmail)]

I see.  The question is not whether "WebTrust for EV" is a set of CA audit 
criteria but whether it is a proper superset of "WebTrust for CA", and if so,
should the Policy be amended to also name it as an acceptable set of criteria.
This is obviously a policy question.  (Sorry if that has already been settled
and I missed it.)

Comment 80

[Eddy Nigg (StartCom)]

(In reply to comment #78)
> Clarification of my terminology:
> 
> WebTrust for EV = WebTrust for Certification Authorities—Extended Validation
> Audit Criteria
> 
> WebTrust for CA = WebTrust Principles and Criteria for Certification
> Authorities

That's the right terminology. However I haven't actually understood the problem. Where is the audit statement for WebTrust for EV? I suspect that there is also another audit around, presumable ETSI?

As such IIRC WebTrust for EV implies WebTrust for CAs at the moment. We've defined this clearly during the modification of the policy and the CAB Forum hasn't changed its requirements yet.

Comment 81

[Kathleen Wilson]

I suspect that the policy is written the way it is because the CA will probably issue both EV-SSL certs and non-EV-SSL Certs. Perhaps the WebTrust for EV audit criteria only covers the EV-SSL certs?

The problem is that the SSL certs have only been audited against the WebTrust for EV criteria:
> The ETSI 101 456 is only for qualified certificates, so that means, that SSL  
> or code signing certificates are excluded, are out of the scope.

Comment 82

[Eddy Nigg (StartCom)]

I understand. It was assumed that a WebTrust for EV audit extends the WebTrust for CAs, because it's a core requirement of the criteria IIRC. If this is correct, than there must be also a WebTrust for CAs audit. However the WebTrust for EV audit criteria doesn't audit certificates outside of this specific scope (EV).

If the ETSI audit is only for QCs, than anything else, is out of scope if that exists at the CAs practice.

Comment 83

[Eddy Nigg (StartCom)]

According to the EV guidelines obtainable at http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf under section (C) (4) (a):

Any CA MAY issue EV Certificates, provided that, before the CA issues any EV
Certificates, the CA and its Root CA satisfy the following requirements:

Comply with the requirements of (i) the then-current WebTrust Program for
CAs, and (ii) the then-current WebTrust EV Program, or an equivalent for
both (i) and (ii) as approved by the CA/Browser Forum;

Further in the guidelines, section (J) (35) has more detailed requirements. The audit criteria for EV obtainable at http://www.cabforum.org/WebTrustAuditGuidelines.pdf under section 7 specifies:

As mentioned, the WT EV Audit Guidelines are to be used *only* in conjunction
with the Principles and Criteria in the WebTrust Program for Certification
Authorities. CAs that wish to issue EV Certificates must first go through a WT
audit and then a WT EV audit.

Section 8 and 9 state:

For CAs that do not have a currently valid WebTrust for CA audit report, the
criteria contained in the WebTrust Program for Certificate Authorities and the
WT EV criteria in this Addendum would be tested.

Therefore there I expect that there must be also WebTrust for CAs audit if there is a WebTrust for EV audit. Right now there doesn't exist an equivalent WebTrust for EV audit (something which might change in the future).

Comment 84

[Frank Hecker]

To clarify: The Mozilla CA certificate policy simply reflects the EV guidelines published by the CAB Forum. The EV guidelines state that both a WebTrust for CAs audit and WEbTrust EV audit are required. We do not have our own requirements for "EV", we are simply following the CAB Forum guidance, since Mozilla is a member of the CAB Forum.

As noted in the guidelines that Eddy quoted, the CAB Forum can decide to accept some other set of audits as satisfying the EV requirements; for example, the CAB Forum could decide that for purposes of the EV guidelines an ETSI audit was equivalent to a WebTrust for CAs audit. That is a decision for the CAB Forum to make, not (in my opinion) for Mozilla to make.

Comment 85

[Kathleen Wilson]

Here’s what I have….

ETSI 101.456 audit, which has just been renewed (I’ll need the new link), which only covers the qualified certs (not SSL, not code signing)
http://www.izenpe.com/s15-12020/es/contenidos/informacion/acreditaciones/es_acredita/adjuntos/certificado_etsi.pdf

WebTrust for EV Readiness audit:  
https://bugzilla.mozilla.org/attachment.cgi?id=359717

Therefore, Izenpe must also have a WebTrust for CA audit.

Iñigo, Somehow I’ve missed where the WebTrust for CA audit report is. Would you please attach it to this bug or provide the corresponding URL?

Comment 86

[Iñigo Barreira]

Kathleen,

I think there´s a lack of understanding of what the ETSI standard means. Izenpe does not have a webtrust for CA audit but it has an ETSI TS 101 456 as mentioned before which is close to webtrust for CA.
In ETSI there´s 2 types of standars to audit, ETSI TS 102 042 and TS 101 456, the first one is for non-qualified certificates, and the second one also includes de qualified ones, that means, that the non-qualified are also covered and if you read the standards are quite similar but when the audit is performed, the auditors pay more attention on the identification process and procedures, but all related to the issuance, managemente, storage, and so on are also audited and those are the same in both standards as well as the Webtrust for CA criteria. But I think that you should ask again Patrick Paling of KPMG for clarification as he´s the auditor.

For example, when the ETSI project of having an alternative audit criteria for EV began, there were 2 options, modifying the TS 101 456 or the TS 102 042. finally this one was choosen because, althoug the identification procedures mentioned in the CAB forum guidelines are similar to the ETSI TS 101 456, this standard is intended for qualified certificates, and the SSL are still non qualified, although the identification process is the same than for a qualified one, but the main characteristic of a qualified one is that they´re issued to a natural person not a machine, so, ETSI finally decided to modify the TS 102 042 specifically for non qualified and included all the related items of identification and some other specifications.

Hope this could help. Also i can give you some contacts at ETSI that can provide you more information.

But, I have one question, are we the only CA that are applying for inclusion the firefox root program with an ETSI TS 101 456 audit and the Webtrust for EV? All the CAs have the webtrust for CA audit? 

Regards

Comment 87

[Kathleen Wilson]

As suggested, I have sent email to KPMG.

In the meantime, please provide direct urls to the documents (the original documents in spanish or basque), and the corresponding page numbers within the documents which contain the following information:

1) Verification procedures for SSL (not EV) certificates, especially in regards to the steps that Izenpe takes to verify that the certificate subscriber owns/controls the domain to be referenced in the certificate.

2) The original documentation of the verification procedures of the EV-SSL certificates. I have the English translation that was provided, but I still need the document pointer to the original public-facing document that contains these procedures and has been audited.

3) Verification procedures for email certificates, especially in regards to the steps that Izenpe takes to verify that the certificate subscriber owns/controls the email address to be referenced in the certificate.

4) Verification procedures for code signing certificates, in regards to the steps that Izenpe takes to verify the identity/authorization of the entity referenced in the certificate.

Please provide the specific URLs pointing directly to the requested documentation, and the specific page numbers within the documents.

No roots make it through the discussion and approval process until this public facing documentation has been provided and it has been shown that these verification procedures have been audited according to the Mozilla CA Certificate Policy as stated previously.

Comment 88

[Kathleen Wilson]

I have found the answer to my question #2 for EV-SSL cert verification procedures: 
section 3.1.3 of
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentacin%20especfica%20%20SSL%20EV%20castellano.pdf

Comment 89

[Iñigo Barreira]

Hi again,

back from my holidays here we are.

In the Izenpe web page:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/solicitar_certificado_digital.html

You can find the documentation for SSL and Code signing certificates. The documents related to the questions are the ones starting by "Procedimiento ...", so, you can find "procedimiento certificado servidor seguro" for SSL and "procedimiento certificado firma codigo" for code signing.

In points 1.2 and 1.3 Izenpe checks the identity of the requester and the domain but you have to take in account that Izenpe is a government CA and in this case we only issue SSL and code signing certificates for the public administration so, sometimes some of the checks are not necessary by law.

About point 3 in which you mention "verification procedures for email certificates" I don´t understand what an email certificate is, so I think we don´t issue that kind of certificate. Unless you´re referring to a corporate certificate in which is optional to include the email.

Regards

Comment 90

[Nelson Bolyard (seldom reads bugmail)]

In answer to comment 89,
An email certificate is a certificate with an RFC 822 email address in 
the subject name or subject alternative name, and which does not preclude 
use in email in its Key Usage or Extended Key Usage extensions.

Comment 91

[Iñigo Barreira]

Ok then, is what I supposed.

In that case, you have to check the corporate certificates, these are qualified certificates and are intended to the employees of the Administration, so these are for the public servants because by law it´s a need. In any case this field is optional and sometimes is not filled up.
The identification process is the same that for all qualified certificates, but in this case we use to sign a contract with the correspondent department or public society in order to themselves to identify their own employees and they give us all the information needed and they are in charge of those information, and this is according to the spanish legislation.

Here are 2 links in the web site in which you can find some info. In the second one, just go to the "declaracion de practicas de certificacion (DPC)especifia" which is a specific CPS for this certificate, and once inside the doc you can check points 2 and 3 for the identification process.

http://www.izenpe.com/s15-12020/es/contenidos/informacion/certificado_corporativo_recono/es_c_recono/certificado_corporativo_recono.html

http://www.izenpe.com/s15-12020/es/contenidos/informacion/cert_corporativos/es_cert/certificado_corporativo.html

Regards

Comment 92

[Kathleen Wilson]

There are two remaining items to be resolved in this request before it can be added to the queue for public discussion.

1) Audit

The ETSI 101 456 audit covers the qualified certs. It does not cover the SSL or code signing certs.

The WebTrust EV audit covers the EV SSL certs.

I have yet to find an audit that covers the non-EV SSL certs and the code signing certs.

As previously suggested I have sent email to KPMG to ask if their recent audits of Izenpe included the non-EV SSL certificates. I have not yet received a response.

In order to proceed, Izenpe needs to identify the audit that covers the non-EV SSL certs and the code signing certs.


2) Verification of Email Address Ownership / Control

Izenpe has provided a lot of information about verifying the identity of the individual and organization. However, I am still unclear about how the ownership/control of the email address is verified when the email address is to be included in the certificate.

I have done Google translations of sections 2 through 4 of the document that describes the process for corporate public certs.
http://www.izenpe.com/s15-12020/es/contenidos/informacion/cert_corporativos/es_cert/adjuntos/Documentaci%C3%B3n%20Espec%C3%ADfica%20Corporativo%20reconocido%20castellano.pdf

Section 4.4 of this document appears to be describing the procedures for delivery of the certificate. The procedure appears to involve a PIN code. The translation wasn’t clear about how that PIN code is delivered to the certificate subscriber. Is that PIN delivered via the email address to be included in the certificate?  Or is it delivered in some other way?

Comment 93

[Iñigo Barreira]

Hi Kathleen,

1)As mentioned Izenpe has the following certifications:
- ISO27001 with the scope related to the CA and all its operations
- ETSI TS 101 456 which is related to the qualified certs
- Webtrust for EV, related to SSL EV certs

We don´t have any specific audit that covers the issuance of SSL and code signing certs, but as metioned, ETSI 101 456 is above ETSI 102 042 which is related to non qualified certs, SSL and code signing. I think Patrick Paling will answer you soon because he told me about your email.
Besides, we´re a government CA so we have more restrictions to issue certificates, qualified and non-qualified and must follow all the spanish and european legislation, in fact, for issuing EV certs we didn´t need to modify our procedures a lot because we already asked for identification process and keeped all the information.

2)As said, everything is under a contract between the requestor company and Izenpe. As government CA we have to be very careful with the identification process on the qualified certificates because according to the spanish law, the signature with those certificates is the same than the hand written signature, so identification is crucial. Having said this, the verification of the email as is an optional field is not done by Izenpe but the requestor company.

We have customers that they have 5 employees and I can go and identify all of them, one by one with all the information needed, but most of them are companies with more than 100 employees, we have ones with 8000 employees, and all the funcionaries, which can be more than 10000, in which is impossible to identify them all, so we sign a contract with them. This contract is usually signed by the general manager/ministry of the company/dept and we identify that person but all the information provided by them is their responsability by contract and we can´t check that.
This have been talked with several lawyers about data protection law, electronic siganture law and so on and this was the solution. Even more, the procedure has been marked as a best practice by the government and auditors for improvement of the speeding of the processing and developing the electronic signature in the public administration.

About the PIN, the procedure is different depending on the issuance process, if this is online, the card with the PIN/PUK envelope is giving inmediatly to the requestor because he´s on the RA requesting the certificate and if this is in batch mode, the card is delivered to the identification place in which took place by courier and the PIN/PUK is sent by post to the address filled in the request form. Sometimes is necessary to change this one, and then the card and the PIN/PUK are sent to the address but with 1 day difference and one by courier and the other by post.

I´d like to invite you to see all the process so you can check it out live for both points, but I presume is quite impossible.

Comment 94

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 95

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

In the meantime, when the 2009 audit is done, please provide the link to the new ETSI certificate and/or auditor’s statement of compliance.

Comment 96

[Iñigo Barreira]

Hi there,

attached you´ll find ETSI and ISO certificate renewed. There´s also a web page form BSI in which you can see all the certificates the company has, but it´s with my own details so I can´t give you the access. :-(

Regards

Comment 97

[Iñigo Barreira]

Attachment: ETSI TS 101 456 certificate

Comment 98

[Iñigo Barreira]

Attachment: ISO 27001 certificate

Comment 99

[Kathleen Wilson]

I am re-reviewing the information in this request in preparation for the upcoming public discussion. 

The websites that were provided for testing are...
SHA1 root: https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp
SHA256 root: https://www.ermua.es/

Both of these websites result in the following error when OCSP is enforced in the Firefox browser
Error code: sec_error_ocsp_invalid_signing_cert

This needs to be fixed before I can start the public discussion for these roots.

Comment 100

[Iñigo Barreira]

Hi Kathleen,

attached is a compressed RAR file with the certificates of the VA and the Technical CA that signed the VA. It seems that you don´t accept the certificate of the VA.
So, I´ve tried the following:

1. I´ve enforced the OCSP in Firefox going to Tools --> Options --> Advanced --> Ciphering --> Validation --> Activate last checkbox ' Cuando falle la conexión a un servidor OCSP, tratar el certificado como no válido'. 
2. So I´ve instaled the 2 Izenpe roots (2003 and 2007). 
3. And I´ve checked the 2 test web sites and I got that error message you say sec_error_ocsp_invalid_signing_cert. 
4. So I´ve instaled the technical CA certificate. 
5. Then I´ve rechecked again and the 2 test web sites give another different error message: sec_error_ocsp_unauthorized_response.  

So, it seems to me that Firefox requires that the VA must be certified by the same CA that issues the SSL cert to the web site, but I don´t understand it, it has no logical meaning.

Our VA is certified by a technical CA, this CA is different than the CA that certifies the web site, as you see in our tree, we have CAs for issuing certs and a technical CA (which is not visible on that tree) that certifies the VA and TSA. In other words, according to our policies, we have different sub CAs that can issue SSL certs so that´s the reason we have our VA and TSA certified by a technical CA because we don´t have only one sub CA that can issue this kind of certificates.

If I´m right in this, then, what can we do for you to accept our VA?

Regards

Comment 101

[Iñigo Barreira]

Attachment: VA and technical CA certificates

Comment 102

[Kathleen Wilson]

> Error code: sec_error_ocsp_unauthorized_response

Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560 (http://www.rfc-editor.org/rfc/rfc2560.txt). NSS strictly enforces the 3 rules at the bottom of page 10, and gives this error code when the response does not conform to those rules.

The following may also help:
https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root

Comment 103

[Iñigo Barreira]

Kathleen,

Checking the RFC2560: 

Systems or applications that rely on OCSP responses MUST be capable
  of detecting and enforcing use of the id-ad-ocspSigning value as
  described above. They MAY provide a means of locally configuring one
  or more OCSP signing authorities, and specifying the set of CAs for
  which each signing authority is trusted. They MUST reject the
  response if the certificate required to validate the signature on the
  response fails to meet at least one of the following criteria:

  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."



So if I understand correctly we must at least have one of the three. Of course, points 2 and 3 we don´t follow because, as I explained, our VA is not issued by the same CA that the certificate ot the web server. 

So, the only option that we have is point 1, that consists the web browser has an explicit configuration to have our VA authorised to answer all the certificates issued by all of our sub CAs, is this possible? are you able to do it?

Regards

Comment 104

[Kathleen Wilson]

NSS strictly enforces all three of these criteria. I am not aware of any plans to change this.

As per
https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root
"CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified."

Comment 105

[Iñigo Barreira]

Good morning,

Reading again the RFC2560, you´re right in terms that it´s supposed that we must meet the 3 requirements. However, going in deep it´s also said that a list of VAs is allowed and a specific configuration to know for which CAs is answering the VA. 


  "Systems or applications that rely on OCSP responses MUST be capable
  of detecting and enforcing use of the id-ad-ocspSigning value as
  described above. They MAY provide a means of locally configuring one
  or more OCSP signing authorities, and specifying the set of CAs for
  which each signing authority is trusted. They MUST reject the
  response if the certificate required to validate the signature on the
  response fails to meet at least one of the following criteria:

  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." 


In point 2.2 of the RFC, it´s said explicity that the OCSP response can be signed with a reliable certificate. 


  "All definitive response messages SHALL be digitally signed. The key 
   used to sign the response MUST belong to one of the following: 

   -- the CA who issued the certificate in question 
   -- a Trusted Responder whose public key is trusted by the requester 
   -- a CA Designated Responder (Authorized Responder) who holds a 
      specially marked certificate issued directly by the CA, indicating 
      that the responder may issue OCSP responses for that CA"

Well, I can also add that this configuration is very typical, the VAs with redirection are not new and they exist and there are applications that support this configuration, or VAs that respond for several CAs (typical example in Spain is the national electronic Id, the DNI-e)

The other browsers didn´t mention anything about our configuration and as I said is very usual.

Regards

Comment 106

[Kathleen Wilson]

Before I can enter this request into public discussion, I must be able to verify that websites whose SSL certs chain up to these roots will load without error into Firefox without the user having to import a cert other than the root.

I see two ways for you to proceed... 
1) You can update your OCSP service to work without error in the Firefox browser.
or
2)You can file a bug against Firefox explaining why you think its implementation needs to be fixed, and wait for the change to be implemented (if it is decided that the change will be implemented). If you go this route, please indicate the bug number in this bug, so we can track the dependency for this request.

Comment 107

[Iñigo Barreira]

I like this attitude, so the options are, do what I want you to do or don´t bother me.

Well, I will then create a bug requesting a change in the Firefox browser to have a similar behaviour as Internet Explorer, Opera, Chrome and Safari (none of these have had any issue and we haven´t been waiting since nov 2006, we´re heading for 4 years, this is gonna be a record guinness).

On the other hand, my customers don´t need to pay this situation (most of them are tired and are banning the use of the Firefox)so I´ll try to modify my OCSP just for my SSL EV sub CA. I don´t know how long this will take and how much money it will cost me, but don´t worry for that, we´re here just to follow your rules (it´s part of my job) but once done, I´ll let you know and of course all my customers and those who want to check it out because I´ll publish the way of doing things in your company, foundation or whatever you call it.

Comment 108

[Iñigo Barreira]

Kathleen,

the bug related is 554598.

Regards

Comment 109

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Comment 110

[Kathleen Wilson]

> I´ll try to modify my OCSP just for my SSL EV sub CA.

The current request is to include two root certificates:
1) Izenpe.com SHA1 (not requesting EV)
2) Izenpe.com SHA256 (requesting EV)

So are you saying that you will modify your OCSP service to work without error in Firefox for websites using SSL certs that chain up to the SHA256 root?

Does that mean that this request is now only for the inclusion of the SHA256 root? And not for the inclusion of the SHA1 root?

Comment 111

[Iñigo Barreira]

Hi,

I think there´s a little bit of confussion here. Izenpe has only one root, called Izenpe.com, but it´s signed with both algorithms, first with SHA1 and then with SHA256, which means this is the newer.

So, what we are planning is to modify or to set up a new VA just for the sub CA that issues the SSL EV certs and following your recommendations that ít´s signed by this CA, so, all the responses for these certificates will comply with your requirements, but this is for the same root. 
So, accordign to our comments 51 to 60, we finally decided to include only the one signed with SHA256 because you said that NSS will allways pick the new one up, so, as said, it´s ok for me.

The solution we´re planning is independently of this.

In summary, I want my Izenpe root included in the Mozilla root program and that my EV certs appear in green in the browser but if you´re accepting only the SHA256 one, I have no problem with that.

Regards

Comment 112

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thanks for the clarification. I've updated the Information Gathering Document to reflect that this root inclusion request is for the SHA256 root.

Comment 113

[Kathleen Wilson]

When do you expect to have the OCSP service updated?

Comment 114

[Iñigo Barreira]

By the end of this month. It´s very easy to configure a VA for every CA although it´s a bad solution but we will wait to implement some other enhancements.

I´ll let you know when this will be available for you to check. This solution will work only for the certs issued since then, not for the old ones.

Regards

Comment 115

[Iñigo Barreira]

Hi again,

we´ve have to wait to issue a new ev cert with the new configuration for you to check.
Now you can check www.it-txartela.net and you´ll see the new VA we´ve created for the CA that issues the EV cert, it´s called VA2.

Anything else? Is this enough?

Regards

Comment 116

[Kathleen Wilson]

When I enforce OCSP in my Firefox browser and go to https://www.it-txartela.net I get the following error:

The OCSP server experienced an internal error.

(Error code: sec_error_ocsp_server_error)

Comment 117

[Iñigo Barreira]

Hi Kathleen,

can you try again, please? I can find that error message. Maybe it´s due that last night we made a modification that was scheduled last week but has been done last night.

Regards

Comment 118

[Iñigo Barreira]

FYI.

I´ve marked the OCSP and the use of OCSP to validate the cert. The default one

Comment 119

[Iñigo Barreira]

Sorry, I meant, I can´t find the error message

Comment 120

[Kathleen Wilson]

It's working for me now. Excellent!

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

Comment 121

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 122

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Izenpe to add the “Izenpe.com” root certificate.

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 “Izenpe Root Inclusion Request”

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

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

Comment 123

[Kathleen Wilson]

This request has been evaluated as per sections 1, 5 and 15 of the official CA 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 from Izenpe to add the SHA256 “Izenpe.com” root certificate, and to enable the websites and code signing trust bits. The request is to also enable EV.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by IZENPE, or of instances where they have 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]. IZENPE appears to provide a service relevant to Mozilla users: It is a public company belonging to the Basque Country Government. The primary geographical area is the Basque Country but all of their certificates are recognized, accepted, and validated throughout 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 CPS, which is available in English, and the Certificate Specific Documents, which are in Spanish.

** CPS: http://www.izenpe.com/cps

Certificate Specific Documentation: 
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/solicitar_certificado_digital.html

** Secure Server Certificates: http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20espec%C3%ADfica%20SSL%20castellano_nov09.pdf

** EV SSL Secure Server Certificates: http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20espec%C3%ADfica%20%20SSL%20EV%20castellano_nov09.pdf

** Corporate Certificates: http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20Espec%C3%ADfica%20Corporativo%20reconocido%20castellano_nov09.pdf

** Code Signing Certificates: http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Procedimiento_Firma_C%C3%B3digo_castellano_06-03-24.pdf


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

* Email: Not Applicable. Not requesting the email trust bit at this time. 

* SSL: According to sections 3.2 and 3.3 of Izenpe’s Procedures for Secure Server Certificates, the identity of the certificate applicant and organization are verified using a notary and public records, then Izenpe uses whois to verify that the applicant has the right to use the domain or subdomain.

* Code: According to Izenpe’s Procedures for Code Signing Certificates, the identity of the certificate applicant and organization are verified using a notary and public records. 

* EV Policy OID: 1.3.6.1.4.1.14777.6.1.1
** Section 3 of Izenpe’s Procedures for EV SSL Secure Server Certificates provides information about the steps taken to verify the identity of the certificate applicant and the organization using public records, as well as the ownership/control of the domain name. Izenpe consults registrars appointed by ICANN/IANA for domain names and addresses associated with the certificate, and compares the Legal and Technical Area contacts with the documentation provided by the applicant.

Section 13 [Certificate Hierarchy]. 
* This root has five internally-operated subordinate CAs. One sub-CA issues EV SSL certs. Two of the sub-CAs are for Qualified certificates, one for Public Administration, and one for Citizens and Entities.  There are also two sub-CAs for non-Qualified certificates, one for Public Administration and one for Citizens and Entities, which issue SSL Server, Email, and Code Signing certs.
** A CA Hierarchy diagram is available here:
https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp

Other: 
* CRLs for end-entity certs have a NextUpdate of 10 days and are refreshed every 1 day
* OCSP is provided. 
** Izenpe uses port 8097 for their OCSP responder. They will investigate using port 80 for the AIA OCSP URI in future certs.

Section 8-10 [Audit]. 
* The WebTrust EV audit was performed by KPMG: https://cert.webtrust.org/SealFile?seal=1017&file=pdf
** An ETSI 101 456 audit is also performed by BSI Management Systems B.V. The ETSI certificate can be viewed by going to the BSI website, http://www.bsi-global.com/ClientDirectory, and entering Izenpe for the Certificate & Client Directory Search.

Based on this assessment I intend to approve this request to add the SHA256 “Izenpe.com” root certificate, enable the websites and code signing trust bits, and enable EV.

Comment 124

[Kathleen Wilson]

To the representatives of Izenpe: 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 #123, and on behalf of the Mozilla project I
approve this request from Izenpe to include the following root certificate in
Mozilla:

* Izenpe.com (web sites, code signing), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.

Comment 125

[Kathleen Wilson]

I have filed bug 578491 against NSS and bug 578499 against PSM for the actual changes.

Comment 126

[Iñigo Barreira]

Hi,

I´d like to let you know that we´ve been changing our infrastructure for the EV sites in order to meet the Mozilla requirements and also to improve our responses. The changes are these:

-	OCSP port has changed to 80
-	VA is signed by the EV issuing CA
-	Also adapted the profiles with the recent changes approved in the CABF.

OIDs remains the same and I can provide you with 2 sites for checking. Please let me know if you encounter any problem

EV (OID 1.3.6.1.4.1.14777.6.1.1)  https://servicios.izenpe.com
Sede EV (OID 1.3.6.1.4.1.14777.6.1.2) https://servicios1.izenpe.com

TIA

Comment 127

[Julen Ruiz Aizpuru]

I'm not sure what does the "In FF4Beta" whiteboard status mean: is the certificate already available in Firefox 4 betas? I'm using Firefox 4 nightlies for a long time now — should I be noticing any change in concrete websites?

Comment 128

[Kathleen Wilson]

If you are running a Firefox browser version 4 Beta, then open the Certificate Manager and find this root. You will see that it is a "Builtin Object Token".

Comment 129

[Kathleen Wilson]

Attachment: Audit-2016.pdf