Closed Bug 435736 Opened 16 years ago Closed 7 years ago

Add Spanish FNMT root certificate

Categories

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

task
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED FIXED
blocking-basecamp -

People

(Reporter: cristina.acedo, Assigned: kwilson)

References

Details

(Whiteboard: In NSS 3.28.1, Firefox 51)

Attachments

(18 files, 10 obsolete files)

35.50 KB, application/msword
Details
99.00 KB, application/msword
Details
259.38 KB, image/jpeg
Details
36.86 KB, application/pdf
Details
765 bytes, application/x-x509-ca-cert
Details
487.20 KB, application/pdf
Details
126.74 KB, application/pdf
Details
80.84 KB, application/pdf
Details
3.09 MB, application/force-download
Details
631.33 KB, application/force-download
Details
22.30 KB, application/force-download
Details
925.94 KB, application/pdf
Details
149.99 KB, application/pdf
Details
147.53 KB, application/x-unknown
Details
162.81 KB, application/pdf
Details
158.09 KB, application/pdf
Details
1.25 MB, application/pdf
Details
472.71 KB, application/pdf
Details
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: Firefox 2.0.0.14

CA Details
----------

CA Name:     [ FNMT CLASE 2 CA ]

Website URL: [ http:// www.cert.fnmt.es ]

CA Summary: 
  [ A one Paragraph Summary of your CA, including the following:  Public Certification Authority (issues certificates to the general public).     ]
  [ - General nature (e.g., commercial, government academic/research, nonprofit)  Fábrica Nacional de Moneda y Timbre (FNMT) provides services to  Spanishand established legaly on the territory citizens.  Sector government. ]
  [ - Primary geographical area(s) served  Geographical area: SPAIN  ]
  [ - Number and type of subordinate CAs      NO Subordinate CAs       ]

Audit Type (WebTrust, ETSI etc.):  [    ETSI 101 456        ]

Auditor:  [      BSI Management Systems B.V   ]

Auditor Website URL: [http:// www.bsi-global.com  ]

Audit Document URL(s): 
  [http://www.cert.fnmt.es/content/pages_std/docs/ETSI.pdf   ]



URL of certificate hierarchy diagram (if available):
  [http://                                                         ]

Certificate Details
-------------------
(To be completed once for each root certificate; note that we only 
 include root certificates in the store, not intermediates.)
  
Certificate Name:  [OU=FNMT CLASE 2 CA, O=FNMT, C=ES    ]

Summary Paragraph:
  [ including the following:   ]
  [ - End entity certificate issuance policy,  
FNMT-RCM issues certificates to natural persons according to his Qualified Certificates Certification Policy (1.3.6.1.4.1.5734.3.5). This certificates bind a public key to a natural person, proving his identity.  These certificates are issuing as Qualified Certificates based on Spanish Electronic Signature Law (59/2003) rules and  ETSI TS 101 456 - “Policy requirements for certification authorities issuing qualified certificates” recommendations. 

Certificates Profiles issued under to this FNMT-RCM Qualified Certificate Policy are issued according to ETSI TS 101 862 – “Qualified Certificate Profile”.  ]
  [   i.e. what you plan to do with the root                       ]

Root certificate download URL (on CA website):
  [http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer]
  [alternatively, paste a copy of the certificate in "PEM" format  ]

Version: [X509 v3]

Certificate SHA1 Fingerprint (in hexadecimal):
  [43 F9 81 10 D5 8A FD 48 22 52 31 80 DO 08 28 37 2F EF 9A 54]

MD5 Fingerprint: [  25:9D:CF:5E:B3:25:9D:95:B9:3F:00:86:5F:47:94:3D]

Key size (for RSA, modulus length) in bits: [1024  ]

Serial number : [36:F1:1B:19]

Valid From (YYYY-MM-DD): [ 1999-03-18  ]
Valid To (YYYY-MM-DD):   [   2019-03-18   ]

CRL HTTP URL (if any):
  [ldap://ldap.cert.fnmt.es .  Simple Authentication Services. Authorization required]

CRL issuing frequency for subordinate CA certificates: [      days ]
CRL issuing frequency for subordinate EE certificates: [      days ]

OCSP responder URL (if any):
  [http://apus.cert.fnmt.es/appsUsuario/ocsp/OcspResponder    Signed request. Authorization required  ]

Class: [Identity validated and domain validated]

Certificate Policy URL:
 [ http://www.cert.fnmt.es/content/pages_std/docs/dpc.pdf]

CPS URL:
  [http://www.cert.fnmt.es/content/pages_std/docs/dpc.pdf]

Requested Trust Indicators: [Email, SSL, Code]

URL of a sample website using a certificate chained to this root 
(if applying for SSL):
  [https://www.cert.fnmt.es]


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
adjusting product and component
Assignee: nobody → hecker
Component: General → CA Certificates
OS: Windows XP → All
Product: Firefox → mozilla.org
QA Contact: general → ca-certificates
Hardware: PC → All
Version: unspecified → other
Attached file CA Details.doc
Cert Details
Accepting bug. It will go into the queue with all the other requests, so we will not be processing it immediately.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
So, it won't be prepared for final release of Firefox 3, isn't it?
(In reply to comment #5)
> So, it won't be prepared for final release of Firefox 3, isn't it?

No. At this point Firefox 3.0 is almost ready to ship. (It will be officially released next Tuesday, June 17.) Our goal is to get more CAs approved for inclusion in future security update releases to Firefox 3.0, e.g., Firefox 3.0.1, 3.0.2, and so on.

Severity: normal → enhancement
Frank, is there a way to nominate this (or should it) for 3.0.x and 3.1? The certificate is necessary for some types of transactions, like buying train tickets, and having that option would help in Firefox adoption in Spain.
I support Juan, this and bug 295474 put Firefox in a competitive disadvantage in Spain compared to Internet Explorer:
http://support.microsoft.com/?scid=kb%3Ben-us%3B931125&x=16&y=15
It's also needed to pay taxes, to manage the driver license...
Accepting this bug, so I can do the information gathering/verification phase.

Kathleen
Assignee: hecker → kathleen95014
Attached is the initial information gathering document, which summarizes the data that has been gathered and verified.  Within the document I have highlighted in yellow the information that is still needed.  I will summarize below.

1) This root is only 1024 bit. NIST recommend that all such roots be phased out by the end of 2010, yet this root expires in 2019. What is your current end-of-life plan with regard to this root? Is there a new root we should be reviewing for inclusion in Mozilla?

2) Is there a CRL for the end-entity certificates that is accessible via an external URL?
There is usually a statement in the CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 48 hours. If you have such a statement in your CP/CPS, would you please provide it in English?

3) Please confirm:
a) There are no subordinate CA’s issued by this root.
b) This root CA directly issues end entity certificates.  End-entity certificates are signed using the private key of this root.

4) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ please translate the relevant text from the latest CP or CPS into English that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates:
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;

5) Please identify if all SSL certs issued from this root are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber.
Are there any SSL certs issued from this root that are only DV? Eg the Organization attribute is not verified, only the domain name is verified?

6) I’m supposed to review the CP/CPS for potentially problematic practices,
as per http://wiki.mozilla.org/CA:Problematic_Practices. Would you please comment as to whether any of these are relevant?
If relevant, please provide further info.

7) Do you have an updated audit report?

Thanks,
Kathleen
 The answer of The FNMT about your questions are:

-- Comment #11 from Kathleen Wilson <kathleen95014@yahoo.com>  2008-10-02 12:22:49 PDT ---
Created an attachment (id=341484)
 --> (https://bugzilla.mozilla.org/attachment.cgi?id=341484)
Initial Information Gathering Document

Attached is the initial information gathering document, which summarizes the data that has been gathered and verified.  Within the document I have highlighted in yellow the information that is still needed.  I will summarizebelow.


1) This root is only 1024 bit. NIST recommend that all such roots be phased out by the end of 2010, yet this root expires in 2019. What is your current end-of-life plan with regard to this root? Is there a new root we should be reviewing for inclusion in Mozilla?

“We are planning to create a new Root CA for FNMT-RCM in 2009. Then we will send to Mozilla a formal request to include this certificate in Mozilla CA Certificate program”.

2) Is there a CRL for the end-entity certificates that is accessible via an external URL? There is usually a statement in the CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 48 hours. If you have such a statement in your CP/CPS, would you please provide it in English?

“YES. There are Certificate Revocation Lists (CRLs) for end-entity certificates published in a LDAP Directoy. The LDAP URL is: ldap.cert.fnmt.es. This is a simple authenticated service. In every end-entity certificate signed by our root CA there is a CRL Distribution Point pointing to the correct CRL. These CRLs are updated every 24 hours as well as every time a certificate is revoked”.



3) Please confirm:

a) There are no subordinate CA’s issued by this root. “Confirmed”. 

b) This root CA directly issues end entity certificates.  End-entity
certificates are signed using the private key of this root. “Confirmed”.

4) As per section 7 of  http://www.mozilla.org/projects/security/certs/policy/
please translate the relevant text from the latest CP or CPS into English that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates:

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;


“In paragraph V.2 of FNMT-RCM’s Certification Practices Statement, Life cycle management of the certificates of components (we call Certificate of Components to SSL-enabled certificates, Code signing certificate and certificates issued for applications that needs authentication each other) are shown the necessary steps for obtaining an SSL Server Certificate. The first one is:

The entity interested in applying for a SSL Certificate, must maintain a previous contact with the Royal Spanish Mint (FNMT-RCM) in order to be provided with the information necessary for the issuance of the certificate requested, as well as the forms to be filled. The necessary documents are:

• Request Form for SSL Certificate fully completed and signed by the person in charge of Certificate. 
• Authorization Form for SSL Certificate request for information as a person in charge for it. 
• Photocopy of National Identity Document, or National Identity Card for Foreigners, with the original valid and in force, from the Responsible of the SSL Certificate. 
• A document proving the ownership of the domain name or IP address or in case of SSL Certificate for intranets services, internal document proving the intranet name. 
• Writing Constitution or the Official State Gazette publication for proving the entity legal person, whether private or public. 
• Certificate Request File in PKCS#10 or SPKAC (Signed Public Key And Challenge) format. 


Upon receipt of this documentation, the Royal Spanish Mint checks the accuracy and authenticity of all data provided and then process the request.

As you can see, we make strong verifications of information sent by entities”.


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; 

“The main purpose of certificates issued by FNMT-RCM Certification Authority is user identity authentication nor digitally sign and/or encryption email messages.  The email is only used as contact method to send information to users”.

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;

“It’s the same process of checking all data provided by entity  explained in section 4.a.”

5) Please identify if all SSL certs issued from this root are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber.
Are there any SSL certs issued from this root that are only DV? Eg the
Organization attribute is not verified, only the domain name is verified?

“FNMT-RCM Certification Authority doesn´t issue SSL Certificates with an organization attribute for every entity that request certificates but in the general process of checking documentation authenticity we check that entity legal person is correct as explained in section 4.a.”

 
6) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Would you please comment as to whether any of these are relevant?
If relevant, please provide further info.

We comment every item of problematic practices document separately:

Long-lived DV certificates: “DV certificates issued by FNMT-RCM CA has four year of validity period. Do you mind that four years is very large? In any case, we only issue DV certificates to very contrasted legal entities (public or private)”.

Wildcard DV SSL certificates: “FNMT-RCM CA CPS claims that FNMT CA doesn´t issue wildcard certificates”. 

Issuing end entity certificates directly from roots: “Yes. In our current deployment the end entity certificates are issued directly by our root CA. In the new deployment planned for 2009 the end entity certificates will be issued by a subordinate CA. Root CA which will be offline”.



Allowing external entities to operate unconstrained subordinate CAs: “Not in any case as FNMT-RCM CA CPS claims”. 



Distributing generated private keys in PKCS#12 files: “Not in any case as FNMT-RCM CA CPS claims”.


Certificates referencing hostnames or private IP addresses: “FNMT-RCM CA doesn´t issue certificates referencing hostnames or private IP addresses”. 



OCSP Responses signed by a certificate under a different root: “FNMT-RCM OCSP responses are signed by a certificate issued by the same CA that issues end entity certificates”.


CRL with critical CIDP Extension: “The CRLs issued by FNMT-RCM CA have the CRL Issuing Distribution Point extension flagged as critical as X509 recommends”.
 

7) Do you have an updated audit report?

“We were planning to have a new audit on ETSI TS 101 456 in the beginning of next year”.
Thank you for the information.

>“The main purpose of certificates issued by FNMT-RCM Certification Authority
> is user identity authentication nor digitally sign and/or encryption email
> messages.  The email is only used as contact method to send information to
>users”.
Then the requested trust bits should not include email (S/MIME). The requested trust bits should only be websites (SSL/TLS) and Code Signing. Do you agree?

