1239329 - Add Renewed ACEDICOM root certificate(s)

Status: RESOLVED WONTFIX

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

Description

[Raúl Santisteban]

Attachment: Webtrust Audit Report and Management's Assertions

CA Details
----------
Original bug inclusion bug number is 471045.

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

CA Name: CAEDICOM ROOT
Website: https://acedicom.edicomgroup.com/en/index.htm
One Paragraph Summary of CA, including the following:
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 
ACEDICOM acomplish with all the requirements specified by Mozilla Policy and It would be really interesting for Mozilla products users include "ACEDICOM Root" Certificate.

In this bug EDICOM is applying for include renewed EDICOM Root, which is issued using SHA256 as following best practices. It's necessary that both Root can be together at Trusted Root repository as a transition time is required.

Last audit process covers both new and old Root Certificate Authorities chain.

Audit Type : Webtrust
Auditor: Auren
Auditor Website:http://www.auren.com/en-IN
Audit Document URL(s):https://cert.webtrust.org/ViewSeal?id=1958

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

Certificate Name: "CAEDICOM Root"
Summary Paragraph, including the following:
New Edicom Certification Authority tree is based on a Root CA (CAEDICOM Root), and a subordinate CA (CAEDICOM01) at this bug creation time.
CAEDICOM Root only issues certificates for subordinate CAs. Nowadays, only subCA "CAEDICOM01" certificate has been signed by "CAEDICOM ROOT".

Certificate Practices Statement can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf

Certificate Policy can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Extended key usages in end entity certificates issued CAEDICOM01 (the only subCA) are:
    * Server Authentication
    * Client Authentication
    * Secure E-mail

Section 3.1 , 3.2 and 3.3 of the Policy specifies the control process followed by Edicom Registration Authority operators to ensure identity accreditation as one of the steps of the issue process.



No external management or subCA is considered under Edicom CPS. No subordinate CA is managed by third party.

Certificate download URL (on CA website):
Version: 
SHA1 Fingerprint: 6C:29:BC:40:BC:0E:C3:7F:78:7E:94:BC:96:2B:C8:D1:FC:A3:58:E4
SHA256 Fingerprint:6D:F0:7B:6A:14:DC:38:44:7C:11:68:9A:FE:23:04:41:AA:F7:58:63:AE:FE:06:1D:48:92:E2:9B:94:1C:2F:51
Public key length (for RSA, modulus length) in bits: 4096
Valid From (YYYY-MM-DD): 2014-05-21
Valid To (YYYY-MM-DD): 2034-05-21

This Root has not be involved in cross signing.

CRL HTTP URL: http://acedicom.edicomgroup.com/caedicomroot.crl
CRL issuing frequency for subordinate end-entity certificates: 24 hours (CRLs issued by CAEDICOM01)
CRL issuing frequency for subordinate CA certificates: 90 days (CRLs issued by CAEDICOM ROOT)
OCSP URL: http://ocsp.acedicom.edicomgroup.com/caedicomroot

Requested Trust Indicators (email and/or SSL and/or code signing):
URL of example website using certificate subordinate to this root
https://rootcertificateprograms.edicom.es/

