471045 - Add "ACEDICOM Root" certificate

Status: RESOLVED FIXED

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

Description

[Raúl Santisteban]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); es_ES; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17
Build Identifier: Any

Edicom , and more specifically the Certification Authority ACEDICOM, is really interested on become a member o Mozilla Certificate Root program.
As Mozilla Certificate Policy describes (http://www.mozilla.org/projects/security/certs/policy/)
ACEDICOM acomplish with all the requirements specified by Mozilla Policy and It would be really interesting for Mozilla products users include "ACEDICOM Root" Certificate.

Reproducible: Always

Steps to Reproduce:
Verifying any ACEDICOM certificate, such as http://acedicom.edicomgroup.com/archivos/certificados/ACEDICOM%2001.crt
Actual Results:  
Mozilla products doesn't trust this certificates since "ACEDICOM Root" certificate is not included in Mozilla repositories.

Expected Results:  
Trusting the certificates

The CA web page is: http://acedicom.edicomgroup.com/

Extended key usages in certificates issued by ACEDICOM Root or subordinate CAs are:
    * Server Authentication
    * Client Authentication
    * Secure E-mail
    * Code signing
    * Time stamping
    * OCSP
    * IPSec

Certification Practices Statement:
    * English version:      http://acedicom.edicomgroup.com/en/archivos/politicas/ACEDICOM_CertificationPractice.pdf
    * Spanish version:      http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM_PracticasCertificacion.pdf

Third-party audits of ACEDICOM practice:
 - ASIMELEC: http://www.asimelec.es/
 - S21Sec: http://www.s21sec.com/
 - Ministerio de Industria, Turismo y Comercio (Spain):
    + http://www.mityc.es/es-ES/index.htm
    + https://www11.mityc.es/prestadores/busquedaPrestadores.jsp

Comment 1

[Raúl Santisteban]

Attachment: ACEDICOM_Root Certificate is the certificate related to the private key used when signing any ACEDICOM subCA

This file can be used to include "ACEDICOM Root" on Mozilla trust certificate repository.

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

In the meantime, please provide as much information as you can as listed in
https://wiki.mozilla.org/CA:Information_checklist

Thanks,
Kathleen

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the Initial Information Gathering document which summarizes the information that has been gathered and verified. Please review the document for accuracy and completeness. Within the document the items highlighted in yellow indicate where further clarification is needed. I will also summarize below.

1) Please verify the CA-hierarchy information in the document, and provide correction or further information if needed.
a) Does this root have any subordinate CAs that are operated by third parties?
b) Has this root been involved in cross-signing?

2) Please provide the section numbers (and translations) where text in the CP/CPS demonstrates that reasonable measures are taken to verify the following information for end-entity certificates chaining up to this root, 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;

3) For testing purposes, please provide a URL to a website whose certificate chains up to this root. Note that this can be a test site.

4) Please review the potentially problematic practices listed at http://wiki.mozilla.org/CA:Problematic_Practices. 
Provide further information for the items that are applicable.

5) 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 these roots, 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
Note that this can be a letter/statement that is posted into bugzilla, and then I will need to do an independent verification of the authenticity of the document by contacting the auditor directly.

Comment 4

[Raúl Santisteban]

Attachment: TLS certificate sample

This certificate can be used as sample to test TLS certificates issued by ACEDICOM.

Comment 5

[Raúl Santisteban]

Attachment: Code signing certificate sample

This certificate can be used as sample to test code signing certificates issued by ACEDICOM.

Comment 6

[Raúl Santisteban]

Attachment: ACEDICOM Response to Initial Information Gathering Document

This documents conteins the response to all the questions on the Initial Information Gathering Document

Comment 7

[Raúl Santisteban]

Attached is the  "ACEDICOM Response to Initial Information Gathering Document", which responses to all the questions from Mozilla until now.

Comment 8

[Kathleen Wilson]

