274100 - Add ACCV CA certificate (Spain)

Status: RESOLVED FIXED

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

Description

[Frank Hecker]

ACCV (Autoritat de Certificacio de la Comunidat Valenciana) is a CA operated by
the government of the Valencia region of Spain. CPS and CPs (in Spanish) can be
found at

  http://www.pki.gva.es/legislacion_c.htm

The root CA certificate data can be found at

  http://www.pki.gva.es/ca_c.htm

Note that only the certificate at

  http://www.pki.gva.es/gestcert/rootca.crt

is a true root certificate; the certificate at

  http://www.pki.gva.es/gestcert/ca.crt

is for an intermediate CA under the root CA. According to our policies only the
root CA certificate will be considered for inclusion.

I can't find any information about audits for this CA, WebTrust or otherwise.

Comment 1

[Frank Hecker]

Correcting a typo: The full name of the CA is "Autoritat de Certificacio de la
Comunitat Valenciana" ("Comunitat", not "Comunidat"). Also, I'm officially
accepting the bug as being assigned to me.

Comment 2

[Jose Amador]

Hi

Two years later, we have obtained WebTrust Seal. The link is https://cert.webtrust.org/ViewSeal?id=571. 

I don´t know if you need any more.

Waiting for your news.

Thanks in advance.

Comment 3

[Frank Hecker]

Congratulations on completing your WebTrust audit, and thanks for the information. Note that we will have to make a decision on whether it makes sense to include CAs for this or any other jurisdiction below the national/country level. See my comment in bug 342503:

"In the past I've approved including CA certificates for CAs operated by national governments (e.g., for the Netherlands and Taiwan), if those CAs issue certificates to the general public, because in my opinion doing this was of benefit to typical users of Mozilla-based products.

However I agree ... that it is hard to justify including root CA certificates for CAs operated by municipal governments (or in general CAs operated by any regional government), given the large number of such governments and the relatively small populations served by each one."

Comment 4

[Jose Amador]

We 'll wait for your decision. For your information, the Valencia region has five million inhabitants (without counting tourists) and five hundred twenty-four cities.

Regards

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

This is an enhancement request.

Comment 6

[Gervase Markham [:gerv]]

Sr Amador,

- Which trust bits are you requesting (websites, email, and/or code)?

- Can you summarise, in a paragraph, the intended use for this root certificate?

Thanks,

Gerv

Comment 7

[Jose Amador]

Dear Sr Markham

Our CA issues certificates for persons (with email), web sites and for signing code, in different policies, but with the same root.

We are a public certificate service provider and the intended use for this root certificate is to improve the electronic administration between our citizens and the administration.

If you need more information, please, say us.

Thanks,

Jose Amador

Comment 8

[Gervase Markham [:gerv]]

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration. [Note: the special circumstances applying to your CA still apply.]

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv

Comment 9

[Jose Amador]

Yes. The informatión for our CA is correct.

Only one thing. Why the type is unknown ?

Comment 10

[Gervase Markham [:gerv]]

My apologies; I should have asked about that. Do you issue domain-validated, identity/organisationally-validated or Extended Validation SSL certificates, or some mixture of the above?

Gerv

Comment 11

[Jose Amador]

No problem. We issue a mixture. Mainly identity/organisationally-validated certificates for everyone, but also we issue SSL certificates and domain-validated for public organizations.

Regards

José Antonio

Comment 12

[Gervase Markham [:gerv]]

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

Gerv

Comment 13

[Gervase Markham [:gerv]]

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

Gerv

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	

Comment 15

[Toni Hermoso Pulido]

Any advance on this?
As I read in the previous comment, information is complete, isn't?
Different Spanish certificate bugs seem to be stalled by no apparent reason for years.

Comment 16

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

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

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

Attached is the Initial Information Gathering document which shows the information previously gathered, and highlights in yellow where additional or updated information is needed. I will also summarize below where further clarification or updates are needed.

1) Please provide a diagram or description of the CA hierarchy, showing all of the subordinate CAs of this root and the types of end-entity certificates that they issue.
a) For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CP/CPS documents, and that any audit covers them as well as the root.
b) Does this root have any subordinate CA’s that are operated by external third parties?
c) Has this root been involved in cross-signing with another root?

2) Do you 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?