Problematic Practices (https://wiki.mozilla.org/CA:Problematic_Practices) and Recommended Practices (https://wiki.mozilla.org/CA:Recommended_Practices) are covered in the same way as the actual Root.

Comment 1

[Raúl Santisteban]

Management of the Problematic Practices described at https://wiki.mozilla.org/CA:Problematic_Practices

** Long-lived DV certificates **
2 years is the maximum valid certificate expiration data, as stated at section 7.1.2.5 of the Policy document.

** Wildcard DV SSL certificates **
The wilcards in names are not allowed. Thus, although wildcards, like CN =*.domain.tld , are common an accepted on the Internet, certificates containing a wildcard will not be issued under this policy. There is one exception: the certificates issued for domains under the control of the organization administering Edicom  it may contain wildcards and Edicom always have control of the domains and subdomains for which the organization
"3.1.7 Using wildcards in the names" of the Policy describe this.

** Delegation of Domain / Email validation to third parties **
Edicom own operators are in charge of domain/e-mail validation requirements described in sections 3.1 , 3.2 and 3.3 of the Policy

** Issuing end entity certificates directly from roots **
This is not allowed. "CAEDICOM Root" just issue subCA certificates.

** Allowing external entities to operate subordinate CAs **
No third party management is considered

** Distributing generated private keys in PKCS#12 files **
User keys are  generated by the user and then the user sends the certificate sign request, as specified on the following sections of the policy 6.1

** Certificates referencing hostnames or private IP addresses **
Special IP addresses (RFC 3330) are not allowed as a domain name on server certificates, as described 
on the section 3.1.1 of the policy.

** Issuing SSL Certificates for Internal Domains **
Internal Domains are not valid for CAEDICOM certificates, as described on the section 3.1.1 of the policy.

** OCSP Responses signed by a certificate under a different root **
OCSP responses are signed by Root certificate

** SHA-1 Certificates **
All certificates under this CA tree "CAEDICOM ROOT" -> "CAEDICOM01 " -> "End entity Certificate" use SHA256

** Generic names for CAs **
Subject of "CAEDICOM Root" describes perfectly the company:
CN=CAEDICOM01/serialNumber=B96490867, O=EDICOM, L=Calle Charles Robert Darwin 8 - 46980 - Paterna, C=ES

** Lack of Communication With End Users **
Different communication channels (website, e-mail, phone) are open for end-users or third party.
** Backdating the notBefore date **
"CAEDICOM Root" notBefore date is the same as issue date.

Comment 2

[Raúl Santisteban]

Management of Recommended Practices at "https://wiki.mozilla.org/CA:Recommended_Practices"

** Publicly Available CP and CPS **
CAEDICOM CP/CPS documents are publicly available at the official web site http://acedicom.edicomgroup.com
Certificate Practices Statement can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf
Certificate Policy can be found at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Both documents are in PDF format and in English version.
References to this document are used across this bug documentation

** CA Hierarchy **

New Edicom Certification Authority tree is based on a Root CA (CAEDICOM Root), and a subordinate CA (CAEDICOM01) at this bug creation time.
CAEDICOM Root only issues certificates for subordinate CAs. Nowadays, only subCA "CAEDICOM01" certificate has been signed by "CAEDICOM ROOT".
End entity certificates are issued by "CAEDICOM01"

** Audit Criteria **
Audit public document is located at https://cert.webtrust.org/ViewSeal?id=1958
The audit is based on Webtrus plus CAB Forum Baseline requirements

** Document Handling of IDNs in CP/CPS **
No internationalized domain names are allowed at certificates issued by CAEDICOM.

** Revocation of Compromised Certificates **
Revocation of compromised Certificate procedures  procedures and causes are described at section 4.8 of the Certificate Practices Statement.

** Verifying Domain Name Ownership **
Section 3.1 , 3.2 and 3.3 of the Policy specifies the control process followed by Edicom Registration Authority operators to ensure identity accreditation as one of the steps of the issue process. This includes Domain name ownership verification.

** Baseline Requirements **
Audit statements indicates how CAEDICOM accomplish with Baseline Requirements

** WHOIS **
For domain validation whois services are used. Section 3.2 of the policy states that, administrative contact e-mail of whois is the information used to validate the domain.
In any case CAEDICOM reserves the right of require physical presence of the applicant or person authorized by him in the registration points in order to provide documentation and conduct appropriate identity checks, as detailed in de Certificate Practice Statement in 3.2.2 and 3.2.3


** Email Challenge-Response / Verifying Email Address Control **
For the e-mail validation, as described in such section, CAEDICOM will send an e-mail , which will include a non repeatable random key (challenge)
The e-mail receiver will respond using provided instruction, so using such challenge the response is matched with the initial e-mail validation process. Once the operator matches it, e-mail validation is completed.
These validation processes are mandatory for each certificate before issuing it.

** DNS names go in SAN **
Sample certificates have been validated by auditors to check that this requirements are satisfied

** Domain owned by a Natural Person **
Proposal is compatible with actual certificate profile.

** OCSP **
OCSP Server has been checked at the audit process.

** Network Security Controls **
Network Security Controls have been audited against "WebTrust Principles and Criteria  SSL Baseline with Network Security – Version 2."
Regular audits are planed and cover all the recommended points:
- Webtrust : annually . Public report available. Last one: https://cert.webtrust.org/ViewSeal?id=1958
- ISO27001 Certification: annually. Public report available.http://www.edicomgroup.com/es_ES/dms/Edicom/Certifications/ISO_27001/ISO%2027001.pdf

Comment 3

[Kathleen Wilson]

Beginning information verification as described here:
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 4

[Kathleen Wilson]

Attachment: 1239329-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the attached document).