Thank you for the information and the translations.

In response to your question: …does Mozilla include the subCA on the trusted certificate store or just the root?
Mozilla only includes root certificates.

I have a few more questions…

1) Is there OCSP under the ACEDICOM Servidores sub-CA? Or is OCSP only available for certs under the ACEDICOM 01 and ACEDICOM 02 sub-CAs? The reason I ask is that the example certs are issued by the Servidores sub-CA, and it wasn't clear to me that OCSP was being used for verification.

2) Which of the Certification Policy documents apply to ACEDICOM 01, and which Certification Policy documents apply to ACEDICOM 02?

3) Which Certification Policy document(s) talk about Code Signing? Which of the sub-CA’s can issue code signing certs?

4) Does ACEDICOM perform identity/organization verification for all SSL certificates? Or is it ever the case for SSL certs that the domain name is verified, but the identity/organization of the subscriber is not verified?

5) It appears that the TLS Certificate Policy
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20%20Politica%20Certificados%20TLS.pdf
was created on 2009-03-26, but the last audit was performed in 2008.
Has the Certificate Policy been included in an audit?
Has the ACEDICOM Servidores root been included in an audit?

6) It’s not clear to me when I look at the auditor’s statement… Which of the sub-CAs were audited as part of the S21sec audit of 2008-09-15? 

Thanks,
Kathleen

Comment 9

[Raúl Santisteban]

Responding to your additional questions:
1) OCSP is available under all the subCA. As It's not mandatory, test certificates didn't included it. If you need it, I can provide test certificate issued from "ACEDICOM Servidores" with OCSP attribute.

2) Although All subCA could issue any kind of certificate policy, the assignment is as follows:
- Certification Policies for Qualified certificates of signature on secure centralised device -> ACEDICOM01 | ACEDICOM 02
- Certification Policies for Qualified certificates of signature on secure centralised device for electronic invoicing and certified storage. -> ACEDICOM01 | ACEDICOM 02
- Identification Policies for Qualified certificates of signature on secure centralised "Smart Card" device. -> ACEDICOM01 | ACEDICOM 02
Certification Policies for Qualified certificates of signature on Software support. -> ACEDICOM01 | ACEDICOM 02
- Política de Certificados TLS para cliente y servidor -> "ACEDICOM Servidores"

3)The policy documents talking about code signing is "Política de Certificados TLS para cliente y servidor". When talking about identity checks, CPS is related. That's physical presence and company documentation is needed for the identity validation process.
The subCA that issue code signing certificates is "ACEDICOM Servidores"

4) For SSL certificates identity/organization is verified also but It's not needed physical validation as on qualified certificates.
 
5) Policy "http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf" was defined and approved at June 2008. But It was "released" 2009-03-26. I mean, until now no certificate was issued with this policy. ACEDICOM was waiting passing this process to make this policy public, but as It was necessary to issue test certificates we "released" the policy and made it public.
The policy was included on the audit process and also the subCA "ACEDICOM Servidores". "ACEDICOM Servidores" was signed by "ACEDICOM Root" at 04/28/08 09:53:40 GMT. You can check this on its certificate.

6) Audit process by s21 included the root CA and all the level 2 CAs, as described on section "3 ALCANCE DE TRABAJO" ("SCOPE OF THE PROCESS"):
Original Text:
- La propia AC raíz creada por EDICOM
- Las Entidades de Certificación de nivel 2

English translation:
- The root CA created by EDICOM.
- Level 2 certification authorities

That is: "ACEDICOM Root", "ACEDICOM 01", "ACEDICOM 02, "ACEDICOM Servidores" were the level 2 CAs at that moment.

Thanks,
Raúl.

Comment 10

[Kathleen Wilson]

Thank you for the additional information.

Please review the ACEDICOM entry on the pending list for accuracy/completeness:
http://www.mozilla.org/projects/security/certs/pending/#ACEDICOM

