489240 - Add Autoridad de Certificacion Raiz del Estado Venezolano root certificate

Status: RESOLVED WONTFIX

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

Description

[Carlos Mariño]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-AR; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.04 (hardy) Firefox/3.0.8
Build Identifier: 

CAs applying for inclusion in Mozilla.

Reproducible: Always

Comment 1

[Carlos Mariño]

Attachment: Information checklist for CAs applying for inclusion in Mozilla

Comment 2

[Kathleen Wilson]

Accepting this bug.

I will begin the Information Gathering and Verification phase soon as described
in https://wiki.mozilla.org/CA:How_to_apply

Comment 3

[Kathleen Wilson]

Would you please attach the root certificate in PEM format to this bug?

I cannot get to https://acraiz.suscerte.gob.ve/certificados/ because I have not yet imported the root that the website cert chains up to.

Comment 4

[Carlos Mariño]

Attachment: Root Certificate in PEM format

Comment 5

[Carlos Mariño]

Attachment: CA Certificate, delivered for ROOT AC

Comment 6

[Kathleen Wilson]

Attachment: SUSCERTE Root Certificate

Comment 7

[Kathleen Wilson]

Thank you for providing the root cert.

I am trying to view the certs listed in
https://acraiz.suscerte.gob.ve/certificados/
but I get intermittent connectivity errors, which is making it really difficult to do so. Would you please explain what each of these is?
CERTIFICADO-RAIZ-SHA1 –this is the root that’s been provided in bugzilla.
CERTIFICADO-RAIZ-SHA256 – same root in sha256 format? Not part of this request?
CERTIFICADO-ACPASS-SHA256 – root -- AC Pasaporte. Not part of this request.
CERTIFICADO-PASAPORTE-SHA256 – ?
PROVEEDOR-FII-SHA1-11-07-2008 – ?
PROVEEDOR-FII-SHA256-11-07-2008 – ?
PROVEEDOR-PROCERT-SHA1-14-07-2008 - ?

For the following websites
https://acraiz.suscerte.gob.ve/certificados/
https://ar.fii.gob.ve
https://www.vencert.gob.ve
the website cert URL distribution point is
https://publicador-psc.fii.gob.ve/crl/cacrl.crl
However I get an error when I try to access this CRL.
Is this the correct url to the CRLs for these website certs? The problem could be due to the same connectivity errors. Would you please see if you can import this CRL into Firefox and what it says the next update is?

When I force Firefox to use OCSP and to error-out if the OCSP connection fails, the following two sites fail with error Invalid OCSP signing certificate in OCSP response.
https://ar.fii.gob.ve
https://www.vencert.gob.ve
However, the certificados site works (except when I get the connectivity error):
https://acraiz.suscerte.gob.ve/certificados/

Comment 8

[Carlos Mariño]

Attachment: CRL of FII in DER format

Comment 9

[Carlos Mariño]

Attachment: CRL of FII in TXT format

Comment 10

[Carlos Mariño]

Thanks for your prompt response



1.- I am trying to view the certs listed in

https://acraiz.suscerte.gob.ve/certificados/

but I get intermittent connectivity errors, which is making it really difficult

to do so. Would you please explain what each of these is?



Our technical staff resolved the intermittent connectivity errors. You can access the site https://acraiz.suscerte.gob.ve/



CERTIFICADO-RAIZ-SHA1 - this is the SUSCERTE Root Certificate in sha1 format

CERTIFICADO-RAIZ-SHA256 - this is the SUSCERTE Root Certificate in sha256 format

CERTIFICADO-ACPASS-SHA256 - this is a special case, We  manage the CA to electronical passport venezuelan. Not part of this request.

CERTIFICADO-PASAPORTE-SHA256 -this is  same special case for electronical passport venezuelan.Not part of this request.

PROVEEDOR-FII-SHA1-11-07-2008 -this is certificate CA subordinate (company FII) issued by the SUSCERTE root CA in sha1 format

PROVEEDOR-FII-SHA256-11-07-2008 - this is same certificate CA subordinate (company FII)  issued by the SUSCERTE root CA in sha256 format

PROVEEDOR-PROCERT-SHA1-14-07-2008 - this is a other certificate CA subordinate (company PROCERT) issued by the SUSCERTE root CA in sha1 format



2.- For the following websites

https://acraiz.suscerte.gob.ve/certificados/