Comment 5

[Raúl Santisteban]

Additional information covers questions in the attachment "1239329-CAInformation.pdf"

Certificate Authorities of Edicom are targeted to private customers, legal or natural person. EDICOM works with companies worldwide to help them achieve ongoing growth and profits and is now the technology provider for B2B communications project development and data integration. Global market is the focus of Edicom certificate customers.

TLS CP is full translated into English. In can be reached throw https://acedicom.edicomgroup.com/en/index.htm 
and directly at:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf

CP is now full translated into English, so for the Email Address Verification question, now the sections referenced can be reviewed in English.
Edicom own operators are in charge of domain/e-mail validation requirements described in sections 3.1 , 3.2 and 3.3 of the Policy
For domain validation whois services are used. Section 3.2 of the policy states that, administrative contact e-mail of whois is the information used to validate the domain.
In any case CAEDICOM reserves the right of require physical presence of the applicant or person authorized by him in the registration points in order to provide documentation and conduct appropriate identity checks, as detailed in de Certificate Practice Statement in 3.2.2 and 3.2.3

Comment 6

[Raúl Santisteban]

Errors listed at 
https://certificate.revocationcheck.com/rootcertificateprograms.edicom.es
have been solved

Comment 7

[Kathleen Wilson]

Attachment: 1239329-CAInformation.pdf

Comment 8

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 9

[Kathleen Wilson]

We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
no errors (certificate not found via CT)

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://rootcertificateprograms.edicom.es/'

Using certificate from local file 'CAEDICOMRoot.cer'

    /CN=rootcertificateprograms.edicom.es
        Notice
            CN could be encoded as PrintableString
        Error
            Certificate Policy explict text must not be VisibleString or BMPString
            Unallowed key usage for RSA public key
~~

Please add a comment in this bug when the errors have been resolved.

Comment 10

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #9)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

Comment 11

[Raúl Santisteban]

Actual URL checks provides different output. Can you please confirm If we should work on this new output?



Using certificate chain from 'https://rootcertificateprograms.edicom.es/'

Using certificate from local file 'CAEDICOMRoot'

    /CN=rootcertificateprograms.edicom.es
        Warning
            Extension should be critical for KeyUsage
        Error
            Unallowed key usage for RSA public key
        Informational
            TLS Server certificate identified

    /CN=CAEDICOM01/serialNumber=B96490867/O=EDICOM/L=Calle Charles Robert Darwin 8 - 46980 - Paterna/C=ES
        Informational
            CA certificate identified
        Warning
            CA certificates should not include subject alternative names

    /CN=CAEDICOM Root/O=EDICOM/C=ES
        Informational
            CA certificate identified
        Warning
            CA certificates should include Digital Signature to allow signing OCSP responses

Comment 12

[Kathleen Wilson]