>> If you need it, I can provide test certificate issued from "ACEDICOM Servidores" with OCSP attribute.

Yes, please.

>> 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. As such, I will contact the person listed in the audit report.

Thanks,
Kathleen

Comment 11

[Raúl Santisteban]

Attachment: Test certificate with OCSP

Comment 12

[Raúl Santisteban]

I attach  "Test certificate with OCSP" so you can test OCSP service.

Comment 13

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 14

[Kathleen Wilson]

This completes the Information Gathering and Verification phase as per
https://wiki.mozilla.org/CA:How_to_apply

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

Comment 15

[Raúl Santisteban]

Is there any scheduled date so ACEDICOM starts public discussion. It has been on queued state since April. If It's required additional information please told me.
Thanks.

Comment 16

[Kathleen Wilson]

We apologize for the delay. There has been a large backlog of requests waiting to go through the public discussion phase.

According to
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
there are still 10 requests ahead of yours in the queue. Each discussion takes at least one, usually two weeks.

A couple of weeks before your request is expected to enter into discussion, I will re-review the information that has been gathered and will post here if any information needs to be updated.

Comment 17

[Kathleen Wilson]

This request is nearing the top of the queue for public discussion, as per
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Would you please update the test website, https://cartero.edicom.es/RootCertificatePrograms/test.htm, to have an SSL cert that has the CRL Distribution Points Extension set, and also has the Authority Information Access Extension set to refer to the OCSP responder?

The audit statement that I currently have is dated September 15, 2008. Do you happen to have an audit statement for this year?

Mozilla is also now requesting the following contact information for CAs.

CA Email Alias: Please provide an email alias that includes the people in your company who should receive correspondence from Mozilla in regards to root certificates. An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organization.

CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.

Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?

Comment 18

[Raúl Santisteban]

Attachment: Ernst and Young Webtrust audit start

This files shows E&Y Webtrust audit start for ACEDICOM.

Comment 19

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 20

[Raúl Santisteban]

Certificate for web site
https://cartero.edicom.es/RootCertificatePrograms/test.htm
update with required information (CRL and OCSP)

Comment 21

[Raúl Santisteban]

Related to the audit statements, as attached file "Ernst and Young Webtrust audit start" shows ACEDICOM is now been reviewed to get webtrust certified. 

Contact information for the CA:
e-mail alias of CA : [e-mail]
CA Phone number: [phone]
Title/Department: IT Systems Department
Contact Person: Raúl Santisteban

Comment 22

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the info gathering document in preparation for public discussion.

Comment 23

[Kathleen Wilson]

I am now opening the first public discussion period for this request from ACEDICOM to add the “ACEDICOM Root” root certificate and enable all three trust bits (websites, email, code signing).

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

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

Note: For the time being, Google Groups is not working for Mozilla discussions. Please either use a newsreader like Thunderbird, and/or subscribe to the mozilla.dev.security.policy newsgroup by email.

Comment 24

[Kathleen Wilson]

There have been two postings so far in the discussion, that are waiting for a response. 

A representative of ACEDICOM should respond directly in the discussion thread to all questions that are posted. Please do so promptly, so that we can complete this discussion as soon as possible.

Comment 25

[Kathleen Wilson]

The public comment period for this request is now over. 

There are two resulting action items:

ACTION ACEDICOM: When the new audit statement is available, update this bug to either attach the document or to provide a link to it.

ACTION Kathleen: Review the new audit statement, and follow Mozilla procedures to confirm the authenticity of the audit statement.

After I have reviewed the new audit statement and confirmed the authenticity as per Mozilla procedures, I plan to post my recommendation for approval in this bug.

Comment 26

[Raúl Santisteban]

Attachment: ACEDICOM Webtrust audit report

ACEDICOM Webtrust audit report, spanish version of the document.

Comment 27

[Raúl Santisteban]

