521439 - Add renewed Firmaprofesional root CA cert

Status: RESOLVED FIXED

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

Description

[Chema López]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091006 Ubuntu/9.04 (jaunty) Shiretoko/3.5.4pre
Build Identifier: 

Root CA certificate:
http://crl.firmaprofesional.com/carootnew.crt

ARL:
http://crl.firmaprofesional.com/fproot.crl

CPS/CPs (unfortunately in Spanish, only) They have not changed much since the last accepted version. We have only included data from the new CAs.
http://www.firmaprofesional.com/index.php?option=com_content&view=article&id=62&Itemid=75

WebTrust seal
https://cert.webtrust.org/ViewSeal?id=946

Reproducible: Always

Comment 1

[Kathleen Wilson]

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

Please remove the Restricted Group Visibility and Role Visibility in this bug.  Those restrictions will cause problems when we get to the public discussion phase.

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified for this request. The items highlighted in yellow indicate where
further information or clarification is needed. Please review the full document
for accuracy and completeness.

Comment 3

[Samuel Sidler (old account; do not CC)]

Kathleen: Is there a reason this bug is private?

Comment 4

[Kathleen Wilson]

No. It should have regular access settings. Nothing private or confidential should be posted in CA Inclusion bugs.

Comment 5

[Chema López]

Attachment: Answers to open issues up to date

Please, fins in the PDF attached the answers.

Comment 6

[Chema López]

Attachment: Sub-CA cert to perform SSL cert chain tests.

Also find attached a sub-CA cert to perform SSL cert chain tests

Comment 7

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

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

Comment 9

[Kathleen Wilson]

I am re-reviewing this request in preparation for the upcoming public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

I noticed a few things that are usually sticking points in the public discussion phase, so it would be best if they can be addressed before I start the discussion.

1) Registration Authorities
Firmaprofesional has a large number of RA's, so this will be of concern. Primarily, documentation such as the CPS needs to state what controls are placed on RA's, and how is it ensured that RA's are processing certificate requests according to documented procedures.

2) Domain name ownership/control
Please see https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
There needs to be public-facing and audited documentation (such as in the SSL CP) about steps that the RAs are required to take to verify that the SSL certificate subscriber owns/controls the domain name to be included in the certificate.
Based on your prior responses, whois is used. Information about how RAs must use whois needs to be provided in a public-facing and audited document. And there needs to be clear controls on the RAs to ensure that they follow those procedures.

3) Email address verification
Please see https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
There needs to be public-facing and audited documentation (such as in the CP or CPS) about steps that the RAs are required to take to verify that the certificate subscriber owns/controls the email address to be included in the certificate.
If it is the case that the data can only be from the company's or professional association's database, then that should be in a public-facing and audited document. 

4) Identity of applicant
Both the SSL CP and the Code Signing CP state that the RA will verify the applicant's identity, its relationship with the entity, its existence and data to include in the certificate. More information will need to be provided in the CP or CPS to state what sorts of steps the RAs must take to do this verification.

Comment 10

[Chema López]

(In reply to comment #9)
> I am re-reviewing this request in preparation for the upcoming public
> discussion:
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
> https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
> 
> I noticed a few things that are usually sticking points in the public
> discussion phase, so it would be best if they can be addressed before I start
> the discussion.
> 
> 1) Registration Authorities
> Firmaprofesional has a large number of RA's, so this will be of concern.
> Primarily, documentation such as the CPS needs to state what controls are
> placed on RA's, and how is it ensured that RA's are processing certificate
> requests according to documented procedures.

In section 8.4.1 of CPS we state that RAs have to pass a yearly-based audit perform by a third, independent party. The scope of that audit reaches from procedural issues since logical security points. I copy a summary of what the audit checks:
- Audit goal is to ensure that the operations RAS perform meet:
  + Legal requirements (Spanish Law 59/2003 of December 19, on electronic signature)
  + Operational requirements stablished in the Certification Practice Statement  (CPS) of Firmaprofesional
  + Recommendations of regulatory bodies (ETSI 101 456. Policy Requirements for Certification Authorities Issuing qualified certificates)