https://ar.fii.gob.ve

https://www.vencert.gob.ve

the website cert URL distribution point is

https://publicador-psc.fii.gob.ve/crl/cacrl.crl However I get an error when I try to access this CRL. Is this the correct url to the CRLs for these website certs? The problem could

be due to the same connectivity errors. Would you please see if you can import

this CRL into Firefox and what it says the next update is?

The connectivity errors have been resolved. You can access the site https://publicador-psc.fii.gob.ve/

Next Update: Jun  4 13:50:00 2009 GMT

Also attached the CRL FII CA subordinate in TXT and DER format



In this site you can download the CRL of the SUSCERTE root CA

https://acraiz.suscerte.gob.ve/lcr/CERTIFICADO-RAIZ-SHA1CRL.txt - TXT format

https://acraiz.suscerte.gob.ve/lcr/CERTIFICADO-RAIZ-SHA1CRLDER.crl - DER format



3.- When I force Firefox to use OCSP and to error-out if the OCSP connection fails,

the following two sites fail with error Invalid OCSP signing certificate in

OCSP response.



We are reviewing the connection to OCSP response service.

Best Regards,

Comment 11

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Thank you for the descriptions of the CAs listed on the website. I am able to import the CRL at the root level into Firefox. I am also able to import the CRL for FII that you attached, but I'm still unable to import the CRL for end-entity certs as per the example websites that were provided. More info on this below.

Attached is the Initial Information Gathering document, which summarizes the information that has been gathered and verified as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Please review the attached document for accuracy and completeness. Within the document, the items highlighted in yellow indicate where further information or clarification is needed.  I will also summarize below.

1) Please provide the document and section numbers, and translations into English of the parts of the CP/CPS documents pertaining to:
•	Verification of Identity and Organization for End-Entity Certs
•	Verification of ownership/control of domain name for End-Entity Certs
•	Verification of ownership/control of email address for End-Entity Certs
•	 Section 7 of http://www.mozilla.org/projects/security/certs/policy/
•	Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices

2) Please see sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/
We need a publishable statement or letter from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for this root, and that the CA does indeed follow these practices and meets the requirements of one of:
•	ETSI TS 101 456
•	ETSI TS 102 042
•	WebTrust Principles and Criteria for Certification Authorities

3) For the externally-operated subordinate CAs, please provide the information listed in the SubordinateCA Checklist: https://wiki.mozilla.org/CA:SubordinateCA_checklist

4) I need to import into Firefox a CRL for end-entity certs chaining up to this root.
For these websites
https://acraiz.suscerte.gob.ve/certificados/
https://ar.fii.gob.ve
https://www.vencert.gob.ve
the website cert URL distribution point is
https://publicador-psc.fii.gob.ve/crl/cacrl.crl
publicador-psc.fii.gob.ve uses an invalid security certificate.
The certificate is only valid for the following names:
  150.186.246.51 , acraiz.suscerte.gob.ve  
(Error code: ssl_error_bad_cert_domain)

5) When I force Firefox to use OCSP and to error-out if the OCSP connection fails, the following two sites fail with error Invalid OCSP signing certificate in OCSP response.
https://ar.fii.gob.ve
https://www.vencert.gob.ve
However, the certificados site works:
https://acraiz.suscerte.gob.ve/certificados/

Comment 12

[Carlos Mariño]

Attachment: Publishable statement from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for this root

Publishable statement states that the CA does indeed follow these practices
and meets the requirements of one of:
•    ETSI TS 101 456
•    ETSI TS 102 042

Comment 13

[Kathleen Wilson]

Would you please also attach a version of this auditor's statement that is translated into English?

I will also need the auditor's website and contact information. 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.

Comment 14

[Carlos Mariño]

Attachment: Publishable statement of the auditor (English language)

Comment 15

[Carlos Mariño]

Attachment: Curriculum Vitae auditor (Spanish version)

Comment 16

[Kathleen Wilson]

Thank you for the audit information. Since this is not a well known auditor, I will have to do some extra verifications.

In the meantime, please post the other information that I requested in comment #11.

Comment 17

[Kathleen Wilson]