Attachment "ACEDICOM Webtrust audit report" contains webtrust audit result. It can also be downloaded from https://cert.webtrust.org/ViewSeal?id=1001

Comment 28

[Kathleen Wilson]

Thank you for providing the new audit report. Since it is posted on the cert.webtrust.org website, I do not have to do an independent verification of the document.

Audit Type: WebTrust CA
Auditor: Ernst & Young

The document looks to be of standard WebTrust CA form, and I didn't note anything unusual.

It appears that the audit covers the ACEDICOM root, and its ACEDICOM 01 and ACEDICOM 02 sub-CAs. 

I do not see reference to the ACEDICOM Servidores sub-CA in the audit report or management's assertions.

Comment 29

[Raúl Santisteban]

Initial webtrust scope was defined before "ACEDICOM Servidores" went into production. ACEDICOM Servidores hasn't still issued any certificates but for internal use, because we are waiting until this Mozilla process has been finished. The whole infrastructure for all ACEDICOM SubCAs is managed by the same Edicom technical people, following the same procedures.

"ACEDICOM Servidores" will be included on 2010 webtrust audit process. 
Considering this, ACEDICOM has decided not to issue any certificate with "ACEDICOM Servidores" until next webtrust review. Then , certificates under policy "Política de Certificados TLS para cliente y servidor" will be issued only by "ACEDICOM 01" or "ACEDICOM 02", which has been included in Webtrust audit scope until next webtrust review this year.

Comment 30

[Kathleen Wilson]

I was under the impression that the "Política de Certificados TLS para cliente y servidor" document only applied to the "ACEDICOM Servidores" sub-CA. So I would expect that since the "ACEDICOM Servidores" sub-CA was not covered in the audit, that the policies documented in "Política de Certificados TLS para cliente y servidor" would not have been part of the audit either.  

Have I misinterpreted the information?

We depend on the auditors to confirm that the documented verification practices and policies are truly in place and being followed.

Comment 31

[Raúl Santisteban]

I'm sorry for the mismatch,
Certificates The  policy "Política de Certificados TLS para cliente y servidor" can be issued under any ACEDICOM subCA. In order to have some kind of distribution administratively, "ACEDICOM servidores"  was created to don't mix qualified and not qualified certificates. This was an internal decision and It's what I tried to explain on public discussion forum.
But, there is no technical problem and all procedures allow us to issue certificates under "Política de Certificados TLS para cliente y servidor" any subCA.
As "ACEDICOM Servidores" has not been included on the final audit report, despite It was reviewed by auditors, and following your advice, ACEDICOM has compromised to just issue those certificates with subCAs included on the report.

I hope I has explained it well. Now, and taking into consideration your doubts , we have asked to the auditors for a report explaining which policies were included on the audit process.

I don't know how many days can this report take. I'll try to update this bug as soon as possible with that report.

I hope this information helps. And we'll wait for the report.

Comment 32

[Raúl Santisteban]

Attachment: E&Y auditors policies attachment

Comment 33

[Raúl Santisteban]

I add the document "E&Y auditors policies attachment" issued by the auditors to clarify doubts about if policy "Política de Certificados TLS para cliente y servidor" was included or not on the webtrust audit process.
I'm sorry because of the delay, but the signature of the partner took a lot of time.

Comment 34

[Kathleen Wilson]

As per comment #25, the public comment period resulted in two actions:

> ACTION ACEDICOM: When the new audit statement is available, update this bug
> to either attach the document or to provide a link to it. 

ACEDICOM has completed their WebTrust CA audit:
https://cert.webtrust.org/ViewSeal?id=1001

> ACTION Kathleen: Review the new audit statement, and follow Mozilla 
> procedures to confirm the authenticity of the audit statement. 

The audit report is posted on the cert.webtrust.org website, so I do not need to confirm the authenticity of the audit statement.