- Audit scope. The elements to be evaluated can be classified into the following areas:
  + Procedures (PRO): to assess whether the staff has the necessary training to perform the RA Operator and performs operations in accordance with procedures established by Firmaprofesional.
    > Theorical skils throught RA Operator tests.
    > Practical skills throught RA Operator test operations with registration application
    > Documetation throught a sample of documentation gathered for a random certificate. Is the documentation complete?
    > ...
  + Logical Security (SEL): to assess  the correct configuration of the computers from which RA operators access registration application.
    > SO version and patches
    > Antivirus version, patches and updating policy as well as level of
    > Password quality, automatic log-out, screensaver,...
    > ...
  + Physical Security (SEF): to assess archiving and custody of registration documentation and RA Operator's authentication devices that performs the RA and operators of registration.
    > Documentation archiving: facilities, security levels,...
    > RA Operator authentication device: device management, PIN management, ...
    > ...

Additionally I would like to clarify that our RAs are not allowed to issue certificates to anybody. They only can issue certificates to end-entities closely related with the RA. Most of our RAs are professional association and they only can issue certificates to its members.


> 
> 2) Domain name ownership/control
> Please see
> https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
> There needs to be public-facing and audited documentation (such as in the SSL
> CP) about steps that the RAs are required to take to verify that the SSL
> certificate subscriber owns/controls the domain name to be included in the
> certificate.
> Based on your prior responses, whois is used. Information about how RAs must
> use whois needs to be provided in a public-facing and audited document. And
> there needs to be clear controls on the RAs to ensure that they follow those
> procedures.

Regarding this issues, I do not find where it is stated that the CA needs to be public-facing and audited documentation (such as in the SSL CP) about steps that the RAs are required to take to verify that the SSL certificate subscriber owns/controls the domain name to be included in the certificate. In section 7 of Mozilla CA Certificate Policy (Version 1.2) states that "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;" but no mention the need to have public-facing and audited documentation. 

Additionally, in the same document, section 8 states that "We (Mozilla) consider the criteria for CA operations published in any of the following documents to be acceptable" and we have a WebTrust seal from 2.003 and renrewd last year, so I understand that our operations meet Mozilla requirements.

Also, as the CP and later clarifiations say, we perform this organizational controls. The follwing documentatin is needed, or checked.
- The authorization of the applicant organization to the individual making the request for issuing the certificate.
- The identity of the individual.
- The ownership of the domain name, certified by a legal representative of the organization.
- Accreditation by a reliable means of existence of the entity under Right.

From my point of view is more reliable a ownership claim, certified (signed by a legal representative of the organization than a consultation of WHOIS.

Finally,  to clarify that the sole and only RA that can issue SSL (and Code-signing) certificates it is Firmaprofesional itself and no other RA.

> 
> 3) Email address verification
> Please see
> https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
> There needs to be public-facing and audited documentation (such as in the CP or
> CPS) about steps that the RAs are required to take to verify that the
> certificate subscriber owns/controls the email address to be included in the
> certificate.
> If it is the case that the data can only be from the company's or professional
> association's database, then that should be in a public-facing and audited
> document. 

Again, I disagree about the need to have public-facing and audited documentation. I refer again to as provided in section 8 of Mozilla CA Certificate Policy (Version 1.2) and the clarifications made on october, the 21th, 2.009.

> 
> 4) Identity of applicant
> Both the SSL CP and the Code Signing CP state that the RA will verify the
> applicant's identity, its relationship with the entity, its existence and data
> to include in the certificate. More information will need to be provided in the
> CP or CPS to state what sorts of steps the RAs must take to do this
> verification.

How to verify the identify of a natural person:
- CPS, 3.2.3 Authentication of the identity of an individual. The RA reliably will verifiy the identity of the subscriber. To do this, the subscriber shall attend and present the national identity card, residence card, passport or other means recognized in law that identifies him/her.