3) Please provide translations into English of sections of CP/CPS documents pertaining to:
•Verification of Identity and Organization
•Verification of ownership/control of domain name for SSL certs
•Verification of ownership/control of email address for email (S/MIME) certs
•Section 7 of http://www.mozilla.org/projects/security/certs/policy/
•Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices

5) The WebTrust audit is from 2006. Do you have a more recent audit?

6) For testing purposes, please provide a URL to a website whose SSL certificate chains up to this root. 

7) What is the nextUpdate set to in the CRL for end-entity certificates?

Comment 17

[Jose Amador]

Hi 

Attach the translation into English of CPS. 
Also sending the link of the latest audit (2009 july) 
https://cert.webtrust.org/SealFile?seal=943&file=pdf

Regards

Comment 18

[Jose Amador]

Attachment: CPS ACCV (English) v1.7

Comment 19

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thank you for providing an updated audit, and for translating the CPS into English.

The document that I am attaching here summarizes the information that has been gathered and verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 20

[Jose Amador]

Hi 

Attach the translation into English of the latest Webtrust audit. 
Also send the answer document with the requested translations

Regards

Comment 21

[Jose Amador]

Attachment: WebTrust Seal 2009 (English)

Comment 22

[Jose Amador]

Attachment: Update response document V1

Comment 23

[Kathleen Wilson]

Thank you for the translations, information, and clarifications. 

> The OCSP certificate is signed by Root CA. 
> It´s the same root that signed the subca certificates.
> That is, OCSP responses are signed by a certificate signed by the root CA,
> which also signed the subordinate CA

I don't believe that's a problem.

I’ve imported the root certificate into my Firefox browser: http://www.pki.gva.es/gestcert/rootca.crt
I have enforced OCSP in my browser.
When I go to https://www.accv.es/ I get:
An error occurred during a connection to www.accv.es.
The signer of the OCSP response is not authorized to give status for this certificate.
(Error code: sec_error_ocsp_unauthorized_response)

Usually this error means that the CA hasn’t implemented the OCSP responder according to section 4.2.2.2 of http://tools.ietf.org/html/rfc2560. In particular the 3 rules at the bottom of page 10. Mozilla strictly enforces these three rules.

Please compare your OCSP implementation with those 3 rules from rfc2560, and test your OCSP service in a Firefox browser.
Enforce OCSP in Firefox:  Tools->Options…->Advanced->Encryption->Validation
Select the box for “When an OCSP server connection fails, treat the certificate as invalid”


> By the time a request arrives, ACCV verifies the identity of the applicant
> and the information provided (the company in which the user works and the
> domain requested by the user). All requests are digitally signed with
> qualified personal certificates. These qualified certificates require that
> the user is physically present in a registration point and proves his
> identity.

It’s clear that the identity of the certificate subscriber has been verified, since they must have a qualified personal certificate before they can apply for an SSL certificate.

What I’m not seeing is how it is verified that the certificate subscriber owns/controls the domain name that is to be included in the SSL certificate. This is a requirement as per section 7 of the Mozilla CA Certificate Policy. Information about this verification process must be included in a public-facing and audit document, such as the CP or CPS.

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Comment 24

[Kathleen Wilson]

The last paragraph should have had "audited document" rather than "audit document". e.g the information needs to be in a document that gets reviewed when the audit is performed.

Comment 25

[Jose Amador]

Hi

We changed the settings to resolve the error in the browser. Now the OCSP should respond well according to your criteria. Please try again and confirm.

About what you comment on the domain identification, our users are public institutions with which the ACCV has agreements. Before coming to the issuance of the certificate, the technicians and lawyers from the ACCV have reviewed the data for that institution, including the domain registration on accredited firms. These are the steps that are mentioned in the certification policy (although no detailed).

Comment 26

[Kathleen Wilson]

I can now load the website with OCSP enforced. Thanks.

In regards to domain name verification, this is a sticking point for Mozilla. 
There needs to be public-facing and audited documentation (such as in the certification policy) about steps that are taken to verify that the SSL certificate subscriber owns/controls the domain name to be included in the certificate. 
https://wiki.mozilla.or/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
Can you update the SSL CP to add more information about this?

Comment 27

[Jose Amador]

Hi

We have updated our policy and added the section 3.1.10 