(In reply to Raúl Santisteban from comment #11)
> Actual URL checks provides different output. Can you please confirm If we
> should work on this new output?
> 
> 
> 
> Using certificate chain from 'https://rootcertificateprograms.edicom.es/'
> 
> Using certificate from local file 'CAEDICOMRoot'
> 
>     /CN=rootcertificateprograms.edicom.es
>         Warning
>             Extension should be critical for KeyUsage
>         Error
>             Unallowed key usage for RSA public key


Yes that's what I'm seeing now too. Please add a comment in this bug when the error (Unallowed key usage for RSA public key) is resolved. 
Note that the test is Powered by https://github.com/awslabs/certlint so if you find it is a problem in the test, then file an Issue in github, and add a comment in this bug to clarify.
Thanks.

Comment 13

[Raúl Santisteban]

Errors reported at tool
https://cert-checker.allizom.org/
Have been solved.

Comment 14

[Kathleen Wilson]

(In reply to Raúl Santisteban from comment #13)
> Errors reported at tool
> https://cert-checker.allizom.org/
> Have been solved.

Confirmed -- no errors.

Comment 15

[Kathleen Wilson]

Raúl, when do you expect to have the 2016 audit statements?

Comment 16

[Raúl Santisteban]

We are working on the audit process with the Third Party since first week of October. We've just asked for a estimated report delivery date. As soon as the Thir party answer I'll update with the answer.

Comment 17

[Kathleen Wilson]

(In reply to Raúl Santisteban from comment #16)
> We are working on the audit process with the Third Party since first week of
> October. We've just asked for a estimated report delivery date. As soon as
> the Thir party answer I'll update with the answer.

Any update?

Comment 18

[Raúl Santisteban]

Attachment: EDICOM Certificate WebTrust.pdf

Webtrust letter

Comment 19

[Raúl Santisteban]

As the final report is being delayed, we asked to the audit company to provide some kind of bridge letter, attached as "EDICOM Certificate WebTrust.pdf"

Comment 20

[Kathleen Wilson]

Attachment: 2016-Edicom-BR-Audit.pdf

Audit statement signed January 24, 2017. Still waiting for the official seal to be posted.

Comment 21

[Raúl Santisteban]

New webtrust Seal can be found at:
https://cert.webtrust.org/ViewSeal?id=2201

Comment 22

[Kathleen Wilson]

Raúl, Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 23

[Raúl Santisteban]

Attachment: BR Self Assesment

As requested, we attach BR Self Assesment ocording to current version of BR.

Comment 24

[Aaron Wu]

Hi Raúl,

Thanks to provide BR Self Assessment, I am doing verification on each session currently.

One thing need your input first, please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.

Thank you so much!

Regards,
Aaron

Comment 25

[Raúl Santisteban]

Hello Aaron,
The three URLs are:

https://rootcertificateprogramsrevoked.edicom.es
https://rootcertificateprogramsexpired.edicom.es
https://rootcertificateprograms.edicom.es/

Comment 26

[Aaron Wu]

(In reply to Raúl Santisteban from comment #25)
> Hello Aaron,
> The three URLs are:
> 
> https://rootcertificateprogramsrevoked.edicom.es
> https://rootcertificateprogramsexpired.edicom.es
> https://rootcertificateprograms.edicom.es/

Hi,

Thanks for your test websites!

The error message is shown once testing:
Forbidden Error: You don't have permission to access / on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Could you please check and fix?

Regards,
Aaron

Comment 27

[Raúl Santisteban]

Hello Aaron,
It's fixed. 

Regards,
Raúl.

Comment 28

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 29

[Kathleen Wilson]

I'm reviewing the data provided by this CA, and I find the following:

TSL CP:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM%20-%20TLS%20Certificates%20Policy.pdf
Date: 29/06/15

CPS:
https://acedicom.edicomgroup.com/en/archivos/politicas_caedicom/1_0/CAEDICOM01%20-%20CertificationPractices.pdf
Date: 28/04/14

Are those the current versions of the CP/CPS?

If yes, how can they be compliant with a reasonably current version of the BRs?

Also, when do you expect to have new audit statements?

Comment 30

[Raúl Santisteban]

Attachment: PSC 2017 0001 EDICOM.pdf

Comment 31

[Raúl Santisteban]

Those were the links of the "current" version when creating this BUG. Obviosly they have been updated during this time.

Current version:
TSL CP:
https://acedicom.edicomgroup.com/eu/CAEDICOM01_CP_TLSCertificatesPolicy.pdf
Date 20/09/2017

CPS:
https://acedicom.edicomgroup.com/eu/CAEDICOM01_CPS_CertificationPracticeStatement.pdf
Date 14/06/2017

Regarding to the audit statements. I'vbe attached our last audit statement, which will be based from now on on new ETSI standards.
Next April is planned to start the new Audit process since last audit finished on June 2017.

Comment 32

[Kathleen Wilson]

(In reply to Raúl Santisteban from comment #31)
> Those were the links of the "current" version when creating this BUG.

I copied those links out of the attached BR Self Assessment document. 
So, which version of the documents were used for your BR Self Assessment?
Perhaps you should update your BR Self Assessment to compare your current CP/CPS with the current version of the BRs.


> Obviosly they have been updated during this time.
> 
> Current version:
> TSL CP:
> https://acedicom.edicomgroup.com/eu/CAEDICOM01_CP_TLSCertificatesPolicy.pdf
> Date 20/09/2017
> 
> CPS:
> https://acedicom.edicomgroup.com/eu/
> CAEDICOM01_CPS_CertificationPracticeStatement.pdf
> Date 14/06/2017

I will use those versions.


> 
> Regarding to the audit statements. I'vbe attached our last audit statement,

The attached audit statement is not sufficient:

1) It does not state the audit period, and so I cannot confirm that there is an unbroken sequence of audit periods. 
Note that the previous audit statement (https://cert.webtrust.org/SealFile?seal=2201&file=pdf) was for audit period October 31, 2015, to October 30, 2016.

2) It does not indicate enough detail regarding the type of audit
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#etsi

3) It does not contain all of the required information:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information

Comment 33

[Raúl Santisteban]

Attachment: AENOR Anexo ETSI al certificado PSC-20170001 - INTERCAMBIO ELECTRONICO DE DATOS Y COMUNICACIONES(CAR).pdf

Attached the new Audit Statement

Comment 34

[Raúl Santisteban]

Can you please provide any status update?
Thanks,

Comment 35

[Kathleen Wilson]

Attachment: 1239329-CA-Information-Oct18-2018.pdf

The attached file shows the CA information that has been verified. Search in the document for the word "NEED" to see where further clarification is requested.

In particular:

1) Audit statements must also be provided in English, per:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

2) Recognized CAA domains must be listed in CP or CPS, per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS

3)  Need Complete Audit History, per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History
Also note:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
"Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually. Successive audits MUST be contiguous (no gaps)."
This root has validFrom: 5/21/2014
https://bugzilla.mozilla.org/attachment.cgi?id=8707470 - audit period 10/31/2014-10/30/2015
WebTrust CA - https://bugzilla.mozilla.org/attachment.cgi?id=8816896
WebTrust BR - https://bugzilla.mozilla.org/attachment.cgi?id=8841805 - 10/31/2015-10/30/2016
ETSI EN 319 411 - https://bugzilla.mozilla.org/attachment.cgi?id=9003448 - 6/19/2017 - 4/24/2018
***So it appears that we do not have audits for this root that cover the audit period 10/31/2016 - 6/18/2017. 