According to section 9 of the Mozilla CA Policy
http://www.mozilla.org/projects/security/certs/policy/
The auditor must meet the following requirements:
--
By "competent party" we mean a person or other entity who is authorized to perform audits according to the stated criteria (e.g., by the organization responsible for the criteria or by a relevant government agency) or for whom there is sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria. In the latter case the "public information" referred to should include information regarding the party's 
- knowledge of CA-related technical issues such as public key cryptography and related standards; 
- experience in performing security-related audits, evaluations, or risk analyses; and 
- honesty and objectivity. 
--

The auditor referred to in comments #12, #14, and #15 is unknown to Mozilla, so I have begun to investigate if this auditor meets the criteria of the Mozilla CA Policy.

In comment #15, a document stating the auditor’s criteria was attached. The document states:
Name: Mariclen Villegas
Miembro ISACA No: 280865

I asked my contact at ISACA to verify this membership name and number, and I received the following reply:

> I find that Mariclen Villegas is not certified nor is she a member of ISACA.

I will not be able to proceed with processing this request until this discrepancy is resolved.

Comment 18

[Carlos Mariño]

Good afternoon,

We want to know if Auditor's Public Declaration that was published on the web site “bugzilla.mozilla.org”, (2009/06/17) signed by Mariclen Villegas, ISACA's member N° 280865,  has actually been verified. This, ever though she's not an ISACA's certified auditor.

Please, could you verified again the Membership status of this auditor, because we understand that an administrative delay has occurred.

So, we would like to know weather Mozilla does accept this public declaration or we must look for another certified auditor to determine if our Root Certification Authority complies with the technical specifications and standards required by Mozilla.

Best regards

Comment 19

[Kathleen Wilson]

> Please, could you verified again the Membership status of this auditor,
> because we understand that an administrative delay has occurred.

I re-checked with my contact at ISACA, and I recieved the following reply: 
"I do find that Mariclen is a member."

So we can move forward with this request. I will proceed with confirming the authenticity of the auditor's statement as per Mozilla CA policy.

In the meantime, please post the other information that I requested in comment
#11.

Comment 20

[Kathleen Wilson]

I have received confirmation from the auditor that the audit statement that was provided in Spanish and in English is authentic.

The first audit was performed from August 2006 to December 2006. 
The second audit was performed from March 2008 to August 2008. 
Audits are performed about every year and a half.

Please provide the other information that was requested in Comment #11.

Comment 21

[Victor González]

(In reply to comment #15)
> Created an attachment (id=383727) [details]
> Curriculum Vitae auditor (Spanish version)

Comment 22

[Victor González]

Appreciated Kathleen Wilson, in order to continue with the phase --Information_gathering_and_verification-- according to Comment #11,  I'll join the working group too.

Comment 23

[Victor González]

(In reply to comment #11)
> 1) Please provide the document and section numbers, and translations into
> English of the parts of the CP/CPS documents pertaining to:
> •    Verification of Identity and Organization for End-Entity Certs
> •    Verification of ownership/control of domain name for End-Entity Certs
> •    Verification of ownership/control of email address for End-Entity Certs
> •     Section 7 of http://www.mozilla.org/projects/security/certs/policy/
> •    Potentially Problematic Practices,
> http://wiki.mozilla.org/CA:Problematic_Practices

Good afternoon,

In this site https://acraiz.suscerte.gob.ve/dpc/DPC_AC_RAIZ_V1.0_en.pdf 
you can download the CP/CPS document and section numbers, and translations into English of the parts of the CP/CPS documents pertaining to:

•    Verification of Identity and Organization for End-Entity Certs, ownership/control of domain name for End-Entity Certs and ownership/control of email address for End-Entity Certs.

Please check it out at section number 6.5.1 Specifications of the Administrative Organization, page 26 of 103.


The other items would be resolved as soon as possible.

Comment 24

[Kathleen Wilson]

The only document I see in English is
http://acraiz.suscerte.gob.ve/dpc/DPC_AC_RAIZ_V1.0_en.pdf  
This document is at the level of authenticating and approving the Certification Service Suppliers (CSS); eg the intermediate CAs that are signed by this root.

Section 7 of the Mozilla CA Policy is in regards to the issuance of end-entity certificates.

I do not read Spanish, so for each item I need you to provide the url to the specific document(s) and the section or page numbers where the procedures are described.  Translations into English are also appreciated, but I can copy-paste into Google Translate.

1) The sections pertaining to Verification of Identity and Organization for End-Entity certs. 

2) The sections of the CP/CPS documents that describe the procedures for verifying that the domain referenced in an SSL cert is owned/controlled by the subscriber. 