"Checking the Request Domain
The ACCV will check that domains and addresses associated to the certificate actually belong to the applicant by looking up the records assigned by ICANN/IANA. This checking will be made by using WHOIS queries in the records authorized by the Red.es agency at http://www.nic.es or its equivalent for national domains or those provided by VeriSign for the generic domains (whois.verisign-grs.com).
Besides WHOIS query, DNS response and connection tests using secure protocol (e.g. HTTPS) with the domain under consideration will be made when possible. In the light of any irregularity, the ACCV will contact the certificate applicant and leave the certificate issuance pending until correction. If this correction is not fixed within a month the request will be denied."

Regards

Comment 28

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 29

[Kathleen Wilson]

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

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

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

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

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

Comment 30

[JGaleano]

We're waiting for the request to go up in the queue but it seems to be completely stoped.
Is there any discussion or any thing we provide to make it go on?

Thanks in advance

Comment 31

[David E. Ross]

Re comment #30:

There are 17 requests in the queue ahead of this one.  To speed the process, knowledgeable individuals -- including individuals associated with other certificate authorities -- are requested to participate in the public reviews currently underway.

Comment 32

[David E. Ross]

Oops!  There are four requests, not 17, in the queue.  Plus, two requests are undergoing public review.

Comment 33

[Kathleen Wilson]

This request is near the top of the queue for public discussion, as such I am re-reviewing this information.

The audit url in my notes is from 2009:
https://cert.webtrust.org/SealFile?seal=943&file=pdf 

Please provide a link to the updated audit statement.

Comment 34

[Jose Amador]

We're just finishing the corresponding WebTrust audit. Once the seal is ready we will link to our website and upload the document.

Thanks

Comment 35

[Kathleen Wilson]

I'm going to proceed with starting the public discussion for this request, but approval will be contingent on the updated audit.

Comment 36

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 37

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Autoritat de Certificacio de la Comunidat Valenciana (ACCV) to add the “Root CA Generalitat Valenciana” root certificate and turn on all three trust bits.

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

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

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

Comment 38

[Kathleen Wilson]

As per Comment #36, I cannot recommend approval for this request until I have received and confirmed the authenticity of an updated audit statement. Please provide it as soon as possible.

The discussion of this request is now closed. The discussion resulted in two action items that will be tracked in this bug.

1) Add clarification to the CPS about the renewal process.
- Certificate renewal means that new keys and new certificate are issued, following policy in regards to validity period. The old cert is revoked.
- Renewal period begins 70 days before the expiration date. The CA sends email alerting users of pending expiration.

2) Update the SSL CP to clarify that SSL certs have the OCSP URI in the AIA.

Comment 39

[Jose Amador]

Hi

We are pleased to announce that we have successfully renewed the WebTrust Seal.You can find the seal here: https://cert.webtrust.org/ViewSeal?id=1142



Thanks in advance

Comment 40

[Kathleen Wilson]

Thanks for the update.  

What is the url of the Auditor's website?

When do you expect to complete the CP/CPS updates as per Comment #38?

Comment 41

[Jose Amador]

Hi

The URL is http://www.dnbcons.com 

The changes in policies are ready, pending the next update of the web. If you need published to recommend approval, I update it now (I thought it was a parallel work).


Regards

Comment 42

[Kathleen Wilson]

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

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

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

To summarize, this assessment is for the request from Autoritat de Certificacio de la Comunidat Valenciana (ACCV) to add the “Root CA Generalitat Valenciana” root certificate and turn on all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by ACCV, 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]. ACCV appears to provide a service relevant to Mozilla users: It is operated by the government of the Valencia region of Spain. ACCV issues certificates for persons (with email), web sites and for signing code, in different policies, but with the same root. ACCV is a public certificate service provider and the intended use for this root certificate is to improve the electronic administration between citizens and the administration.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP for each certificate usage and the CPS. An English translation of the CPS was provided, and translations of part of the CP documents have also been provided.

CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=426960
CPS (Spanish): http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V2.1.pdf

All CP Documents listed by certificate usage: 
http://www.accv.es/quienes-somos/practicas-y-politicas-de-certificacion/politicas-de-certificacion/
SSL CP:
http://www.accv.es/fileadmin/Archivos/Politicas_pdf/PKIGVA-CP-03V2.0-c2010.pdf
Code Signing CP: 
http://www.accv.es/fileadmin/Archivos/Politicas_pdf/nuevo_23_07_08/PKIGVA-CP-04V2.0-c.pdf
Qualified Certs CP for Public Employees: 
http://www.accv.es/fileadmin/Archivos/Politicas_de_certificacion/ACCV-CP-13V2.0-c.pdf
Qualified Certs CP for Citizens: 
http://www.accv.es/fileadmin/Archivos/politicas_certificacion/ACCV-CP-07V4.0-c.pdf

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