4) Fix Revoked and Expired test websites.
Currently they result in Error code: SSL_ERROR_BAD_CERT_DOMAIN
The certificate is only valid for rootcertificateprograms.edicom.es.
Test Website - Revoked: https://rootcertificateprogramsrevoked.edicom.es/ 	 
Test Website - Expired: https://rootcertificateprogramsexpired.edicom.es/

5) Resolve all lint testing errors
https://crt.sh/?caid=14975&opt=cablint,zlint,x509lint&minNotBefore=2014-05-21
https://crt.sh/?caid=15530&opt=cablint,zlint,x509lint&minNotBefore=2014-05-21

Comment 36

[Raúl Santisteban]

Attachment: PSC-2017/0001

English translation of the audit report.

Comment 37

[Andrew Ayer]

A CA chaining to this root has issued the following TLS server (pre)certificates that are valid for www.test1.com:

https://crt.sh/?sha256=dd128f802f1444c1f3497b9ac1667d9f04d57ba715f72d190444866a228c9016
https://crt.sh/?sha256=af1c6e7eedb0ff033ccd248e00453ab993d5e6ec09c663e07b9f6b7d45e5d720
https://crt.sh/?sha256=faa5b302aeb33db2ce9cec7f21c79e09b86a947c123dbe2720dc15632c682a09
https://crt.sh/?sha256=eb6ccad62c122ae9900a872fb1083985a39f11748c859f07a125b05bf4f40ed8
https://crt.sh/?sha256=330789e0f6b59e37b6ef9df045ee7ac4eadedfab53f173e5c6a8a73d8b77ffcf

Could EDICOM please comment on how these certificates were validated?

Comment 38

[Raúl Santisteban]

Attachment: 2019 AENOR Anexo 2 ETSI 319 411-2 PSC-EDICOM_v4.pdf

New audit statement ETSI 319 411-2

Comment 39

[Raúl Santisteban]

Attachment: 2019 AENOR Anexo 1 ETSI 319 411-1 PSC-EDICOM_v4.pdf

New audit statement ETSI 319 411-1

Comment 40

[Kathleen Wilson]

I am denying this request to include the "CAEDICOM Root" that is valid from 5/21/2014. This CA is welcome to generate a new (fully BR Compliant) root certificate and CA hierarchy, and re-apply for inclusion by opening a new Bugzilla Bug and Root Inclusion Case as described here:
https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request

Reasons for denying inclusion of this root certificate:

1. No response to the questions in Comment #37 about the domain verification procedures that were used to issue pre-certs to the www.test1.com domain.
2. The potential audit gap from 10/31/2016 to 6/18/2017 (see Comment #35)
3. Many of the items listed in Comment #35 have not yet been fully addressed.

A summary of the information that has been used to evaluate this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000077