Comment 30 for bug 1271513

 The answer of The FNMT about your questions are:

-- Comment #11 from Kathleen Wilson <email address hidden> 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”.