* Email: According to section 3.2.2 and 3.2.3 of the Qualified Certs CP for Public Employees and the Qualified Certs CP for Citizens the email addresses that may be included in certificates are generated by the administration, and not the end user. Civil servants certificates are issued from the official lists supplied by the public administration concerned. These official lists are drawn from selective processes with maximum guarantees (determine who is a civil servant) and involve a process in person at the registration point of administration. Public administration provides its employees with email accounts for his work as a civil servant. These email accounts are corporate and internally generated. The ACCV accepts these mail accounts because they are imposed by the administration and not by the user.

* SSL: According to section 3.1.10 of the SSL CP, ACCV checks that domains and addresses associated to the certificate actually belong to the applicant by looking up the records assigned by ICANN/IANA. This checking will be made by using WHOIS queries in the records authorized by the Red.es agency at http://www.nic.es or its equivalent for national domains or those provided by VeriSign for the generic domains (whois.verisign-grs.com). Besides WHOIS query, DNS response and connection tests using secure protocol (e.g. HTTPS) with the domain under consideration will be made when possible. 

* Code: According to Section 3.1.9 of the Code Signing CP and the SSL CP the subscriber must have a qualified personal certificate before applying for a Code Signing or SSL certificate. All requests for Code Signing and SSL certs are digitally signed with qualified personal certificates. These qualified certificates require that the user is physically present in a registration point and proves his identity. Therefore, by the time a request for a Code Signing or SSL cert arrives, ACCV has already verified the identity of the applicant and the company in which the user works.

* EV Policy OID: Not applicable. Not requesting EV treatment.

Section 15 [Certificate Hierarchy]
* This root has four internally-operated subordinate CAs which sign end-entity certificates for individuals and organizations. The sub-CAs are:
** CAGVA - Issued end entity certificates; personal certificates, code signing certificates and SSL certificates. This CA no longer issues certificates (CRL signing only).
** ACCV-CA1 - Issues end entity certificates. Mainly company certificates.
** ACCV-CA2 - Replaces CAGVA. Issues end entity certificates; personal certificates, code signing certificates and SSL certificates. ACCV checks the data from end entities exhaustively (vital statistics and data domain).
** ACCV-CA3 - Issues Windows logon certificates and DC certificates for internal domains.

Other: 

* CRL: 
** http://www.pki.gva.es/gestcert/rootgva_der.crl
** http://www.accv.es/gestcert/accv_ca2.crl (NextUpdate 2 days)
** CPS section 4.9.9. ACCV shall publish a new CRL in its repository at maximum intervals of 3 hours, even if there have been no modifications to the CRL (changes to the status of certificates) during the aforementioned period.

* OCSP: http://ocsp.pki.gva.es/

* Delegation of Domain / Email validation to third parties 
** CPS section 1.3.2:  Bodies of the Autonomous Government of Valencia as well as other entities can be Registration Authorities provided that the corresponding collaboration agreement has been entered into. These Registration Authorities are referred to as User Registration Points or PRUs in the documentation relating to the Certification Authority of the Community of Valencia, and they are entrusted with confirmation of the requester’s identity and delivery of the certificate.
** Obligations of the Registration Authority are defined in CPS section 9.6.2.
** CPS section 5.2.1.7: Auditor… must verify all aspects mentioned in the security policy, copies policies, certification practices, Certification Policies, etc. in the group of ACCV systems and within the ACCV personnel, as well as in the PRUs.

Section 9-11 [Audit]. 
The operations of the ACCV Root and its intermediate certificates are audited annually according to the WebTrust CA criteria. The most recent audit was completed in March, 2011, by DNB (http://www.dnbcons.com/). The audit statement is posted on the cert.webtrust.org website: 
https://cert.webtrust.org/SealFile?seal=1142&file=pdf

Based on this assessment I intend to approve this request from ACCV to add the “Root CA Generalitat Valenciana” root certificate and turn on all three trust bits.

Comment 43

[Kathleen Wilson]

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

** Root CA Generalitat Valenciana (websites, email, code signing)

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

Comment 44

[Kathleen Wilson]

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