In regards to the existing audit, I have submitted a request via the BSI website to verify the authenticity of the audit statement as per Mozilla policy. Once the old audit is verified, I think we can proceed with evaluation of this request.

The existing audit has expired, so an updated audit will probably be needed before final inclusion. 

>Long-Lived Domain-Validated SSL certs
>“DV certificates issued by FNMT-RCM CA has four year of validity period. Do
>you mind that four years is very large? In any case, we only issue DV
>certificates to very contrasted legal entities (public or private)”.
I am not sure what “contrasted legal entities” means. 
This is only a concern for SSL certs in which the identity or organization of the owner of the certificate has not been verified. If you issue 4-year certs in which only the domain name has been verified, then the certs are subject to the issue described in 
https://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates

>“The CRLs issued by FNMT-RCM CA have the CRL Issuing Distribution Point
>extension flagged as critical as X509 recommends.”
This is problematic because Firefox will return the error code ffffe095 when attempting to load a CRL with the critical CIDP. It is highly recommended that you don’t make this extension critical until this has been resolved in Firefox, which is still TBD.
(In reply to comment #13)
> In regards to the existing audit, I have submitted a request via the BSI
> website to verify the authenticity of the audit statement as per Mozilla
> policy. Once the old audit is verified, I think we can proceed with evaluation
> of this request.

Do we have an answer about this?


> This is problematic because Firefox will return the error code ffffe095 when
> attempting to load a CRL with the critical CIDP. It is highly recommended that
> you don’t make this extension critical until this has been resolved in Firefox,
> which is still TBD.

Is this issue solved now or for Fx 3.5?
Please, consider this bug affects at least es-ES, ca, and eu localizations of Firefox. What are we supposed to tell our users when a single response on bugs like this take months? Are we really taking care of the user experience?
Julen, please note that Kathleen has posted additional questions to this bug in comment 13. It is upon the CA to reply here.
I have been waiting for a response to my previous post. Since that was so long ago, I will summarize here what information I am looking for now.

1) The “FNMT Clase 2 CA” is 1024 bit. FNMT will create a replacement root in 2009. Has your new root been created and audited? If so, I recommend including that root in this request.

2) Can you provide a URL that can be used for downloading the CRL instead of ldap?
The information about CIDP has been updated, please see
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

3) This root directly issues end-entity certificates. If the new root has been created, is it offline, with sub-CAs?

4) “The main purpose of certificates issued by FNMT-RCM Certification Authority is user identity authentication nor digitally sign and/or encryption email messages.  The email is only used as contact method to send information to users”. 
Then the requested trust bits should not include email (S/MIME). The requested trust bits should only be websites (SSL/TLS) and Code Signing, not email. Do you agree?

5) I did not ever receive a reply from BSI in regards to the audit report.  However, it’ll be best to get and confirm the 2009 audit report instead.  My understanding was that the audit was planned for early this year.  Has it happened?

6) “DV certificates issued by FNMT-RCM CA has four year of validity period. Do you mind that four years is very large? In any case, we only issue DV certificates to very contrasted legal entities (public or private)”.
According to paragraph V.2 of the CPS, is it accurate to say that all SSL certificates are identity or organizationally verified? Or do you ever issue SSL certs where only the domain name had been verified, and the identity or organization is not verified?
Pinging FNMT staff, since you are the one to provide the requested data. Moreover, more public administration sites are going into production with a FNMT certificate, like the Madrid Public Health Service web site for medical apointments self-service:

https://www.citaprevia.sanidadmadrid.org/

Firefox users will have access denied to the page if FNMT is not trusted as it is now because of this bug not moving further, and both Mozilla and the FNMT will get bad press.

This bug has been opened for more than a year now, following another previous one, and the delays caused by both sides have been these to date:

Mozilla
-------

26/05/2008 (#5) --> 12/06/2008 (#6): 17 days
12/06/2008 (#6) --> 02/10/2008 (#10): 30 + 31 + 31 + 21 = 114 days

Mozilla total: 131 days


FNMT
----

02/10/2008 (#11) --> 01/12/2008 (#12): 31 + 29 = 60 days
02/12/2008 (#13) --> 12/03/2009 (#17): 31 + 31 + 28 + 10 = 100 days
12/03/2009 (#13) --> Today: 31 + 30 + 19 = 80 days

FNMT total: 240 days

Grand total: 371 days


Even if 131 days is proof that Mozilla needs reviewing his process to get CAs accepted, the 240 days delay by FNMT, 180 days without a single commment, is completely unacceptable.

We, as the Spanish Mozilla Community, must and will take every step at hand to make clear to Spanish users what is the reason why Firefox users can't access in a secure way to government sites using FNMT certificates.
Hello Kathleen 

Include the CA Root certificate for FNMT-RCM CA  Spanih  on next Mozilla update it easy.
Only thing is get certificate from http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
and include it on next update, for example 3.0.11
Can be it possible please ?
It would be pleasure for all Spanish Mozilla Community

Sorry for my bad english 
Best Regards
Luciano
Before a root can be added to Mozilla, the process described at
https://wiki.mozilla.org/CA:How_to_apply
must be completed.

This request is currently in the Information Gathering and Verification phase as described at
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

In order to proceed, an official representative of FNMT must respond to the items listed in Comment #17.

After the Information Gathering and Verification phase is completed, the request then has to go through the public discussion phase, which is described at https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Perhaps you can contact FNMT to encourage them to respond?
Luciano, please let's keep the discussion at the dev.crypto mailing list:

http://groups.google.es/group/mozilla.dev.tech.crypto/browse_thread/thread/da33d24030fe5e6f/9314b4ae9cbebb09

This way we will keep the bug clean just for comment about the process.

Kethleen, I've been personally in contact with Carolina from FNMT during the whole process to help them, but I haven't got any reply from her for too long (I tried several times), and I got the return receipt back, so I know they got my emails.

Since this is a BIG marketing issue in Spain, as Ricardo said before, we will inform from the community about the process and who should move next.
ping. Please now that the holidays season has finished, please move on this issue.
In order to proceed, an official representative of FNMT must respond to the
items listed in Comment #17.
Kathleen, I'm a representative of Spanish Mint (FNMT). I'll try to response the outstanding issues

(In reply to comment #17)
> I have been waiting for a response to my previous post. Since that was so long
> ago, I will summarize here what information I am looking for now.
> 
> 1) The “FNMT Clase 2 CA” is 1024 bit. FNMT will create a replacement root in
> 2009. Has your new root been created and audited? If so, I recommend including
> that root in this request.

We have created a new Root CA for FNMT-RCM. We're expect to get de ETSI 101 456 at 2009 november for this CAs. We agree to include new root in this request, but spanish users need also the “FNMT Clase 2 CA” because there are more than 2.200.000 certificates issued that will be active by several years.


> 2) Can you provide a URL that can be used for downloading the CRL instead of
> ldap?
> The information about CIDP has been updated, please see
> https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

No, we can't for FNMT Clase 2 CA at this moment.

> 3) This root directly issues end-entity certificates. If the new root has been
> created, is it offline, with sub-CAs?

Yes, the new root CA will be online and there will be subordinate CAs

 
> 4) “The main purpose of certificates issued by FNMT-RCM Certification Authority
> is user identity authentication nor digitally sign and/or encryption email
> messages.  The email is only used as contact method to send information to
> users”. 
> Then the requested trust bits should not include email (S/MIME). The requested
> trust bits should only be websites (SSL/TLS) and Code Signing, not email. Do
> you agree?

We're agree. Nevertheless, it would be interesting for future uses that trust bits include email.

> 
> 5) I did not ever receive a reply from BSI in regards to the audit report. 
> However, it’ll be best to get and confirm the 2009 audit report instead.  My
> understanding was that the audit was planned for early this year.  Has it
> happened?

We'd the audit on ETSI TS 101 456 at BSI Netherlands and we're renewing this audit report at this time.


> 6) “DV certificates issued by FNMT-RCM CA has four year of validity period. Do
> you mind that four years is very large? In any case, we only issue DV
> certificates to very contrasted legal entities (public or private)”.
> According to paragraph V.2 of the CPS, is it accurate to say that all SSL
> certificates are identity or organizationally verified? Or do you ever issue
> SSL certs where only the domain name had been verified, and the identity or
> organization is not verified?

We verify domain and the organization identity (at National Trade Registry)
Thank you for the information. 

Please also provide the following:
1) a url for downloading the new root
2) a website (can be a test site) whose SSL cert chains up to the new root
3) Attach the latest CPS to this bug report with copy-and-paste enabled (so I can copy-and-paste into Google Translate)

Is there new information in the CPS in regards to the new root?
Whiteboard: information incomplete
Hello Kathleen,

we provide the requested information.

URLs for downloading roots (both, current and new):
- http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
- http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt (new root)

Latest CPSs for current and new root (these pdfs are copy&paste enabled):
- http://www.cert.fnmt.es/dpc/dpc.pdf
- http://www.cert.fnmt.es/dpc/dgpc.pdf (includes information about new root)

We are working in a new test website whose SSL cert chains up to the new root. We'll inform you when it's ready

Best regards,

Rafa
I am still unable to use copy-paste (for translation purposes) of http://www.cert.fnmt.es/dpc/dpc.pdf
Does this document also cover the subscriber verification procedures for certs issued in the hierarchy of the new root?

I think that http://www.cert.fnmt.es/dpc/dgpc.pdf does not have the info I need -- I did not find subscriber verification procedures in it.