3) The sections of the CP/CPS documents that describe the procedures for verifying that the email account associated with the email address in the cert is owned/controlled by the subscriber.

4) The sections of the CP/CPS documents that describe the identity verification procedures for code signing certs.

Comment 25

[Victor González]

Attachment: DPC English version SUSCERTE

Comment 26

[Victor González]

Attachment: Norm27. Guide for Accreditation of Certification Services Suppliers

This Norm is in Spanish Version Only.

Comment 27

[Victor González]

Appreciated Kathleen,
Good Morning:

These questions don not apply to SUSCERTE, because the Root CA is the Root Certification Authority of the National Infrastructure of Electronic Certification whose main function is to issue the electronic certificates to the Certification Services Supplier.

You can check it out at the following Sections of our DPC: Created an attachment (id=407272)

Section #6. Declaration of Certification Practices and Certificates Policy of The Root Certification Authority of Venezuela.
Section #6.3.4 Subjects of Certificates.
Section #6.3.4.1 Certification Services Suppliers

The Subordinated CA is called CSS of the Public and Private Sector of the Country. Within the Venezuelan legal framework, these are derived from the hierarchy of the Root CA, where they require that the Root CA signs their certificate so that they, on time, issue certificates to the final signatories, following with the confidence chain from the root point of the National Insfrastructure of Electronic Certification. Every one of these CSS must elaborate its own DPC and Policy of Certificates, coherent with the general requeriments established by the LSMDFE (Decree with Legal Force 1,204 On Data Messages and Electronic Signatures), its Partial Regulation and others that SUSCERTE may deem necessary.

In fact, our "Key Usage" field of the Certificate's Root CA defines the purpose of the certificate key. It must specify as critical value: Electronic Signature of the Certificate and LRC's Signature. 