How to verify entity existence:
- CP legal person (1.3.6.1.4.1.13177.10.1.5.x), 4.1 Process ISSUANCE OF CERTIFICATES, a) Request. Providing either:
  + Charter (Constitutional deeds) of the entity, stating the appointment of legal representative (original and copy) accompanied by a simple informative Note Register issued during the ten days prior to the filing date and a manifestation of the legal representative responsible for confirming the validity of the charge, or 
  + Certificate of the Trade Registry on the constitution, legal personality organization, appointment and term of office of the legal representative issued during the 10 days prior to the filing date Firmaprofesional.

How to verify the relatioship with the entity:
- CP individual related to a company or entity (1.3.6.1.4.1.13177.10.1.2.x). 4.1   Process ISSUANCE OF CERTIFICATES, a) Request. RA must:
  + Identify the legal representative of the organization
  + Verify his/her powers of representation (following the procedure described above)
  + Obtain an authorization signed by the legal representative of the organization with data on persons authorized to obtain a certificate of individual related to a company
  + Data of this authorization must include: Name, ID and Position in the organization from each person

  The certificate request must be made by the applicant, meeting described in the CPS and the following:
  + The applicant shall be authorized to request the certificate from the legal representative of his/her organization.
  + The applicant must submit the required documentation to the RA to process the application.

Firmaprofesional has one of the more estrict registration procedure. There is no on-line unattended registration process and attendance in the RA is mandatory.

Comment 11

[Kathleen Wilson]

Thank you for the clarifications. I have a few items to follow up on…

> Documentation of steps taken to verify domain name ownership/control

We rely on public documentation and audits of those documented processes to ascertain that “the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate…”