After reviewing the audit report, I asked for clarification about what the audit covered. As per Comment #32, Ernst & Young has provided a statement about what their recent audit covered, including “Certificados TLS para cliente y servidor”.

>  After I have reviewed the new audit statement and confirmed the authenticity 
> as per Mozilla procedures, I plan to post my recommendation for approval in 
> this bug.

The action items have been completed. Therefore, I plan to post my recommendation for approval in this bug.

Comment 35

[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 to add a new root CA certificate for ACEDICOM. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by ACEDICOM, 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]. ACEDICOM appears to provide a service relevant to Mozilla users: It is a commercial CA covering all countries of the European Union.

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 Certification Practices Declaration (CPS), which has been translated into English; and the TLS Certificate Policy (CP), which is in Spanish. The ACEDICOM website also contains links to all of the CP documents for their qualified certificates that are issued under two separate sub-CAs of this root.

** CPS in English: http://acedicom.edicomgroup.com/en/archivos/politicas/ACEDICOM_CertificationPractice.pdf

** TLS CP -- for the sub-CA that issues non-qualified certificates including websites, email, and code signing
http://acedicom.edicomgroup.com/es/archivos/politicas/ACEDICOM%20-%20Politica%20Certificados%20TLS.pdf

** All of the other CP documents listed on the following website are for the two sub-CAs that issue Qualified certificates
http://acedicom.edicomgroup.com/en/contenidos/practicasyPoliticas/punto1.htm


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

* Email: According to section 3.2.2 of the TLS CP, a challenge-response check is performed to confirm that the certificate subscriber owns/controls the email address to be included in the certificate. 
** Translation of the text: In the process of verifying the ownership of an email address, ACEDICOM 
included in the email and unique random string, which will form a challenge. The email recipient will respond to the challenge by following the instructions in the email itself. This challenge is unambiguously associated with the application for issue of certificate. When the operator of record establishes that challenge response is correct, will be demonstrated ownership of the email address and you can continue the process of validation and certificate issuance. These validation processes of control or ownership of the email address are required for each request on issue or renewal. 

* SSL: According to section 3.2.2 of the TLS CP, ACEDICOM verifies that the certificate subscriber owns/controls the domain name to be included in the certificate by performing a challenge-response check which involves sending email to the administrative contact of the domain name as found via whois.

* Code: ACEDICOM’s CPS and TLS CP describe reasonable measures to verify the identity and authorization of the certificate requester. 

Section 8-10 [Audit]. Section 8-10 [Audit]. 
* ACEDICOM is audited annually. Their most recent audit was performed by Ernst & Young according to the WebTrust CA audit criteria, and is available here: https://cert.webtrust.org/ViewSeal?id=1001. 

Section 13 [Certificate Hierarchy]. 
* This root has three internally-operated subordinate CAs. The ACEDICOM 01 subordinate CA issues Qualified certificates for identification and advanced electronic signature, for the use of physical persons or legal organizations. The ACEDICOM 02 subordinate CA issues certificates for purposes other than Qualified electronic signature. The ACEDICOM Servidores subordinate CA issues non-qualified server/client certificates and code signing certificates. The TLS CP describes the verification procedures for certificates issued by the ACEDICOM Servidores subordinate CA.

Other: 
* NextUpdate for the CRLs for end-entity certs is 24 hours.
* OCSP is provided.

Potentially problematic practices: None noted.

Based on this assessment I intend to approve this request to add the “ACEDICOM Root” root certificate to NSS, and enable all three trust bits.

Comment 36

[Kathleen Wilson]

To the representatives of ACEDICOM: 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 #35, and on behalf of the Mozilla project I
approve this request from ACEDICOM to include the following root certificate in
Mozilla, with trust bits set as indicated:

* ACEDICOM Root (web sites, email, code signing)

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

Comment 37

[Kathleen Wilson]

I have filed bug 550521 against NSS for the actual changes.

Comment 38

[Kathleen Wilson]

In Firefox 3.6.7.