However, in response to the first question, please check it out at DPC :
8. IDENTIFICATION AND AUTHENTICATION
8.2 Initial validation of Identity.
8.2.3 Verification of the faculties of representation. (Here SUSCERTE apply the Norm 027, a Guide for the Accreditation of Certification Services Suppliers, which specifies the classified documentation required wheter it's of a legal, economic-financial, technical or auditing kind, is available. 
Note: Norm 27 is in Spanish version only. So, if you would like to check it out, please download it here: Created an attachment (id=407273)


All of this Apply, as I said before, only at a Certification Service Suppliers (CSS) level; eg the intermediate CAs that are signed by this root.

Comment 28

[Eddy Nigg (StartCom)]

Kathleen, in case this CA functions as kind of a super CA and their CA policies don't apply to the sub ordinate CAs (including auditing), those CAs must apply for inclusion themselves. We had previous similar requests which were not approved.

Comment 29

[Kathleen Wilson]

As per https://wiki.mozilla.org/CA:SubordinateCA_checklist
When a root CA issues sub-CAs that are operated by third parties, the following is required (for both sub-CAs operated for internal use, as well as sub-CAs operated for external use such as your Certification Service Suppliers):
- The CP/CPS that the sub-CAs are required to follow. 
- Requirements (technical and contractual) for sub-CAs in regards to whether or not sub-CAs are constrained to issue certificates only within certain domains, and whether or not sub-CAs can create their own subordinates. 
- Requirements (typically in the CP or CPS) for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy. 
-- domain ownership/control 
-- email address ownership/control 
-- digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate 
- Description of audit requirements for sub-CAs (typically in the CP or CPS) 
-- Whether or not the root CA audit includes the sub-CAs. 
-- Who can perform the audits for sub-CAs. 
-- Frequency of the audits for sub-CAs. 

If you want to continue down the road of including the root in Mozilla, you will need to update the CPS/DPC to meet these requirements, and those updates will need to go through an audit. You will also be required to provide the rest of the information listed in https://wiki.mozilla.org/CA:SubordinateCA_checklist for each of your Certification Service Suppliers.

The other alternative, as stated in Comment #28, is for each of your sub-CAs to apply for inclusion themselves, as separate trust anchors.

Please reply in this bug to let us know which route you plan to take.

Comment 30

[Victor González]

Good Afternoon Kathleen.

 We planned to take the alternative as stated in comment #28, where each one of our sub-CAs has to apply for inclusion themselves, as separate trust anchors.

We have already kept in touch with our sub-CAs, and they are working on the requisites to join into the inclussion process. 

In fact, there is already a new user on this forum "[e-mail]", they are our private Sub-CAs.

As soos as possible, our public Sub-CA will join the rest of process too.

In the terms of continuing with the rest of process, please tell us wich would be the next step to follow.

Thanks in advance.

Comment 31

[Kathleen Wilson]

Thank you for the update.

Please have each sub-CA file a separate bug requesting the inclusion of their certificate, as per https://wiki.mozilla.org/CA:How_to_apply

In their bug description, please have them indicate that their cert chains up to the “Autoridad de Certificacion Raiz del Estado Venezolano” root, and that in bug #489240 it was determined that each sub-CA would apply for inclusion separately.

Comment 32

[Carlos Suarez]

Hello Kathleen Wilson, i hope you still working on this bug. My name is Carlos Suarez, i work for SUSCERTE and i'm going to be the one who continues working on this bug.

I hope we could start again as fast as posible, i know its been long time without work on this, so apologies.

I also want to know the status of our request. 

Waitting for your response to start working, 
Carlos Suarez.

Comment 33

[Carlos Suarez]

Hello and happy new year 2011! I hope hear news from you soon to start working!

Carlos Suarez from SUSCERTE

Comment 34

[Carlos Suarez]

Hello and happy new year 2011! I hope hear news from you soon to start working!

Carlos Suarez from SUSCERTE

Comment 35

[Kathleen Wilson]

Hi Carlos, 

Please read from Comment 27 through Comment 31 in this bug. As a result, this bug was closed, and I stopped working on it.

Note that PROCERT, a sub-CA of SUSCERTE, has created a bug for inclusion of their CA -- see bug #593805.

Happy new year!
Kathleen

Comment 36

[Carlos Suarez]

Hello Kathleen, thanks for write! 

Ok, i read from comment 27 to comment 31. I understand that each sub-CA has to work on separates bugs their inclusion of their certificates. But we want to keep the request to include the Root Certification Authority of Venezuela CA-Certificate in Mozilla to maintain the chain of trust of the National Infrastructure of Electronic Certification in Venezuela. 

I will apreciate if you tell me how can we work in the inclusion again.
Can we reopen this bug?

Best regards!
Carlos

Comment 37

[Kathleen Wilson]

> I understand that each sub-CA has to work on separates bugs their inclusion 
> of their certificates. 

Only if they are going to be included as separate trust-anchors.

> But we want to keep the request to include the Root Certification Authority 
> of Venezuela CA-Certificate in Mozilla 

We do not include both the root and the intermediate certificates, so if we re-open this bug then we would close PROCERT's bug #593805. All of the sub-CAs would have to be evaluated as part of this bug. 

> Can we reopen this bug?

Yes, we can re-open this bug again, if your intent is to include the SUSCERTE root. 

You will need to provide all of the information listed here:
https://wiki.mozilla.org/CA:Information_checklist

and here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist

Please see https://wiki.mozilla.org/CA:How_to_apply for a description of our process.

Comment 38

[Carlos Suarez]

Thanks for the information above Kathleen,

Our intent is to include SUSCERTE root certificate and that PROCERT keep working on his own inclusion through bug #593805.

I want to talk to you about somethings before take a decision about the bug.

PROCERT has already worked on their bug, so we don't expect to close it. 
Can we work on the inclusion of SUSCERTE root through that bug, the bug #593805? 

I let you know, as aditional information, that SUSCERTE root its included in the Windows Root Certificate Program Members. You can check it at the website:

http://social.technet.microsoft.com/wiki/contents/articles/windows-root-certificate-program-members.aspx

Does this help to advance in the inclusion in Mozilla?

Thank you again,

Carlos!

Comment 39

[Kathleen Wilson]

> PROCERT has already worked on their bug, so we don't expect to close it. 
> Can we work on the inclusion of SUSCERTE root through that bug, the bug
> #593805? 

The only time we include an intermediate CA is when it is being treated as a trust-anchor, such that the root cert that signed it will not be considered for inclusion.

If you wish to work on including the SUSCERTE root, then we can re-open this bug, and make it depend on the PROCERT bug. We can continue working on the PROCERT bug as an evaluation of it as a sub-CA, but not to be considered for inclusion. 

Is this the way that you would like to proceed?

> Does this help to advance in the inclusion in Mozilla?

No.