> From my point of view is more reliable a ownership claim, certified (signed by
> a legal representative of the organization than a consultation of WHOIS.

In my notes I have “we verify the identity of the requesting person and the binding between the organization and the domain. … In addition we also use whois services.”

Are my notes wrong? Do you not use whois?

> Documentation of steps taken to verify email address ownership/control

We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

My notes have: “There is not a explicit indication on that point, but the different policies are always bound to the membership to a company, professional association, and so. It is not the individual (the person whose personal data is going to be in the "subject field") who provides the data to be include in the certificate, but a legal representative. And this data is collected from de company's or professional association's database.”

This may be sufficient if the CP/CPS indicated this restriction. But currently I’m not able to find information in the CP/CSP about how it is confirmed that the certificate subscriber owns/controls the email address to be included in the certificate. Maybe I’m missing it?

There is the option to proceed with the root inclusion request with only enabling the websites and code signing trust bits. E.g. don’t enable the email trust bit.

Comment 12

[Chema López]

(In reply to comment #11)
> Thank you for the clarifications. I have a few items to follow up on…
> 
> > Documentation of steps taken to verify domain name ownership/control
> 
> We rely on public documentation and audits of those documented processes to
> ascertain that “the CA takes reasonable measures to verify that the entity
> submitting the certificate signing request has registered the domain(s)
> referenced in the certificate…”
> 
> > From my point of view is more reliable a ownership claim, certified (signed by
> > a legal representative of the organization than a consultation of WHOIS.
> 
> In my notes I have “we verify the identity of the requesting person and the
> binding between the organization and the domain. … In addition we also use
> whois services.”
> 
> Are my notes wrong? Do you not use whois?

Your notes are okey, but this information is not public-facing. See below the measure we plan to do.
> 
> > Documentation of steps taken to verify email address ownership/control
> 
> We rely on public documentation and audits of those documented processes to
> ascertain that the requirements of section 7 of the Mozilla CA Certificate
> Policy are met.
> 
> My notes have: “There is not a explicit indication on that point, but the
> different policies are always bound to the membership to a company,
> professional association, and so. It is not the individual (the person whose
> personal data is going to be in the "subject field") who provides the data to
> be include in the certificate, but a legal representative. And this data is
> collected from de company's or professional association's database.”
> 
> This may be sufficient if the CP/CPS indicated this restriction. But currently
> I’m not able to find information in the CP/CSP about how it is confirmed that
> the certificate subscriber owns/controls the email address to be included in
> the certificate. Maybe I’m missing it?
> 
> There is the option to proceed with the root inclusion request with only
> enabling the websites and code signing trust bits. E.g. don’t enable the email
> trust bit.

Measures to be taken
--------------------

We plan to release a new version of the CPS at the end of July, adding the following:

Validations:

- Domain Control. To ensure that a requesting entity has control over the domain (URL) that claims to include in a certificate, we use two types of checks:
  + Organizational: requesting ownership of the domain name, certified by a legal representative of the organization.
  + Technical: The following authenticated whois services are queried:
    > For domains *.es: https://www.nic.es/sgnd/domain/publicInformacionDominios.action
    > For all other domains: https://www.networksolutions.com/whois/index.jsp

- Email control.
  + In general, the signatories are people associated with the Registration Authority (eg, collegiates, members of associations, etc.) In such cases it is not the signatory who requests a specific email address to be included in the certificate but that RA itself is that, by consulting its database, gets the address.
  + In cases where the signer has no link to the RA, the control of the e-mail is validated by a challenge/response to the requested address.

Comment 13

[Kathleen Wilson]

When the updated CPS is ready, please post a comment in this bug with a link to it.

While considering the updates to your CPS, I recommend that you review recent root inclusion discussions at mozilla.dev.security.policy. 

Please also see:

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

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

https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties

Comment 14

[Chema López]

(In reply to comment #13)
At last, CPS has been released.

You can find it at http://www.firmaprofesional.com/cps/FP_CPS_5.pdf

Please, refer to sections 3.2.5 Validación del dominio (Domain validation) and 3.2.6 Validación del correo electrónico (e-mail validation) to see the commented changes.


> When the updated CPS is ready, please post a comment in this bug with a link to
> it.
> 
> While considering the updates to your CPS, I recommend that you review recent
> root inclusion discussions at mozilla.dev.security.policy. 
> 
> Please also see:
> 
> https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
> 
> https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
> 
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties

Comment 15

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updating the Information Gathering Document according to the updated CPS.

I'll post a comment in this bug when I start the discussion.
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 16

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Firmaprofesional to add the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate.

For a description of the public discussion phase, see 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Firmaprofesional Root Inclusion Request”

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

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

Comment 17

[Chema López]

Attachment: New proposed version for SSL CP...

Comment 18

[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 Firmaprofesional to add the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate, and to enable all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Firmaprofesional, 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]. Firmaprofesional appears to provide a service relevant to Mozilla users: It is a commercial CA in Spain that issues certificates to professional corporations, companies and other institutions.  

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CPS, SSL CP, and Code Signing CP, which are in Spanish. 

CPS: http://www.firmaprofesional.com/cps/FP_CPS_5.pdf
SSL CP: https://bugzilla.mozilla.org/attachment.cgi?id=477539
Code Signing CP: http://www.firmaprofesional.com/cps/FP_CP_FirmaCodigo_4.pdf

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

* Email: Firmaprofesional RAs use a challenge/response mechanism to verify that the certificate subscriber has control of the email address to be included in the certificate when it is not the RA requesting the certificate. Alternatively, the organization acting as the RA may request a certificate on behalf of an individual and provide the individual’s email address from their organization’s database, where the email address is in the organization’s domain and controlled by the organization.  (CPS section 3.2.6)

* SSL: Firmaprofesional does not delegate issuance of SSL certificates to third parties. According to CPS Section 3.2.5, Firmaprofesional verifies the organization requesting the certificate. According to SSL CP section 4.1.a, Firmaprofesional performs a whois query to confirm that the certificate subscriber owns the domain name to be included in the certificate.

* Code: According to SSL CP section 4.1, Firmaprofesional verifies the existence and identity of the organization, and the identity and authority of the certificate subscriber to request the certificate on behalf of the organization. 

* EV Policy OID: Firmaprofesional is not requesting EV-enablement at this time.

Section 13 [Certificate Hierarchy]. 
* This is a renewal for the Firmaprofesional root certificate that is currently in NSS, which was evaluated for inclusion in bug #342426. Sub-CAs of the new root cross-sign end-entity certs with sub-CAs of the old root, in order to maintain business continuity. 
* This root CA signs subordinate CAs that sign end-entity certificates. One sub-CA is used by Firmaprofesional, and other sub-CAs are issued for organizations including professional corporations, companies or other institutions, which act as Registration Authorities.
* All of the Sub-CAs are internally operated by Firmaprofesional.

Other: 
* Firmaprofesional issues CRLs with NextUpdate 7 days for end-entity certs.
* OCSP is provided.

* Professional corporations, companies or other institutions, may act as Registration Authorities to issue individual certificates that may be used for S/MIME. According to CPS section 8.4.1, RAs are required to pass a yearly-based audit that is performed by an independent third party. The audit goal is to ensure that the operations RAs perform meet:
** Legal requirements (Spanish Law 59/2003 of December 19, on electronic signature).
** Operational requirements established in Firmaprofesional’s CPS.
** Recommendations of regulatory bodies (ETSI 101 456. Policy Requirements for Certification Authorities Issuing qualified certificates).

Section 8-10 [Audit]. 
Firmaprofesional is audited annually by Ernst & Young according to the WebTrust CA criteria, and the audit statement is posted on the webtrust.org website: 
https://cert.webtrust.org/ViewSeal?id=946

Based on this assessment I intend to approve this request to add the “Autoridad de Certificacion Firmaprofesional CIF A62634068” root certificate, and to enable all three trust bits.

The following action item will also be tracked in this bug.

ACTION Firmaprofesional: Publish the updated SSL CP on the Firmaprofesional website, and post an update in this bug when completed.

Comment 19

[Kathleen Wilson]

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

* “Autoridad de Certificacion Firmaprofesional CIF A62634068” (web sites, code signing, email)

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

Comment 20

[Kathleen Wilson]

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

Comment 21

[Kathleen Wilson]

Chema, Please update this bug when the following action item has been completed.

ACTION Firmaprofesional: Publish the updated SSL CP on the Firmaprofesional website.

Comment 22

[Chema López]

Thanks to you all.

Of course, Kathleen, as soon as the new policy is released I will update the ticket.

(In reply to comment #21)
> Chema, Please update this bug when the following action item has been
> completed.
> 
> ACTION Firmaprofesional: Publish the updated SSL CP on the Firmaprofesional
> website.

Comment 23

[Chema López]

Attachment: New approved and published SSL policy

This is the new published SSL policy available at http://www.firmaprofesional.com/cps/FP_CP_Gen_Servidor_Seguro_5.1.pdf

Comment 24

[Kathleen Wilson]

Chema, Thank you for the update.

All, I have confirmed that the requested changes are in the new version of the SSL CP that is posted on Firmaprofesional's website. The specific changes were to section 4.1.a. An English translated excerpt follows:

"Request can only be managed by Firmaprofesional RA.

Subject to the provisions of the relevant Certification Practices
Statement (CPS) of Firmaprofesional, to ensure that a requesting
entity has control over the domain (URL) claiming to be included in a
certificate, Firmaprofesional RA uses two types of checks:
** Organizational: requesting ownership of the domain name, certified
by a legal representative of the organization.
** Technical: The following services are queried whois authenticated:
     o For domains “*.es”: 
https://www.nic.es/sgnd/dominio/publicInformacionDominios.action
     o For the rest of domains:
        -  A query to http://www.iana.org/domains/root/db/, to find out
who is the authoritative WHOIS service
        -  A query to the corresponding WHOIS service
"

Comment 25

[Kathleen Wilson]

Attachment: Qualified Audit Report Webtrust BR Firmaprofesional 2015-2016_en.pdf

Comment 26

[Kathleen Wilson]

Attachment: Qualified Audit Report Webtrust EV Firmaprofesional 2015-2016_en.pdf