In regards to CRL/OCSP, have you tested your SSL certs (especially revocation) in the Firefox browser?  The reason I ask is that the test websites I have for the old root are:
https://www.cert.fnmt.es
https://www.citaprevia.sanidadmadrid.org/
Both SSL certs for these test websites have CRL Distribution Point of the form:
Not Critical
X.500 Name: CN = CRL2379
OU = FNMT Clase 2 CA
O = FNMT
C = ES
I do not believe that this form will work in the Firefox browser, and therefore the CRL would not get checked. 
Also, neither of the SSL certs for the test websites have the AIA extension set to point to the OCSP responder, so I don’t believe the Firefox browser would use OCSP to verify the cert.
Therefore, I believe that there would be no validation of the SSL cert within the Firefox browser. I may be wrong, so please test.
Please move this. We all Spaniards need these certificates.
(In reply to comment #28)
> Please move this. We all Spaniards need these certificates.

Note the whiteboard status at the top of the bug. "information incomplete."

Note Kathleen's last comment from November requesting information, confirmation on document content, and verification of testing.  NO RESPONSE FROM FNMT.

Please do not make such comments when it is FNMT which has not provided the information required/requested that all other CAs have.  Unless FNMT provides the required information in a timely manner, this bug will sit as is.
To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  As noted in comment #27, some required information is missing.  That information must be provided by the certificate authority before this request can enter the queue.  Thus, the problem lies in the hands of FNMT and not Mozilla.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.

Those who are anxious for these root certificates -- who already trust them, and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificates themselves.  The links are at <http://www.mozilla.org/projects/security/certs/pending/#FNMT>.

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there.
(In reply to comment #30)
> Those who are anxious for these root certificates -- who already trust them,
> and who have no patience with the Mozilla process for scrutinizing certificate
> authorities -- can download and install the root certificates themselves.  The
> links are at <http://www.mozilla.org/projects/security/certs/pending/#FNMT>.


Adding to this, at Mozilla Hispano we have a Flash demoing every step involved to add the certificate in Firefox:

http://www.mozilla-hispano.org/documentacion/Importar_un_certificado

To all Spanish users: please, don't add noise to this bug. Most of the delay in this process is due to FNMT (see comment #18), so distracting Mozilla staff from other tasks doesn't help at all. Instead, ping FNMT staff (in an educated manner, please!!) through their web contact form:

http://www.fnmt.es/index.php?spec=faq&page=9
Hello Kathleen,

I provide some additional information. I hope it will be useful for you.

In document "http://www.cert.fnmt.es/dpc/dpc.pdf" (FNMT Clase 2 CA Root) you can get the subscriber verification procedure at pages 173 - 174.

You can get this information in the specific CPS of a new subordinate CA of new root: http://www.cert.fnmt.es/dpc/ape/dpc.pdf (pages 55 - 69). This subordinate CA issues end-entity certificates for Official sites only.

You can test website whose SSL cert chains up to the new root in this real and Offcial sites:
- https://www.agenciatributaria.gob.es/
- https://sedemeh.gob.es/
- https://www.sede.fnmt.gob.es

I hope this will be sufficient to unlock this situation, because we have many complaints from users and Official entities.

Best regards








(In reply to comment #27)
> I am still unable to use copy-paste (for translation purposes) of
> http://www.cert.fnmt.es/dpc/dpc.pdf
> Does this document also cover the subscriber verification procedures for certs
> issued in the hierarchy of the new root?
> 
> I think that http://www.cert.fnmt.es/dpc/dgpc.pdf does not have the info I need
> -- I did not find subscriber verification procedures in it.
> 
> In regards to CRL/OCSP, have you tested your SSL certs (especially revocation)
> in the Firefox browser?  The reason I ask is that the test websites I have for
> the old root are:
> https://www.cert.fnmt.es
> https://www.citaprevia.sanidadmadrid.org/
> Both SSL certs for these test websites have CRL Distribution Point of the form:
> Not Critical
> X.500 Name: CN = CRL2379
> OU = FNMT Clase 2 CA
> O = FNMT
> C = ES
> I do not believe that this form will work in the Firefox browser, and therefore
> the CRL would not get checked. 
> Also, neither of the SSL certs for the test websites have the AIA extension set
> to point to the OCSP responder, so I don’t believe the Firefox browser would
> use OCSP to verify the cert.
> Therefore, I believe that there would be no validation of the SSL cert within
> the Firefox browser. I may be wrong, so please test.
> In document "http://www.cert.fnmt.es/dpc/dpc.pdf" (FNMT Clase 2 CA Root) 
> you can get the subscriber verification procedure at pages 173 - 174.

Perhaps, but I cannot actually read this because the document is not in English and it is locked for copying, so I cannot copy-and-paste the text into a translator.

> You can get this information in the specific CPS of a new subordinate CA 
> of new root: http://www.cert.fnmt.es/dpc/ape/dpc.pdf (pages 55 - 69). 
> This subordinate CA issues end-entity certificates for Official sites only.

So is this a new sub-CA of the "AC RAIZ FNMT-RCM" root? Is it internally or externally operated?

> You can test website whose SSL cert chains up to the new root in 
> this real and Offcial sites:
> - https://www.agenciatributaria.gob.es/
> - https://sedemeh.gob.es/
> - https://www.sede.fnmt.gob.es

I have imported both of the "FNMT Clase 2 CA" and the "AC RAIZ FNMT-RCM" roots into my Firefox browser, and I still cannot access these three websites.

Are you able to access these websites from within a Firefox browser?
(In reply to comment #33)
> > In document "http://www.cert.fnmt.es/dpc/dpc.pdf" (FNMT Clase 2 CA Root) 
> > you can get the subscriber verification procedure at pages 173 - 174.
> 
> Perhaps, but I cannot actually read this because the document is not in English
> and it is locked for copying, so I cannot copy-and-paste the text into a
> translator.


I have translated the V.2.1 section in that pages. Since I'm not an expert in certificate topics, I'm not sure if you need the following V.2.2 section. The translation may not be perfect, but I hope it will be better than an automatic translation service: ;-)

V.2. Component Certificates Life Cycle Management

V.2.1 Requesting a Component Certificate

Below it is described the requesting procedure by which personal data is gathered from a Requester (Solicitante) of a Component Certificate, his/her identity is verified, the domain ownership (if applicable) and the ability to make such request on behalf of the entity/organization for which the Component Certificate is issued and the agreement/contract formalized with FNMT-RCM in order to issue a Component Certificate once all verifications have taken place.

These activities will be performed directly by the Registry Area of FNMT-RCM.

To request these products the requester must be part first of the Electronic Community.

The DNI-e (Electronic National ID card, which includes an individual secure certificate itself) computing features will be taken into account for the process, as established by legislation.

Prior Contact

The entity/organization interested to get a Component Certificate must hold a prior meeting with FNMT-RCM, so it can get the needed information and forms to fill in order to get the requested Component Certificate.

Once all documentation has been gathered, FNMT-RCM will check the correctness of it, which must include in any case:

* Component Request Form fully completed and signed by the Representative in Charge of Component. This form can be viewed in the "Form Models" section.

* Form authorizing the request of an electronic component as representative in charge of it. This form can be viewed in the "Form Models" section.

* A photocopy of the National ID (or Spanish Resident Foreigner ID) valid and non-expired card of the Representative of the Component.

* A document certifying the property of the Domain Name or IP Address, or internal document certifying the Intranet.

* Legal constitution registration form (and copy of the creation and publication in a government journal, if applicable) of the Entity/Organization interested, whether it is a public or private one.

* PKCS#10 file of the Component Certificate Request.

* In the case of a component for Code Signing, for Advanced Client Services or a Generic Electronic Component, the PKCS#10 can be generated and inserted in the infraestructure of the FNMT-RCM following the same process that for the pre-request for Individual People Certificates. The Request Code generated during the pre-request proccess must be attached to the rest of documentation.

Processing the request and documentation by FNMT-RCM

FNMT-RCM, once both the request and accompanying documentation have been received, will process the petition using its internal software applications. It will generate, in a special paper for signed agreements/contracts, the paperwork that will be presented to the requester for he to sign it, and will sign itself the Component specific request, to later proccessing by FNMT-RCM.

Depending of the Component type specified in the petition, the procedure will generate:

* In the case of a web server: a download code after validating the registry. Such code will be printer to later downloading the PKCS#7 or Certificate.

* In the case of a Code Signing or a Electronic Component, after validating the registry a message will show confirming the petition. To download this Component Certificate, the request code provided by the solicitant will be used.


> > You can get this information in the specific CPS of a new subordinate CA 
> > of new root: http://www.cert.fnmt.es/dpc/ape/dpc.pdf (pages 55 - 69). 
> > This subordinate CA issues end-entity certificates for Official sites only.
> 
> So is this a new sub-CA of the "AC RAIZ FNMT-RCM" root? Is it internally or
> externally operated?
>


I'm afraid I can't answer to this, an FNMT representative will have to do it. :-(


> > You can test website whose SSL cert chains up to the new root in 
> > this real and Offcial sites:
> > - https://www.agenciatributaria.gob.es/
> > - https://sedemeh.gob.es/
> > - https://www.sede.fnmt.gob.es
> 
> I have imported both of the "FNMT Clase 2 CA" and the "AC RAIZ FNMT-RCM" roots
> into my Firefox browser, and I still cannot access these three websites.


I have just installed the new FNMT CA (I already had the old one) and I haven't experienced any problem to acess the three sites in HTTPS mode without getting any warning (using SeaMonkey 2.0.2). Could you please re-check? Maybe you haven't marked the new CA as trusted for identifying web sites?
(In reply to comment #33)
> > You can test website whose SSL cert chains up to the new root in 
> > this real and Offcial sites:
> > - https://www.agenciatributaria.gob.es/
> > - https://sedemeh.gob.es/
> > - https://www.sede.fnmt.gob.es
> 
> I have imported both of the "FNMT Clase 2 CA" and the "AC RAIZ FNMT-RCM" roots
> into my Firefox browser, and I still cannot access these three websites.
> 
> Are you able to access these websites from within a Firefox browser?

In short, install all certificates available at: <http://www.cert.fnmt.es/index.php?cha=adm&sec=23&page=227&lang=es>

The text there reads:

"
For the certificate to work properly within the browser it is necessary to have installed both the root certificate of the FNMT-RCM as well as the certificate of the intermediate certification authorities.
"

In my experience, access to the URL above is granted when authorizing the "Certificado Raíz de la APE" to identify websites. According to the text though, one should also install the other three certificates (the "Certificado Raíz de la FNMT-RCM" seems to be included inside the APE one).
I have installed both certificates en #c26 and websites on #c32 work great.
Re: comment #35

It is standard practice for site certificates that any required intermediate certificate be installed on the site's Web server.  Only root certificates should be installed in a browser.  

In this case, testing of the root certificate should be considered valid only for a configuration involving that standard practice.
According to the relevant RFCs, server MUST send the complete CA chain up to the CA root. Sending of the CA root is optional. The above servers don't comply to the RFC and don't send the CA chain. 

(Amazing, if CAs don't get that right, how will their customers?! :S )
(In reply to comment #37)
> Re: comment #35
> 
> It is standard practice for site certificates that any required intermediate
> certificate be installed on the site's Web server.  Only root certificates
> should be installed in a browser.  
> 
> In this case, testing of the root certificate should be considered valid only
> for a configuration involving that standard practice.


For the record, I have installed _only_ these two certificates:

http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

and I have accessed with no problem at all to sites using certificates signed by either the old or the new CAs. So, AFAICT, I've sticked to standard practice.
Which one is the CA root? I assume it's http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt and apparently this seems to work now:

depth=2 /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM
verify return:1
depth=1 /C=ES/O=FNMT-RCM/OU=AC APE
verify return:1
depth=0 /C=es/O=FNMT-RCM/OU=AC APE/OU=500070015/CN=www.agenciatributaria.gob.es
verify return:1

    Verify return code: 0 (ok)
(In reply to comment #40)
> Which one is the CA root? I assume it's
> http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

There are two other root certificates which instead of using SHA-1 use SHA-256 and SHA-512 respectively:

http://www.cert.fnmt.es/certs/ACRAIZFNMTRCMSHA2.crt
http://www.cert.fnmt.es/certs/ACRAIZFNMTRCMSHA512.crt

but I don't know of websites or services that use them.

As I stated in comment #35, the recommendation is to also install the intermediate certificate (in the website it is described as a root certificate)

http://www.cert.fnmt.es/certs/ACRAIZAPE.crt

which is signed with ACRAIZFNMTRCM.crt. I did not know that only the root certificates should be the only ones necessary for website trust (SSL/TLS in general or even wider in scope?). That's why my observation above how the APE certificate being currently a link in the authentication chain wasn't more careful and might have ended up conveying the impression that I advocate only installing that one.

The reason for the recommendation of installing all four certificates might be because website authentication and encription isn't the only purpose of the above certificates. For example, identification and document signing certificates will be signed by the APE one, and in those cases there might not be a mandate for all intermediate certificates to be passed on to the user.
Any signed document or server must provide the CA certificates up to the CA root. Even documents, code and emails must include the complete chain.
(In reply to comment #33)
> Perhaps, but I cannot actually read this because the document is not in English
> and it is locked for copying, so I cannot copy-and-paste the text into a
> translator.
> 

OK Kathleen, it's my fault. I'll send you a copy (copy-and-paste enabled) of these documents ASAP. However, take a look at comment #34 from Ricardo Palomares.

> So is this a new sub-CA of the "AC RAIZ FNMT-RCM" root? Is it internally or
> externally operated?
> 
All of our CAs are internally operated.

> I have imported both of the "FNMT Clase 2 CA" and the "AC RAIZ FNMT-RCM" roots
> into my Firefox browser, and I still cannot access these three websites.
> 
> Are you able to access these websites from within a Firefox browser?

I had installed the http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt certificate and I had no problems experienced any problem to acess the three sites.
(In reply to comment #43)
> (In reply to comment #33)
> > Perhaps, but I cannot actually read this because the document is not in English
> > and it is locked for copying, so I cannot copy-and-paste the text into a
> > translator.
> > 
> 
> OK Kathleen, it's my fault. I'll send you a copy (copy-and-paste enabled) of
> these documents ASAP. However, take a look at comment #34 from Ricardo
> Palomares.
> 
Hello Kathleen. I coud get a copy-and-paste enabled version of CPSs. How can I submit you that files?

Best regards,

Rafa
Rafa, just attach them to this bug.
Attached file CPS of a FNMT's subordinated CA (obsolete) —
Re comment #35 and subsequent comments:  

It is contrary to the practice of Mozilla to install intermediate certificates in the NSS database.  Certificate authorities MUST advise their subscribers that all intermediate certificates should instead be installed in the servers containing the dependent subscriber certificates.  See, for example, <https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657>.  

Far too often, CAs fail to provide proper and emphatic guidance on this -- especially for site certificates -- which causes failures to establish secure Web browsing sessions.  When a Web server fails to include necessary intermediate certificates, I judge that as evidence that the server administrators really do not understand Internet security practices, which makes me uneasy about other aspects of the Web site.
(In reply to comment #33)

Hello Kathleen,

is there any new about this subject?

I think you have everything you requested. 

However if you need any more information please ask us.

Best regards,

Rafa
All, I appreciate those of you who are trying to help with this request, and the translations that you have provided have indeed been useful. However, for the questions below I need only to have Rafa (as the official representative of FNMT) respond.

> You can test website whose SSL cert chains up to the new root in 
> this real and Offcial sites:
> - https://www.agenciatributaria.gob.es/
> - https://sedemeh.gob.es/
> - https://www.sede.fnmt.gob.es

For the above urls when I enforce OCSP I get 
Error code: sec_error_bad_database
This usually means that the OCSP responder is responding to the OCSP request with an error code.

Please test:
Enforce OCSP in Firefox:  Tools->Options…->Advanced->Encryption->Validation
Select the box for “When an OCSP server connection fails, treat the certificate as invalid”
Reload the webpage

> Verification of Domain Name Ownership/Control as per section 7 of
> http://www.mozilla.org/projects/security/certs/policy/.

Found in translations of CPS of FNMT Clase 2 CA (current Spanish users CA):

“Document proving ownership of the domain name or IP address or internal document attesting to the Intranet.”

How is this information verified? Having the subscriber provide documentation is not sufficient. The information that is provided by the subscriber needs to be verified by the CA. The CA needs to have documented/audited procedures for verifying that the subscriber owns/controls the domain name to be included in the certificate. 

Google Translations from CPS of a FNMT's subordinated CA, AC APE:

145. FNMT-RCM will not, in such Certificate, the responsibility of verifying: 
• The authority and competence of the Registry to request a Certificate of 
based electronic identification on behalf of the body, agency or entity 
administration concerned and certificate holder. 
• Ownership of the organ or agency of government on the direction 
electronic and / or domain to be included in the Certificate

This seems to say that FNMT-RCM does not verify that the subscriber owns the domain name to be included in the certificate.  Is this a correct translation?

What CPS document for the AC RAIZ FNMT-RCM root describes the procedures that must be taken for all SSL end-entity certs issued within its hierarchy in regards to verifying that the subscriber owns/controls the domain name to be included in the certificate?


> Audit

Sorry if I missed it, but I still don’t have a current audit statement for either of these roots.


> Potentially Problematic Practices

In my notes I have a question mark for 
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
Do you delegate domain validation to third parties, such as RAs?  If yes, we’ll need further information about the controls placed on them.


> Further Questions about the FNMT Clase 2 CA root

The SSL certs for the websites that were provided for testing (https://www.cert.fnmt.es, https://www.citaprevia.sanidadmadrid.org/)
don’t have AIA extensions. However, I have noted an OCSP responder for the old root. Is OCSP supported for the old root? If yes, how is it used if the AIA extension is not set?

The old root is 1024-bit, which we are planning to phase out. When do you plan to stop issuing certs under that root? What will be the valid-to date of the last end-entity cert to expire under that root?
(In reply to comment #51)
> All, I appreciate those of you who are trying to help with this request, and
> the translations that you have provided have indeed been useful. However, for
> the questions below I need only to have Rafa (as the official representative of
> FNMT) respond.
> 
> > You can test website whose SSL cert chains up to the new root in 
> > this real and Offcial sites:
> > - https://www.agenciatributaria.gob.es/
> > - https://sedemeh.gob.es/
> > - https://www.sede.fnmt.gob.es
> 
> For the above urls when I enforce OCSP I get 
> Error code: sec_error_bad_database
> This usually means that the OCSP responder is responding to the OCSP request
> with an error code.
> 
> Please test:
> Enforce OCSP in Firefox:  Tools->Options…->Advanced->Encryption->Validation
> Select the box for “When an OCSP server connection fails, treat the certificate
> as invalid”
> Reload the webpage
> 
Hi Kathleen,
I've tested what you said and I get the same result. However, I analyzed the network traffic (with WireShark tool) and I've could see that OCSP is responding succesfully.
I send a screenshot where you can see OCSP Response (the server I've connected is https://www.sede.fnmt.gob.es).
I don't know why firefox is returning that error. Any idea?
It still fails for me.

When I turn off OCSP enforcement, I can go to the website just fine. However, the default in later versions of Firefox is to have OCSP enforced.

After I turn off OCSP and go to the website, then when I re-enforce OCSP I have to clear my cache before the error is visible again.  

After you enforce OCSP, please try clearing your history/cache and restarting Firefox if needed.
(In reply to comment #54)
> It still fails for me.
> 
> When I turn off OCSP enforcement, I can go to the website just fine. However,
> the default in later versions of Firefox is to have OCSP enforced.
> 
> After I turn off OCSP and go to the website, then when I re-enforce OCSP I have
> to clear my cache before the error is visible again.  
> 
> After you enforce OCSP, please try clearing your history/cache and restarting
> Firefox if needed.

I got the same results but I don't know why. As you can see in screenshot attached Firefox receives a correct OCSP Response. However firefox returns error... Maybe a bug in Firefox's OCSP Client?
(In reply to comment #51)
> > Verification of Domain Name Ownership/Control as per section 7 of
> > http://www.mozilla.org/projects/security/certs/policy/.
> 
> Found in translations of CPS of FNMT Clase 2 CA (current Spanish users CA):
> 
> “Document proving ownership of the domain name or IP address or internal
> document attesting to the Intranet.”
> 
> How is this information verified? Having the subscriber provide documentation
> is not sufficient. The information that is provided by the subscriber needs to
> be verified by the CA. The CA needs to have documented/audited procedures for
> verifying that the subscriber owns/controls the domain name to be included in
> the certificate. 

That information is verified with responsible entity of managing the registry of Internet domain names (i.e. Red.es in Spain). I'll suggest to our Legal Department to include this information in next version of CPS

> 
> Google Translations from CPS of a FNMT's subordinated CA, AC APE:
> 
> 145. FNMT-RCM will not, in such Certificate, the responsibility of verifying: 
> • The authority and competence of the Registry to request a Certificate of 
> based electronic identification on behalf of the body, agency or entity 
> administration concerned and certificate holder. 
> • Ownership of the organ or agency of government on the direction 
> electronic and / or domain to be included in the Certificate
> 
> This seems to say that FNMT-RCM does not verify that the subscriber owns the
> domain name to be included in the certificate.  Is this a correct translation?

Well, the Spanish Mint is not responsible of verify the ownership of electronic direction. This CA is only for public entities and we have legislation that requires that entities to publish their electronic direction (and ownership) previously in Official State Gazette (BOE). FNMT-RCM verifies publication of this information before issuing certificate.
This practice is stablished at internal procedures of FNMT-RCM CA and I'll suggest to our Legal Department to include this information in next version of CPS


> What CPS document for the AC RAIZ FNMT-RCM root describes the procedures that
> must be taken for all SSL end-entity certs issued within its hierarchy in
> regards to verifying that the subscriber owns/controls the domain name to be
> included in the certificate?
> 
I'll suggest to our Legal Department to include this information in next version of CPS.
Currently there is only a sub-ca but in the future will be several sub-cas so we'll include general information about verification procedures (will be equivalent in rigor). Then we'll include specific practices by CA in each sub-ca specific CPS.

> 
> > Audit
> 
> Sorry if I missed it, but I still don’t have a current audit statement for
> either of these roots.
> 
We expect to get the preliminary audir report at 10/03/2010

> > Potentially Problematic Practices
> 
> In my notes I have a question mark for 
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
> Do you delegate domain validation to third parties, such as RAs?  If yes, we’ll
> need further information about the controls placed on them.
> 

We have RAs that validate information only for citizen certificates but never for SSL server certificates.

 
> > Further Questions about the FNMT Clase 2 CA root
> 
> The SSL certs for the websites that were provided for testing
> (https://www.cert.fnmt.es, https://www.citaprevia.sanidadmadrid.org/)
> don’t have AIA extensions. However, I have noted an OCSP responder for the old
> root. Is OCSP supported for the old root? If yes, how is it used if the AIA
> extension is not set?

There is a OCSP Responder but it's not free. Only FNMT-RCM clients can access that service.

> The old root is 1024-bit, which we are planning to phase out. When do you plan
> to stop issuing certs under that root?
We plan to stop issuing certificates on december of this year.

> What will be the valid-to date of the
> last end-entity cert to expire under that root?
3 years from stop issuing certs.

As you can see, I'll suggest that certain information from internal procedures and practices be included in next versions of CPSs.
Will it be sufficient? Will there be any further problem?
> We expect to get the preliminary audit report at 10/03/2010

Please provide the public-facing audit statement when it is available.

> There is a OCSP Responder but it's not free. 
> Only FNMT-RCM clients can access that service.

Does that apply to the new root too? Or just the old root?

> As you can see, I'll suggest that certain information from internal procedures
> and practices be included in next versions of CPSs.
> Will it be sufficient? Will there be any further problem?

Please post the new CP/CPS documents or links in this bug when they are available. Please be sure that the documentation explains how the information provided by the subscriber is compared (or tested) with other information to confirm that the subscriber owns/controls the domain name to be included in the certificate.
In regards to OCSP, I added further information to https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root

However, I don't really know what would cause the error that I get when I try to access the test websites, such as https://www.agenciatributaria.gob.es/

security library: bad database.
(Error code: sec_error_bad_database)
Maybe a comment from Nelson B Bolyard give some light:


SEC_ERROR_BAD_DATABASE always means one of two things;
- if you were trying to find/fetch something, it cannot be found.
- if you were trying to store something, there is already such a thing
in the DB, and your attempt to store it would overwrite that other thing.

http://article.gmane.org/gmane.comp.mozilla.crypto/10435
In response to Rafa's inquiries in the dev-tech-crypto list, 
I did some digging and found that

a) this CA is issuing (or, has issued) certs in which the RDNs in the cert 
names are encoded in the reverse of the standard order.  The RDNs are encoded
from most specific first to most general last, but the standard order is 
from most general first (e.g. country) to most specific last (e.g. Common 
name).  This is not a show stopper, IMO, but it suggests a lack of awareness 
of applicable international standards that I would not expect from a first 
class certificate authority.

b) In some cases, the certificate names are encoded with the ASN1 character 
set "printable string" and in other case with the character set "UTF8 String".
Evidently the CA expects names to match despite the different character 
set encodings.  The names will NOT match when the character sets do not 
match.  This IS a show stopper.
I downloaded the root CA cert from the URL given in comment 0.
The SHA1 fingerprint does not exactly match that given in comment 0.

Comment 0 SHA1: 43 F9 81 10 D5 8A FD 48 22 52 31 80 DO 08 28 37 2F EF 9A 54
computed        43:F9:B1:10:D5:BA:FD:48:22:52:31:B0:D0:08:2B:37:2F:EF:9A:54
                      ^        ^                 ^         ^
These are obviously typos.
The MD5 fingerprints match.
Comment 0 MD5   25:9D:CF:5E:B3:25:9D:95:B9:3F:00:86:5F:47:94:3D
computed        25:9D:CF:5E:B3:25:9D:95:B9:3F:00:86:5F:47:94:3D
Rafa, we are waiting for FNMT response. Please, could you check latest comments?
We have been working in  bugs that Nelson reported. Hope to have them resolved on 10 June.
(In reply to comment #63)
> We have been working in  bugs that Nelson reported. Hope to have them resolved
> on 10 June.

We have solved the problem last week.

Now Firefox can validate OCSP responses successfully.
Thanks Rafa. I have successfully browsed to the test websites in my Firefox browser with OCSP enforced, and with no errors.

Please also respond to Comment 60 and Comment 57.
Rafa, please, answer to comment 65 and hopefully we could have the certificate on Mozilla 2.0 (just in time for Firefox 4 release).
(In reply to comment #65)
> Thanks Rafa. I have successfully browsed to the test websites in my Firefox
> browser with OCSP enforced, and with no errors.
> 
> Please also respond to Comment 60 and Comment 57.

Hi again Kathleen,

excuse me for not answering before, but I've been offline until today.

Regarding to comment 60, in fact, this was the cause of the problem with OCSP enforced validation.

Regarding to comment 57,

Q: Does that apply to the new root too? Or just the old root?
A: It applies just the old root

Q: Please provide the public-facing audit statement when it is available.
A: I attach the CSPS

Q: Please post the new CP/CPS documents or links in this bug when they are available [...]
A: I attach CPS document. You can access this document also at http://www.cert.fnmt.es/dpc/dpcc2.pdf.

You can find information you need at pages 13 (paragraphs 43 and 44) and 19 (paragraph 67 and 68).

If you have any queries please do not hesitate to contact us again.

Best Regards,

Rafa
Please attach a version of the "FNMT Clase 2 CA certificate policy statement" (Comment #69) that is enabled for copying so that I can copy-paste into a translator.

When audit statements 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 statements that have been provided. Therefore, I have sent an email to asimelec@asimelec.es to request that they confirm the authenticity of the audit statement provided in Comment #68.
(In reply to comment #70)
> Please attach a version of the "FNMT Clase 2 CA certificate policy statement"
> (Comment #69) that is enabled for copying so that I can copy-paste into a
> translator.
> 
> When audit statements 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 statements that have been provided.
> Therefore, I have sent an email to asimelec@asimelec.es to request that they
> confirm the authenticity of the audit statement provided in Comment #68.

I've attached CPS enabled for copying.

Regarding the other issue, if you want a direct contact, you can write to Susana Asensio (susana.asensio@asimelec.es). You can also see that ASIMELEC scheme is registered in the list of European schemes (http://ec.europa.eu/information_society/policy/esignature/eu_legislation/notification/spain/index_en.htm)
>> I've attached CPS enabled for copying.

Thanks.

In this document, a sub-bullet of #44 says: "Verificar que toda la información contenida en la solicitud del Certificado se corresponde con la aportada por el Solicitante."

Google Translations says: "Verify that all information contained in the certificate request matches that provided by the Applicant."

Is that a correct translation? Or is it supposed to be something to the effect of "Verify the accuracy of all data provided."? 

A sub-bullet of #68 says: "Documento acreditativo de la propiedad del Nombre de Dominio o dirección IP o documento interno acreditando la Intranet."

Google Translation says: "Document proving ownership of the domain name or IP address or internal document certifying the Intranet."

How does FNMT verify that this document is authentic?

>> if you want a direct contact, you can write to Susana Asensio 
>> (susana.asensio@asimelec.es).

I have sent email to susana.asensio@asimelec.es to confirm the authenticity of the audit statement.
(In reply to comment #73)
> >> I've attached CPS enabled for copying.
> 
> Thanks.
> 
> In this document, a sub-bullet of #44 says: "Verificar que toda la información
> contenida en la solicitud del Certificado se corresponde con la aportada por el
> Solicitante."
> 
> Google Translations says: "Verify that all information contained in the
> certificate request matches that provided by the Applicant."
> 
> Is that a correct translation? Or is it supposed to be something to the effect
> of "Verify the accuracy of all data provided."? 

We verify that information in the certificate request (electronic) matches documents (physic) provided by the applicant.


> A sub-bullet of #68 says: "Documento acreditativo de la propiedad del Nombre de
> Dominio o dirección IP o documento interno acreditando la Intranet."
> 
> Google Translation says: "Document proving ownership of the domain name or IP
> address or internal document certifying the Intranet."
> 
> How does FNMT verify that this document is authentic?
> 

In our "GENERAL CERTIFICATION PRACTICES STATEMENT" (applicable to any CA managed by FNMT) we clarify that point. You can find this information at page page 40 (paragraphs 155 and 156).

You can download this doc (copy enabled) from: http://www.cert.fnmt.es/dpc/dgpc.pdf

Additionally, I send the translation of these paragraphs:

"155.	In the cases in which the Certificate includes data like domain names or IP addresses, the FNMT–RCM shall check, via the information systems that the authorised registrars for each case make available to the public, that the documentation required and validated by the Registry Office is correct. 
156.	For such purpose the publications in the different official state and autonomous region gazettes shall be taken into account, as well as the public registers and the registers accessible by the FNMT-RCM of the different registry bodies of domain names and assignation of IP addresses."





You can 



> >> if you want a direct contact, you can write to Susana Asensio 
> >> (susana.asensio@asimelec.es).
> 
> I have sent email to susana.asensio@asimelec.es to confirm the authenticity of
> the audit statement.
In reply to comment 74:
> We verify that information in the certificate request (electronic) matches
> documents (physic) provided by the applicant.

That's a good step, but it's not sufficient unless the documents provided by
the applicant are true.  How do you verify that?
(In reply to comment #75)
> In reply to comment 74:
> > We verify that information in the certificate request (electronic) matches
> > documents (physic) provided by the applicant.
> 
> That's a good step, but it's not sufficient unless the documents provided by
> the applicant are true.  How do you verify that?

As we said, in the cases in which the Certificate includes data like domain names or IP addresses, the FNMT–RCM shall check, via the information systems that the authorised registrars for each case make available to the public, that the documentation required and validated by the Registry Office is correct.

For such purpose the publications in the different official state and
autonomous region gazettes shall be taken into account, as well as the public
registers and the registers accessible by the FNMT-RCM of the different
registry bodies of domain names and assignation of IP addresses.
Rafa,

Given that, for example, https://www.agenciatributaria.gob.es/ https://sedemeh.gob.es/ and https://www.sede.fnmt.gob.es/ nowadays requires root certificate AC RAIZ FNMT-RCM which can be downloaded from http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

Could you open another bug requesting inclusion of this other FNMT root certificate ?

Otherwise MS will have a competitive advantage over Mozilla's products given that MS already supports this additional root certificate through KB931125

FNMT root certificate this bug was originally opened, which can be downloaded from http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer is still required for https://www.citaprevia.sanidadmadrid.org/ and many other sites.
As per the Updated Information Gathering document, this request is for inclusion of both the "FNMT Clase 2 CA" and "AC RAIZ FNMT-RCM" root certificates.

I am still waiting for a response from the auditor.
I have received the following response from the auditor in regards my request to confirm the authenticity of the attached statement, and other questions that I asked.
--
I am Julián Inza, the Chairman (President) of the ASIMELEC CSP Certification Scheme and signer of the statement referred in https://bugzilla.mozilla.org/attachment.cgi?id=477940

I have reviewed completly the audit report issued by auditor company S21Sec, under the rules of the scheme. I have reviewed also all CPS under the scope of the audit and that cover all certification services carried out by FNMT.

FNMT-RCM stands out for Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda, and is the Spanish Royan Mint, which issues and manages certificates for Government related activities.

The summary is as follows:

    * FNMT Clase 2 CA: is the root CA with which FNMT has been issuing personal certificates for several years. These certificates are managed according to european Directive 1999/93/CE, so this root CA is issuing "qualified certificates" mainly for citizens, and public servants.
    * AC RAIZ FNMT-RCM: is the new root CA under which the "CA APE" is running. So, APE (which stands for Administración Pública Española - Spanish Government related certificates) is a subordinate CA for AC RAIZ FNMT-RCM. Under APE hierarchy some certificates are designed to fit "sede electrónica" requirements. This means "electronic headquarter" which, in brief, are SSL certificates with additional extensions. Other uses are as qualified certificates for public servants and seal certificates for government agencies. This activity has been specially covered by the audit, so, this root should be included in the Browser Trusted List.
    * CA FEM: Means "Firma Electrónica Móvil" (Mobile Electronic Signature) and is a special CA for GSM mobile phones certificates, also issued under "qualified certificate" requirements.

ASIMELEC audit Scheme for Certification Service Providers (european designation for CAs, Certification Authorities) equals or exceed requirements such as "WebTrust for CAs" and is specially designed to have into account european legislation (Directive 1999/93/CE), and technical requirements such as ETSI TS 101 456, ETSI TS 101 862, ETSI TS 102 280, CWA 14172 (-1, -2 and -3) or CWA 14167-1.

ASIMELEC is one of the two main Spanish IT Associations, and is the sponsor of the Scheme. It has recently merged with AETIC, the other big association. Together they are now AMETIC, so future compliance statements will be issued by AMETIC which retain all activities of both organitations.

ASIMELEC CSP Audit Scheme Web page is available at http://www.asimelec.es/Items/ItemDetail.aspx?ID=993

--
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 two weeks. 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 be in the discussion for
several 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.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: information incomplete → Information confirmed complete
I am just a particular, not important, just another spanish firefox user.

I have had several certificates from fnmt, in Spain the fnmt certifies webpages of the government and persons to access those webpages.

FNMT offers free services to the citizens: certificate request, revocation, etc but paid services (AFAIK) to other entities that request their services.

In Spain we also have an identity card (called DNIE or DNI electronico) with a chip and a pair of certificates on it but it is not very used because it requires having a card reader, having that card, installing several programs and drivers (complex for the medium user) and it is still not fully functional in GNU/Linux (is a work in progress).

FNMT certificates are the most compatible in Spain with the public administration and several other pages like online banks, justice, etc.

I have installed in a lot of computers the FNMT root cert and 2CA because almost all administrations use this kind of certificates. Including this certificate will be very useful for us, the spanish users.

I have not found the discussion in mozilla.dev.security.policy yet, I suppose that is still "on queue" but I would like to contribute with one more "user opinion".

If I can help translating something or with any other thing, please mail me.
As Jose Sanchez, I have not managed to find a discussion published in mozilla.dev.security.policy yet, so I join in this space at the request of Jose Sanchez (comment # 82) to include the certificates FNMT Firefox, so as to facilitate the use of Firefox in electronic management tasks, and thus expedite the migration to Firefox in Spanish users' computers.
I'm IT director on a local governement in Spain. Our users and the citizens need digital sign and we need the certificate of FNMT.
 I join in this space at the request of Jose Sanchez (comment # 82) to include the certificates FNMT Firefox, so as to facilitate the use of Firefox in electronic management tasks, and thus expedite the migration to Firefox in Spanish users' computers.
I'm a Spanish user who would like the FNMT root certificate to come already installed in Firefox too, but I don't think the proper way for claiming this is adding more comments in the bug.

Comments are for helping to solve the bug rather than to give your support.

Better try adding votes for this fix in the "Importance" field at the top of the bug.
Take it easy, my friends. :-) As explained in comment #81, there is queue to enter in public discussion, and FNMT is already in that queue (the last one):

https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Given that every discussion can take several weeks and the lenght of the queue, we should be prepared to wait for about six months before FNMT discussion starts. If anybody of you have experience in PKI, audit practices and, in general, security, you can join the open discussions and help move them forward. The faster they go, the sooner FNMT discussion will advance thru the line. :-)
May I just add what a shame for the Spanish goverment to still not have recognition, a multi-million dolar online IT platform for online government access stuck, while Izenpe, the local Basque government certificate authority already is in the database, even if their local id card scheme was passed out when the non nationalist got into power. It's just amazing how some things change and others not.
I as a regular computer technicia can say that the system is secure and complex, I guess the spanish goverment didn't trust Bush and their US based certification authoritys.
Please, stop bugspamming.

We all want to add the FNMT certificate since this bug was opened almost 3 years ago. But the burrocracy is slow as you know. Please, be patient. This is not the ideal situation, but we can only wait to start the public discussion.

If you want to comment this bug, please refer to Mozilla Hispano forums, please.
(In reply to comment #87)
> May I just add what a shame for the Spanish goverment to still not have
> recognition, (..)
> I as a regular computer technicia can say that the system is secure and
> complex, I guess the spanish goverment didn't trust Bush and their US based
> certification authoritys.


To add up to Guillermo's comment, while most of the delay has happened on FNMT side, right now the bug is waiting on Mozilla queue for public discussion. And it has NEVER had anything to do with political or country issues. The certification standard is country-neutral.

BTW, you can always add the CA certificate yourself:

http://www.mozilla-hispano.org/documentacion/Importar_un_certificado

Keep in mind that there is two CAs now to be installed:

http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt
Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
We provide requested info:

1 - We audit our systems periodically. In fact, next intrusion test will be done within the next few months (before January 2012)
2 - We haven't any cross-signed certificate.
3 - Access to certificate issuance software is secured by using X509 certificates with private keys in a smartcard. So operators need their smartcard and its associated password in order to issue certificates
4 - All of SSL/codesigning certificate requests are manually approved for issuing. This is done after verifying concerning information. There is no automatic issuing
5 - There aren't third parties that issue SSL or codesigning certificates directly or indirectly.
This request is near the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

As such, we need to update the information in the Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=507241

Would a representative of FNMT please review this document to identify things that have changed or been updated, and comment in this bug to provide the current information? Also, please provide an updated audit statement.
We provide updated information:

AC RAIZ FNMT-RCM: we have a new CA under this root: "AC Administración Pública". This CA is an updated version of APE CA in order to meet new requirements from Spanish Goberment about certificates of Public Administrations. It has a 2048 bits key.
CA Certificate: http://www.cert.fnmt.es/certs/ACAP.crt
DPC (CAs AP and APE integrated): http://www.cert.fnmt.es/dpc/ape/dpc.pdf
CRLs are in: ldap://ldapape.cert.fnmt.es
OCSP: http://ocspap.cert.fnmt.es/ocspap/OcspResponder
A test website: https://sede.xunta.es
We haven't an updated audit statement (current is valid until August 2012). Hhowever, we plan to conduct a new audit process before June 2012.
Re comment #94:  

The latest audit statement indicated in the Completed Information Gathering Document is dated 29 July 2010.  The confirmation of that statement by the auditor is dated 25 January 2011.  Both of those are more than a year ago.  Mozilla policy requires annual audits, which means there should have been an audit statement from approximately July 2011.
Rafa,

I am re-reviewing this request because it is at the top of the queue for discussion. Please...

1) Point me to (and translate) the DPC section that covers the frequency of the audit.

2) Respond to the action items outlined here:
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

3) The test website that is given for the old "FNMT Clase 2 CA" is https://www.cert.fnmt.es
The end-entity cert does not contain CRL or OCSP URIs. Also, I see that the old root signs end-entity certs directly. I believe this will be a show-stopper for inclusion of this root. I recommend modifying this inclusion request to only be for the new "AC RAIZ FNMT-RCM" root.

4) I have a note that SSL certificates are valid for 4 years. 
According to the current Mozilla CA Certificate Policy
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
"6. We require that all CAs whose certificates are distributed with our software products: ...
verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less;"
This will need to be addressed in both process and documentation for the end-entity certs chaining up to the root(s) that you are requesting inclusion for.
Kathleen,

I'm sorry but I thought that we had nothing to do until we had a new audit statement.

In fact, we are being audited these days.

Regarding #3, I agree with you. This inclusion request is only for de new "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?

Regarding #4, SSL certificates issued by any SubCA chaining to "AC RAIZ FNMT-RCM" root will be valid for a maximum of 3 years

As soon as possible I will upload updated CPS, audit statement, etc.

(In reply to Kathleen Wilson from comment #96)
(In reply to Rafa from comment #97)
> Regarding #3, I agree with you. This inclusion request is only for de new
> "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?

I've updated my notes and 
http://www.mozilla.org/projects/security/certs/pending/#FNMT
to remove reference to inclusion of the "FNMT Clase 2 CA" root.


This request is currently waiting for:
1) Response to question about audit frequency (reference Comment 96 and http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html)
2) updated CPS and audit statement
3) Response to the February CA Communication, 
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

Thanks,
Kathleen
(In reply to Kathleen Wilson from comment #98)
> (In reply to Rafa from comment #97)
> > Regarding #3, I agree with you. This inclusion request is only for de new
> > "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?

Before you modify the inclusion request:

1. How many websites are chaining to the old root? How many are chaining to the new root? If there are many websites chaining to the old root then we should find a way to get the old root working.

2. Does the new "AC RAIZ FNMT-RCM" root cross-sign the older root? Would it make sense to create such a cross-signing so that we could include only the "AC RAIZ FNMT-RCM" root? Would that be sufficient to address the concern that the old root issued EE certificates directly?

3. Is FNMT still issuing certificates from the Class 2 certificate, or is FNMT currently only issuing new certificates from the "AC RAIZ FNMT-RCM" root?

The fact that https://www.cert.fnmt.es/ itself uses a certificate that was directly issued by the Class 2 certificate, combined with the fact that Chrome and IE trust that certificate, indicates to me that adding only the "AC RAIZ FNMT-RCM" certificate is not going to solve the problems we are trying to solve.

The process for revoking trust in a sub-CA certificate is the same process we would use for revoking trust in a root CA certificate. Consequently, I am not sure there's much practical benefit in avoiding adding the Class 2 certificate on that basis.

Another question: How common is it for FNMT to issue certificates for domains outside of *.es? Would it be reasonable to limit the trust of FNMT to .es domains, at least in the short-term?
(In reply to Kathleen Wilson from comment #98)
> (In reply to Rafa from comment #97)
> > Regarding #3, I agree with you. This inclusion request is only for de new
> > "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?
> 
> I've updated my notes and 
> http://www.mozilla.org/projects/security/certs/pending/#FNMT
> to remove reference to inclusion of the "FNMT Clase 2 CA" root.
> 
> 
> This request is currently waiting for:
> 1) Response to question about audit frequency (reference Comment 96 and
> http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html)
> 2) updated CPS and audit statement
> 3) Response to the February CA Communication, 
> https://wiki.mozilla.org/CA:Communications#February_17.2C_2012
> 
> Thanks,
> Kathleen

Hello Kathleen,

I answer your questions:

1) Last august it was approved to modify audit frequency. So, from now, audit frequency will be of 1 year.
We have included this statement in a new version of CPS. As soon as new CPS is published I'll update this thread

2) We hope to have new audit statement at december 2012. As soon as we get new audit statement I'll update this thread.

3) Regards to the February CA Communication:

Q1: A
Q2: N/A
Q3: N/A
Q4: Confirmed
Q5: IP

Regards,

Rafa
As per Comment #100, please update this bug with URLs to the new CPS and audit statement when available.

Please also add a comment to this bug to provide your response to the action items listed in the CA Communication that was sent today, and is available here:
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
tef asked us to do this and so this should probably be tef+. I can't figure out how to set that flag.
blocking-basecamp: --- → ?
(In reply to Brian Smith (:bsmith) from comment #102)
> tef asked us to do this and so this should probably be tef+. I can't figure
> out how to set that flag.

Note: we won't be able to get this done today so it should be blocking-basecamp- but I nom'd it so that somebody with power and authority can set the tef+ flag, which doesn't appear for me in bugzilla.
(In reply to Brian Smith (:bsmith) from comment #102)
> tef asked us to do this and so this should probably be tef+. I can't figure
> out how to set that flag.

Okay, done.
blocking-b2g: --- → tef+
blocking-basecamp: ? → -
FNMT still needs to provide their updated CPS and audit statements, and we still need to have their request discussed in m.d.s.policy.

What is the deadline for blocking-b2g?

Kathleen
(In reply to Brian Smith (:bsmith) from comment #99)
> (In reply to Kathleen Wilson from comment #98)
> > (In reply to Rafa from comment #97)
> > > Regarding #3, I agree with you. This inclusion request is only for de new
> > > "AC RAIZ FNMT-RCM" root. How we modify this inclusion request?

I answer your questions:

> Before you modify the inclusion request:
> 
> 1. How many websites are chaining to the old root? How many are chaining to
> the new root? If there are many websites chaining to the old root then we
> should find a way to get the old root working.

Currently most of SSL certificates issued by FNMT are chaining to the old root. We expect this change during 2013.

> 2. Does the new "AC RAIZ FNMT-RCM" root cross-sign the older root? Would it
> make sense to create such a cross-signing so that we could include only the
> "AC RAIZ FNMT-RCM" root? Would that be sufficient to address the concern
> that the old root issued EE certificates directly?

No, new root is not going to cross-sign the older root.
 
> 3. Is FNMT still issuing certificates from the Class 2 certificate, or is
> FNMT currently only issuing new certificates from the "AC RAIZ FNMT-RCM"
> root?

Currently we issue certificates with the "old root". We plan to stop issuing SSL certificates with old root by mid-year or 3Q 2013

> The fact that https://www.cert.fnmt.es/ itself uses a certificate that was
> directly issued by the Class 2 certificate, combined with the fact that
> Chrome and IE trust that certificate, indicates to me that adding only the
> "AC RAIZ FNMT-RCM" certificate is not going to solve the problems we are
> trying to solve.
> 
> The process for revoking trust in a sub-CA certificate is the same process
> we would use for revoking trust in a root CA certificate. Consequently, I am
> not sure there's much practical benefit in avoiding adding the Class 2
> certificate on that basis.
> 
> Another question: How common is it for FNMT to issue certificates for
> domains outside of *.es? Would it be reasonable to limit the trust of FNMT
> to .es domains, at least in the short-term?

Most of SSL certificates we issue are for .es domains. In fact most of them are issued to Public Administration entities or associated organizations.

So it would be reasonable solution limit trust to .es domains.
(In reply to Kathleen Wilson from comment #105)
> What is the deadline for blocking-b2g?

I'd say ASAP but that won't help :)  How about we say next Friday, January 25?
How are things going here?
Flags: needinfo?(kwilson)
Still needed (from comment #101):
> As per Comment #100, please update this bug with URLs to the new CPS and
> audit statement when available.
> 
> Please also add a comment to this bug to provide your response to the action
> items listed in the CA Communication that was sent today, and is available
> here:
> https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
Flags: needinfo?(kwilson)
New version of our CPS is pending of final approval. As soon as it's released I will update it in the thread.

In addition, we are working in response to the last "CA Comunication". I hope it'll be ready soon.
De-noming because it looks like it will be a while and it looks like I was mistaken in considering it a blocker when I nominated it. I should have marked it tracking-b2g instead, but AFAICT I cannot do that in the NSS product.
blocking-b2g: tef+ → tef?
(In reply to Brian Smith (:bsmith) from comment #111)
> De-noming because it looks like it will be a while and it looks like I was
> mistaken in considering it a blocker when I nominated it. I should have
> marked it tracking-b2g instead, but AFAICT I cannot do that in the NSS
> product.

Okay, tef- but please nominate any patches for uplift to the relevant b2g branch when they are ready.  It looks like the tracker flag isn't on all products so I think the approval on the patch(es) is the best we can do.  Oh, I'll also accept private email to get attention to this :)
blocking-b2g: tef? → ---
Whiteboard: Information confirmed complete → Information incomplete
Today I have seen than CPS was update on July. Rafa, there are any other update?

It's important update information to try to resolve this bug.
The Root certificate download URL is not longer valid.
You can found it here:
https://www.sede.fnmt.gob.es/descargas/certificados-raiz-de-la-fnmt
It wasn't clear to me which information I had was current or outdated. So I created a new CAInformation document (attached).

Within this document, the items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness, and provide the necessary information in this bug.
Aboute Potential Constraints on this CA Hierarchy. Would it be reasonable to constrain certificate issuance within this CA hierarchy to certain domains, such as *.es?

Not. There is some domains as *.org with FNMT certificates. Example: https://tramites2.ayuntamientojun.org/to/montarTramiteAction.egim?idTrami=55
Status of this bug: Waiting for response from an official representative of the CA regarding items highlighted in yellow in the document attached to Comment #115.
Kathleen, maybe it would be a good idea to add the comment number to the whiteboard too, since almost 6 years of comments are difficult to follow ;)
Comment to FNMT:
Resolution of this bug is also blocked the inclusion of CA in Android's trust store.

You can see http://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=53195 for more information.
Whiteboard: Information incomplete → Information incomplete -- Coment #115
I keep telling my family in the cuisine you can distinguish bad management because two things:

1. Lots of unfinished work in sight.
2. Lots of speaking being exchanged.

The reason is always the same: there isn't really anybody taking care of the process, but just some people blindly working in smoke.

So stop working and start solving. Perhaps it will take you moths, but not years.
Updated General CPS includes:
- Periodicity of one year to the fulfilment of audits 
- Prohibition to issue CA certificates to other different entities to FNMT-RCM.
- Limitation to a maximum of 3 years the period of validity of the end-entity certificates.
Attachment #427562 - Attachment is obsolete: true
Also, I attach reference to WebTrust seal recently obtained:

https://cert.webtrust.org/ViewSeal?id=1784
Truthful and complete translation into English of new software component CA.
Attachment #427570 - Attachment is obsolete: true
Attachment #477943 - Attachment is obsolete: true
Attachment #483443 - Attachment is obsolete: true
Updated version of specific CPS of CA for Public Organizations and Administrations
Attachment #427559 - Attachment is obsolete: true
Which of the 3 trust bits (Websites, Email, Code Signing) are you requesting to have enabled for the 	
AC RAIZ FNMT-RCM root? My notes says "Websites, Code Signing".

The Seal file that you attached in Comment #124 is for "WebTrust for Certification Authorities -- SSL Baseline Requirements version 2.0", which is only regarding SSL cert issuance.
Does FNMT have other current audit statements, such as WebTrust for CA, ETSI TS 102 042 or ETSI TS 101 456?
See section 11 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
If yes, please provide the link to them.
Attached file 435736-CAInformation.pdf (obsolete) —
I have entered the information for this root inclusion request into SalesForce. Please double-check the attached document for accuracy, and search for "Need Response" to see the remaining questions.
Hi Kathleen.

We are requesting to have enabled for Websites and Code Signing.

We thought  that "WebTrust for Certification Authorities" audits was enough for that. 
 
Anyway, we have already started an ETSI 101 456 audit process and we expect to have concluded it in a few months
Hi Kathleen,

We are contacting you as we are facing the following question:

As internal consultancy service of FNMT we are surprised that besides the accreditation “SSL Baseline Requirements Audit Criteria”, FNMT was asked for "Principles and Criteria for Certification Authorities 2.0”. 

As far as we know the principles of both standards are identical, except for technical network security specifications “SSL Requirements Baseline Audit Criteria” as shown in the following matrix::

WT CA 2.0                                    WT BR SSL 2.0
CA Principles	                             Principles
P1. CA Business Practices Disclosure         P1. Baseline Requirements Business Practices Disclosure
P2. CA Environmental Controls                P3. CA Environmental Security
P3. Service Integrity                        P2. Service Integrity
                                             P4. Network and Certificate Systems Security Requirements 

We consider that is enough to comply with “SSL Baseline Requirements Audit Criteria”  for the certifications under the scope. Would you be so kind to let us know the reason to ask for both standards? Based on our understanding, this situation increases the costs of accreditation for quality, security and reliability of WebTrust, ... in addition to cause confusion.

Please, we would like to clarify this issue.

Best regards
(In reply to Antonio from comment #131)

I posted your question in the mozilla.dev.security.policy discussion forum:
https://groups.google.com/d/msg/mozilla.dev.security.policy/gAyPrxZezqo/Q1RAiLfZUD8J
(In reply to Kathleen Wilson from comment #132)
> (In reply to Antonio from comment #131)
> 
> I posted your question in the mozilla.dev.security.policy discussion forum:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/gAyPrxZezqo/
> Q1RAiLfZUD8J

Here's the answer:
They are completely different in their application. SSL Baseline only cover the CAB baseline requirements and do not cover the more detailed requirements for WebTrust certification (and initial acceptance). WebTrust for CA covers accepted practices for a CA - additional SSL Baseline were brought in just to deal with specific additional issues.
(In reply to Kathleen Wilson from comment #129)
> Created attachment 8549906 [details]
> 435736-CAInformation.pdf
> 
> I have entered the information for this root inclusion request into
> SalesForce. Please double-check the attached document for accuracy, and
> search for "Need Response" to see the remaining questions.


Dear Kathleen,

Indeed, new version of CPS and PC that are within the scope of the certification will comply with the requirement of the “WebTrust SM/TM for Certification Authorities WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security”. However, for the sake of coherence, it was not possible to consider such statement but after finishing the audit. 

It will be included the following text:

FNMT-RCM conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. 

We remain at your disposal for any further clarification concerning this topic.

Best regards
(In reply to Antonio from comment #134)
> Indeed, new version of CPS and PC that are within the scope of the
> certification will comply with the requirement of the “WebTrust SM/TM for
> Certification Authorities WebTrust Principles and Criteria for Certification
> Authorities - SSL Baseline with Network Security”. However, for the sake of
> coherence, it was not possible to consider such statement but after
> finishing the audit. 
> 
> It will be included the following text:
> 
> FNMT-RCM conforms to the current version of the Baseline Requirements for
> the Issuance and Management of Publicly-Trusted Certificates published at
> https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any
> inconsistency between this document and those Requirements, those
> Requirements take precedence over this document. 
> 
> We remain at your disposal for any further clarification concerning this
> topic.


Please clarify if you intend to add that statement to the CP/CPS, or if you are saying it will be part of the audit statement only.

For reference, I asked in the discussion forum about having the BR commitment to comply in the audit statement only:
https://groups.google.com/d/msg/mozilla.dev.security.policy/wsw2G-PFKiA/akU0bhzN8MMJ
It looks to me like the answer will be that it needs to be in the CP/CPS. You are welcome to participate in that discussion.
(In reply to Kathleen Wilson from comment #135)
> (In reply to Antonio from comment #134)
> > Indeed, new version of CPS and PC that are within the scope of the
> > certification will comply with the requirement of the “WebTrust SM/TM for
> > Certification Authorities WebTrust Principles and Criteria for Certification
> > Authorities - SSL Baseline with Network Security”. However, for the sake of
> > coherence, it was not possible to consider such statement but after
> > finishing the audit. 
> > 
> > It will be included the following text:
> > 
> > FNMT-RCM conforms to the current version of the Baseline Requirements for
> > the Issuance and Management of Publicly-Trusted Certificates published at
> > https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf. In the event of any
> > inconsistency between this document and those Requirements, those
> > Requirements take precedence over this document. 
> > 
> > We remain at your disposal for any further clarification concerning this
> > topic.
> 
> 
> Please clarify if you intend to add that statement to the CP/CPS, or if you
> are saying it will be part of the audit statement only.
> 
> For reference, I asked in the discussion forum about having the BR
> commitment to comply in the audit statement only:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wsw2G-PFKiA/
> akU0bhzN8MMJ
> It looks to me like the answer will be that it needs to be in the CP/CPS.
> You are welcome to participate in that discussion.

Dear Kathleen,

The following statement will be added in the next version of the CP/CPS:

"The FNMT-RCM manages its certification services and issues certificates in accordance with the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” established by the CA/Browser Forum and which can be consulted in the following link: https://cabforum.org/baseline-requirements-documents/

The FNMT-RCM shall review its certification policies and practises in order to keep them in line with the referred requirements. In light of the publication of new versions of that document of requirements, The FNMT-RCM shall act diligently to address any deviation or, where appropriate, notify in this document any incurred noncompliance."

Best regards.
Thank you for the clarification.

Here's the current status of this request...

Needed to complete the Information Verification phase:
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

1) Audit statement (e.g. WebTrust for CA or ETSI 102 042) that covers SSL and Code Signing certs

2) BR Commitment to Comply in CP/CPS
Whiteboard: Information incomplete -- Coment #115 → Information incomplete -- Coment #137
(In reply to Kathleen Wilson from comment #137)
> Thank you for the clarification.
> 
> Here's the current status of this request...
> 
> Needed to complete the Information Verification phase:
> https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
> 
> 1) Audit statement (e.g. WebTrust for CA or ETSI 102 042) that covers SSL
> and Code Signing certs
> 
> 2) BR Commitment to Comply in CP/CPS

Dear Kathleen,
 
Regarding the audit statement, we strongly believe that there are major overlaps between the “WebTrust Principles and Criteria for Certification Authorities Version 2.0” and the “WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2.0” and such issue should be clarified in the Mozilla CA Certificate Policy. We understand that under the Mozilla’s own criteria, both document's requirements must be satisfied. However, we think this is not the most efficient way to handle it because of the extra cost and time that CA's management need to budget to engage duplicate reporting of the same controls. We kindly ask you for some clarification of this situation to the industry, CPA Canada and users, because we did not find any reference about it and many of us have serious doubts in that respect. 

Having said this, we have developed a compliance matrix (CA + SSL BR) for this client and indeed all the requirements have been satisfied and we have evidences about this assertion. Please let us know how to go ahead.

We remain at your disposal for any further clarification concerning this topic. 

Best regards.
(In reply to Antonio from comment #138)
> Having said this, we have developed a compliance matrix (CA + SSL BR) for
> this client and indeed all the requirements have been satisfied and we have
> evidences about this assertion. Please let us know how to go ahead.

Please see item #2 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
(In reply to Kathleen Wilson from comment #139)
> Please see item #2 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices

Hi Kathleen,

on this issue, item #2 says:

"If you provide the information yourself (e.g., it is hosted on your own web site), please provide us with contact information for the auditor (or other third party)."

So, if we publish at our web site a self-statement and we also provide the auditor's contact information, could be enough to meet Mozilla's requirements?
(In reply to Rafa from comment #141)
> (In reply to Kathleen Wilson from comment #139)
> > Please see item #2 of
> > https://wiki.mozilla.org/CA:
> > Information_checklist#Verification_Policies_and_Practices
> 
> Hi Kathleen,
> 
> on this issue, item #2 says:
> 
> "If you provide the information yourself (e.g., it is hosted on your own web
> site), please provide us with contact information for the auditor (or other
> third party)."


That is referring to the auditor's statement. If the auditor's statement is published or provided by the CA, then I do a separate process to contact the auditor to confirm the authenticity of the auditor's statement.


> 
> So, if we publish at our web site a self-statement and we also provide the
> auditor's contact information, could be enough to meet Mozilla's
> requirements?

No. A self-statement does not help. 
We need audit statement(s) that meet the requirements of sections 11 through 14 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
(In reply to Kathleen Wilson from comment #142)

> No. A self-statement does not help. 
> We need audit statement(s) that meet the requirements of sections 11 through
> 14 of
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy/inclusion/

Hi Kathleen.

Regarding this question, we have published at our website an Audit Report from auditor. Within this document you can see contact information for the auditor.

It can be downloaded from:
- https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf (english)
- https://www.cert.fnmt.es/documents/11601/4379265/auditReport_es.pdf (spanish)

I think there are no more pending questions.
The Root Cert URL, http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt, now points to the SHA-256 root, so I updated the technical details about the root cert in SalesForce. Please confirm that the information in the attached document is correct. 

Also, due to the frequency of OCSP errors being found during the discussion phase we have added a check for CAs to address these issues before their request goes to the discussion phase, using the http://certificate.revocationcheck.com/ website.

When I entered https://www.sede.fnmt.gob.es/certificados into the revocation checker the following OCSP errors were listed. Please comment in this bug when these have been resolved.

http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
- bad signature on embedded certificate
- OCSP response expired
- NextUpdate happens before the date in the Expires cache header
- Error parsing OCSP response
Attachment #8549906 - Attachment is obsolete: true
Whiteboard: Information incomplete -- Coment #137 → Information incomplete -- Coment #144
(In reply to Kathleen Wilson from comment #144)
> > 
> When I entered https://www.sede.fnmt.gob.es/certificados into the revocation
> checker the following OCSP errors were listed. Please comment in this bug
> when these have been resolved.

Two days ago we have updated our OCSP Server configuration and we have solved OCSP related bugs.
I just tried it again: http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
returns: Error parsing OCSP response: asn1: structure error: tags don't match (16 vs {class:0 tag:28 length:72 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 set:false omitEmpty:false} responseASN1 @2
(In reply to Kathleen Wilson from comment #146)
> I just tried it again:
> http://certificate.revocationcheck.com/www.sede.fnmt.gob.es
> returns: Error parsing OCSP response: asn1: structure error: tags don't
> match (16 vs {class:0 tag:28 length:72 isCompound:true}) {optional:false
> explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0
> set:false omitEmpty:false} responseASN1 @2

This problem it's not an OCSP Server problem. As you can see, POST request are resolved correctly.

The type GET requests with certain special characters in the base 64 encoding (+, /, ..) with special meaning in URIs must be encoded first with "URL encoding" before sending, according to RFC 2560, and RFC 6960 A.1.1 point point A.1. However, they are not doing, as seen in the logs of our web server.

Specifically, the parsing error occurs because when treating the wrong GET request our OCSP Server sends a redirect to a welcome page, which logically cause the OCSP response parsing error.

You can see the same behaviour if you check other SSL certificates issued by other root CAs inluded in Mozilla root CA Program.
Analyzing the raw data (by clicking in "Raw data" button at the top right of page), we can see that the OCSP GET Request for subordinate CA contains special characters (two '+' symbols) that should be encoded properly (URL encoding).

I attach copy&paste raw data of OCSP request (PEM encoded):

-----BEGIN OCSP REQUEST-----
MEIwQDA+MDwwOjAJBgUrDgMCGgUABBS634rj9+tQjJTBuuMefNw6cT1ENwQUFBHi
tSu5jJitaNMxVEDkWF8DG30CAQI=
-----END OCSP REQUEST-----
Attached file 435736-CAInformation-Final.pdf (obsolete) —
I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

In the meantime, please clarify your audit plans for 2015.

My current notes have...
WebTrust CA Audit (5/4/2014): https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf
WebTrust BR Audit (12/3/2014): https://cert.webtrust.org/SealFile?seal=1784&file=pdf
Whiteboard: Information incomplete -- Coment #144 → Ready for Public Discussion
(In reply to Kathleen Wilson from comment #150)
> I will try to start the discussion soon.
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
> 
> In the meantime, please clarify your audit plans for 2015.
> 
> My current notes have...
> WebTrust CA Audit (5/4/2014):
> https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf
> WebTrust BR Audit (12/3/2014):
> https://cert.webtrust.org/SealFile?seal=1784&file=pdf

We will start audit tasks next october. We hope to have renewed seal on november 2015.

In addition, we have got the ETSI TS 101 456 V1.4.3 seal this August 2015 (http://www.cert.fnmt.es/documents/11601/5161307/ETSI_101_456.pdf). 

The audit tasks for renewal of ETSI seal will be done on 2T of 2016 so we almost will be on a continous audit process.
Attachment #8644041 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from FNMT to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit. 

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “FNMT Root Inclusion Request”.

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

A representative of FNMT must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Ready for Public Discussion → In public discussion
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://www.sede.fnmt.gob.es/certificados'

Using certificate from local file 'ACRAIZFNMT.cert'

    /C=ES/O=FNMT-RCM/OU=sede electr\xC3\xB3nica/OU=SEDE ELECTRONICA FNMT-RCM/serialNumber=Q2826004J/CN=www.sede.fnmt.gob.es
        Notice
            O could be encoded as PrintableString
            OU could be encoded as PrintableString
            CN could be encoded as PrintableString
        Informational
            No checks for DirectoryName
            TLS Server certificate identified
        Warning
            Unable to check unicode normalization of certificate policy explicit text
        Error
            BR certificates with organizationName must include either localityName or stateOrProvinceName
            BR certificates may not contain DirName type alternative names

...

    /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM
        Notice
            O could be encoded as PrintableString
            OU could be encoded as PrintableString
        Informational
            CA certificate identified
        Error
            CA certificates must include commonName in subject
~~

Please add a comment in this bug when the errors have been resolved.
(In reply to Kathleen Wilson from comment #155)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/
(In reply to Kathleen Wilson from comment #155)
>         Error
>             CA certificates must include commonName in subject
> ~~

We have a question regarding this Error.

In "CA-Browser-Forum-BR-1.3.2" doc, at section 7.2.1 it's said:

"The Certificate Subject MUST contain the following:
‐ countryName (OID 2.5.4.6). This field MUST contain the two‐letter ISO 3166‐1 country code for the
country in which the CA’s place of business is located.
‐ organizationName (OID 2.5.4.10). This field MUST contain the name (or abbreviation thereof),
trademark, or other meaningful identifier for the CA, provided that they accurately identify the CA.
The field MUST NOT contain exclusively a generic designation such as “Root 1”."

Nothing is said about any commonName in subject nor that that field is required.
Also, regarding the error "BR certificates must not contain directoryName type alternative name", it has been discussed yet at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7wIZmwp4qGQ.

As it was commented, our certificates are compliant with this requirement as we set the Domain Name (there is at least a DNSName). Also, in order to comply with all applicable law related to eGovernment and identification of eOffices, administrative ID info must be set at SAN extension. As stating at section 8 of BRs we are oblied to do so.

Even if you look at CABForum EV Guidelines (9.2.2), about Subject Alternative Name it is just said:
 "This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates.

You'll agree that this is a less restrictive assertion (and it's about EV certificates wich are more sensitive and requirements are harder) and it should be taken into account.

I suggest to change the error message to a warning in order to allow CAs to explain its especial circumstances.
(In reply to Rafa from comment #157)
> (In reply to Kathleen Wilson from comment #155)
> >         Error
> >             CA certificates must include commonName in subject
> > ~~
> 
> We have a question regarding this Error.
...
> Nothing is said about any commonName in subject nor that that field is
> required.

Yes - we've confirmed that it isn't required for inclusion in Mozilla's program. I updated cert-checker to make this a notice rather than an error.
(In reply to Rafa from comment #158)
> Also, regarding the error "BR certificates must not contain directoryName
> type alternative name", it has been discussed yet at
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/
> 7wIZmwp4qGQ.
> 


I started a discussion about these certlint tests in mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ
Issues that require further discussion should be moved there, so that others may contribute to the discussion/decision, I will be able to refer people to the decisions later, and the results will benefit everyone who is now required to run these tests.

I moved the discussion about
 Error
   BR certificates with organizationName must include either localityName or stateOrProvinceName
   BR certificates may not contain DirName type alternative names

to mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/fQm2VYb4AAAJ
Depends on: 1263949
Attached file 2016 ETSI Seal (obsolete) —
Attached file 2016 Browser audit Attestation (obsolete) —
Attachment #8775143 - Attachment mime type: text/html → application/pdf
Attachment #8775145 - Attachment mime type: text/html → application/pdf
Here's a summary of the audit information that has been provided, and the intermediate certs that have been revoked (to be added to OneCRL).

WebTrust CA audit statement from PricewaterhouseCoopers dated May 18, 2016
https://bug435736.bmoattachments.org/attachment.cgi?id=8766584
Root certificates covered: FNMT-RCM Root CA
Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos”

WebTrust BR audit statement from PricewaterhouseCoopers dated May 18, 2016
https://bug435736.bmoattachments.org/attachment.cgi?id=8766583
Root certificates covered: FNMT-RCM Root CA
Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos”

ETSI TS 101 456 audit certificate from TUVIT dated 2016-06-21
https://bug435736.bmoattachments.org/attachment.cgi?id=8775143
Root certificates covered: OU=AC RAIZ FNMT-RCM
Intermediate certificates covered:
CN = AC Administracion Publica
CN = AC FNMT Usarios
CN = AC Representacion

Audit Attestation by TUVIT
https://bug435736.bmoattachments.org/attachment.cgi?id=8775145
Root certificates covered: OU=AC RAIZ FNMT-RCM
“The assessment covered the period from May 6, 2015 until May 4 2016. It was verified that the CA’s “AC FNMT Usuarios” and “AC Representacion” don’t issue SSL/TSL certificates”

Subordinate CAs revoked and to be added to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1263949
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 8A:8E:8D:48:BC:44:F7:9D:80:67:F8:0F:14:1E:C5:A0:A9:97:99:D5
  sha256 hash: FD:01:90:1F:E7:C4:F5:14:D6:36:DF:64:C0:74:4A:A4:02:9D:B9:16:A3:6F:28:47:4C:84:0E:68:07:93:6A:1E
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 24:F1:1E:3F:73:DE:D8:92:D4:F0:E3:3B:8A:8F:5A:A5:21:88:A3:C2
  sha256 hash: 0D:4C:32:4B:B0:B0:08:F4:5E:EC:73:8B:8E:51:B3:7D:25:0F:76:F0:5F:6A:0C:30:13:66:10:20:A2:07:25:65
subject: C=ES, O=FNMT-RCM, CN=ISA CA
  sha1 hash: 5E:7F:EE:F9:4C:1F:C5:C6:A2:34:46:8C:89:6B:5D:BA:CA:05:97:69
  sha256 hash: 05:2B:EB:BD:CD:5C:84:7B:FA:0F:6F:B0:EA:22:46:B5:5B:A9:EE:55:E0:2A:2D:48:0B:87:FC:2F:34:2C:84:43
subject: C=ES, O=FNMT-RCM, OU=AC APE
  sha1 hash: 35:EC:75:F8:81:25:03:39:D1:52:5F:EB:0E:23:44:BC:DE:7A:5A:5C
  sha256 hash: C0:81:EA:C7:B9:80:7B:70:BD:DC:AC:13:1F:07:B6:67:E4:D9:DE:7F:56:8C:43:BA:01:11:13:A1:E7:53:48:99
subject: C=ES, O=FNMT-RCM, CN=EU ISA CA
  sha1 hash: 7C:C6:1C:DE:A5:7E:02:6E:2D:A5:C3:C7:66:01:39:A6:6E:AC:80:DE
  sha256 hash: BF:1C:7E:BA:A0:AC:08:9C:16:DD:C7:EA:03:88:D8:3F:47:21:DD:86:2F:E8:71:5E:19:BA:07:82:AE:D1:46:FE
subject: C=ES, O=FNMT-RCM, CN=EU ISA CA
  sha1 hash: B5:CF:1B:22:8A:1A:A3:93:84:3A:C8:02:AB:F9:58:A1:A5:5F:DF:ED
  sha256 hash: 69:9C:E8:E2:05:65:1E:F4:8B:03:85:33:15:AE:48:2C:A0:4B:F2:B3:E2:D9:B5:A5:EF:08:E8:CB:13:86:9B:B6
The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

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

Inclusion Policy Section 4 [Technical].
I am not aware of instances where Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
FNMT appears to provide a service relevant to Mozilla users. It provides services to Spain as a national CA. 

Root Certificate Name: AC RAIZ FNMT-RCM
O From Issuer Field: FNMT-RCM
Trust Bits: Websites
EV Policy OID(s): Not EV
Root Certificate Download URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

CA Document Repository: 	https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
CP: https://www.sede.fnmt.gob.es/documents/11614/67070/dpc_componentes_english.pdf/
CPS: https://www.sede.fnmt.gob.es/documents/11614/137578/dpc_english.pdf/
Updated CPS attached to bug February 2015:
https://bug435736.bugzilla.mozilla.org/attachment.cgi?id=8565442

Certificate Revocation
OCSP URL(s): 
http://ocspape.cert.fnmt.es/ocspape/OcspResponder
http://ocspap.cert.fnmt.es/ocspap/OcspResponder

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

* SSL Verification Procedures: According to section 6.1.3 of dpc_componentes_english.pdf, if the Certificate is associated with one or more Internet domains, the Registry Office will check, on the authorized domain registrars' databases, that the title holder of the domain and the Certificate Subscriber match, and will keep proof of the inquiry.

* EV SSL Verification Procedures: Not requesting EV treatment
* Email Verification Procedures: Not requesting Email trust bit
* Code Signing Subscriber Verification Procedure: Not requesting Code Signing trust bit

Inclusion Policy Sections 11-14 [Audit]. 
See Comment #165 for details about FNMT's audits.

Inclusion Policy Section 18 [Certificate Hierarchy]
There are internally-operated subCAs in this CA hierarchy, and there is no plan to allow for externally-operated subCAs. The internally-operated subCAs are as follows:
+ AC Administración Pública
     - Issues: SSL certs, QCP certs
     - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456
+ AC Componentes Informáticos
     - Issues: SSL certs
     - Audits: WebTrust for CAs, WebTrust SSL BRs
+ AC FNMT Usuarios
     - Issues: issues QCP certs, not restricted by EKU extension
     - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of non-existence of SSL certs
+ ISA CA - revoked, being added to OneCRL via Bug #1263949
+ AC APE - revoked, being added to OneCRL via Bug #1263949

Based on this assessment I intend to approve this request from FNMT to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.
Whiteboard: In public discussion → Pending Approval
As per the summary in Comment #166, and on behalf of Mozilla I approve this request from Fábrica Nacional de Moneda y Timbre (FNMT) to included the following root certificate:

**  “AC RAIZ FNMT-RCM” (websites)

I will file the NSS bug for the approved change.
Whiteboard: Pending Approval → Approved, Pending NSS Changes
Depends on: 1299951
I have filed bug #1299951 against NSS for the actual change.
Per Comment #166:

The following is an example of a certificate that FNMT has misissued: https://crt.sh/?id=13283681 (SHA-256 hash e5757f28a974675950fd2f76b7633811c86f60b6528644ec1dc81a7465980a7f )

.gc is not an IANA-delegated ccTLD or ICANN-contracted gTLD, therefore, it is an intranet domain.

Per the Baseline Requirements:
the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates

This certificate was issued on Feb 9, 2016 with an expiration of Feb 9, 2018
The (old) CA that issued that certificate was remove from this inclusion request  -> Comment #98
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: Approved, Pending NSS Changes → In NSS 3.28.1, Firefox 51
If this issue is resolved, then why is this still happening:
https://www.ssllabs.com/ssltest/analyze.html?d=correo.uhu.es

FNMT-RCM is already in:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport


https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.28.1_release_notes

The following CA certificates were Added
OU = AC RAIZ FNMT-RCM
SHA-256 Fingerprint: EB:C5:57:0C:29:01:8C:4D:67:B1:AA:12:7B:AF:12:F7:03:B4:61:1E:BC:17:B7:DA:B5:57:38:94:17:9B:93:FA
(In reply to Alex from comment #171)
> If this issue is resolved, then why is this still happening:
> https://www.ssllabs.com/ssltest/analyze.html?d=correo.uhu.es
> 

That site (https://correo.uhu.es) doesn't provide the full certificate chain. In other words, it doesn't provide the intermediary CA (AC Componentes Informáticos) used to issued his certificate.

As said by cor-el [1]:

"Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage. If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet."

You can check it by visiting this web:

https://www.edu.xunta.es/webmail/

before https://correo.uhu.es. Then you shouldn't see any unknown issuer warning.

About ssllabs.com/ssltest, it seems that they don't follow Firefox release schedule. [2]

[1] https://support.mozilla.org/es/questions/1021610#answer-632157
[2] https://community.qualys.com/thread/15629#comment-36145
The first problem, is that "AC Componentes Informáticos" use SHA1 signing algo, and Mozilla dropped since the beginning of this year, i dont know if was dropped in all channels or only on dev/nightly for now.

About Cert Chain, yes, correo.uhu.es (My old campus, amazing)server is bugged.
(In reply to Theliel from comment #173)
> The first problem, is that "AC Componentes Informáticos" use SHA1 signing
> algo, and Mozilla dropped since the beginning of this year, i dont know if
> was dropped in all channels or only on dev/nightly for now.

Here with Firefox 51 works, so it seems that Firefox still allows SHA1 signing in the cert chain.

But, as you said, it's going to be a problem in a short time. [1]

[1] https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/
As noted in the Release Notes of Firefox 52.0 [1], released March 7, 
'Display (but allow users to override) an “Untrusted Connection” error when encountering SHA-1 certificates that chain up to a root certificate included in Mozilla’s CA Certificate Program.'

So, it applies to all certs that have "AC Componentes Informáticos" in the cert chain.

Untrusted Connection error with code: "SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED" is expected on all websites that have certs like https://www.edu.xunta.es/webmail/ (referenced before). Users may feel they have the same error like before Firefox 51.0.

The only and unique version of Firefox where certs like this one works, is 51.0, released January 24, which was updated to NSS 3.28.1.

[1] https://www.mozilla.org/en-US/firefox/52.0/releasenotes/

(Websites that have certs with "AC Administración Pública" in the cert chain ARE NOT impacted, as "AC Administración Pública" is signed with SHA-256. Example: https://sede.educacion.gob.es/ )
Product: mozilla.org → NSS
Attachment #8775143 - Attachment is obsolete: true
Attachment #8775145 - Attachment is obsolete: true
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.