FNMT Root Inclusion Request

[Kathleen Wilson]

FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate and
enable the Websites trust bit.

Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency that
provides services to Spain as a national CA.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=435736

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8677034

Noteworthy points:

* Documents are in Spanish, and some are translated into English.

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/

* CA Hierarchy

** This root has internally-operated subordinate CAs
- “AC Componentes Informáticos” issues certificates for SSL Servers and
code signing.
- "AC Administración Pública" is an updated version of the “APE CA” in
order to meet new requirements from Spanish Government about
certificates of Public Administrations.
- “APE CA” is no longer used.

* This request is to enable the Websites trust bit.

** From dpc_componentes_english.pdf…

*** Section 5.3.2.1, item 43: Checking the identity and particulars of
the Certificate Applicant and the Subscriber and/or its Representative,
and obtaining the representation that the Applicant is authorized by the
Subscriber to file the application. ... Identification will be
implemented through acceptable electronic signature certificates and the
functionalities established in respect of the DNId [electronic ID
document] for the above-mentioned purposes.

*** Section 5.3.2.2, item 48: As regards management of the lifecycle of
Component Certificates, FNMT-RCM is the only authorized Registry Office,
through its Registry Area. ... To check that the domain title holder's
name matches the Subscriber's identity or, if appropriate, to obtain the
Subscriber's authorization, which will be associated with the Component
Certificate, using the means within its reach that, reasonably, make it
possible to prove the title, according to the state of technology.

*** Section 6.1.3 item 66: The Registry Office will verify the
Subscriber's personality and, if appropriate, the Representative's
personality and capacity, through verification of the Electronic
Signatures and Certificates used in the process and/or inquiry on the
databases of the Companies Register or of trustworthy third parties.

*** Section 6.1.3, item 65: 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 Policy OID: Not applicable; not requesting EV treatment.

* Root Cert URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt

* Test Website: https://www.sede.fnmt.gob.es/certificados

* CRL
ldap://ldapape.cert.fnmt.es/CN=CRL164,CN=AC%20Administraci%F3n%20P%FAblica,OU=CERES,O=FNMT-RCM,C=ES?certificateRevocationList
ldap://ldapfnmt.cert.fnmt.es/CN=CRL,OU=AC%20RAIZ%20FNMT-RCM,O=FNMT-RCM,C=ES?authorityRevocationList;

* OCSP
http://ocspape.cert.fnmt.es/ocspape/OcspResponder
http://ocspap.cert.fnmt.es/ocspap/OcspResponder

* Audit: FNMT is audited annually by PWC according to the WebTrust CA
and WebTrust BR criteria. I exchanged email with the auditor to confirm
the authenticity of the audit statement at this URL:
https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf

* Potentially Problematic Practices -- None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from FNMT to include the “AC
RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Charles Reiss]

On 10/21/15 19:17, Kathleen Wilson wrote:
> FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate and enable
> the Websites trust bit.

[snip]

> * CA Hierarchy
>
> ** This root has internally-operated subordinate CAs

> - “AC Componentes Informáticos” issues certificates for SSL Servers and code
> signing.
> - "AC Administración Pública" is an updated version of the “APE CA” in order to
> meet new requirements from Spanish Government about certificates of Public
> Administrations.
> - “APE CA” is no longer used.

What are the apparent subCAs with CNs 'AC FNMT Usuarios'
[https://crt.sh/?caid=6664 ] and 'ISA CA' [https://crt.sh/?caid=947 (example EE
cert: https://crt.sh/?id=8983568 )]?

[alm...@gmail.com]

'AC FNMT Usuarios' are for individuals.

'ISA CA' are for staff working for the European Commission or any institution or Agency of the European Union.

[Charles Reiss]

I notice that the audit report Kathleen linked to explicitly mentions the other
CAs ("the Delegated Certification Authorities; 'CA Administración Pública' y 'CA
Componentes Informáticos'" [sic]) but not these CAs. Is there a reason for that?

https://www.sede.fnmt.gob.es/documents/11614/67070/dpcec_english.pdf appears to
be translated CPS for the ISA CA sub-CA. For server certificates, this document
says:

12.2.2.1.3.381:
FNMT – RCM shall check, through the information systems that the Local
Registration Authority Officer (LRA Officer) authorised for each case have
available to them, that the domain name or IP address to include in the Web
Server Certificate is owned by the applicant Organization or Competent Body. In
the event that that such a check is not possible, __the FNMT-RCM shall accept
the Organization or Competent Body’s ownership over said names or addresses on
the basis of the corresponding application__.

[emphasis added]

I don't think that last option ("accept [...] on the basis of the corresponding
application") is acceptable for verifying domain name or IP address ownership
under the BRs.

(It's also not clear to me what the other option ("check, through the
information systems [...], that the domain name or IP address [..] is owned")
actually entails. I'd hope it means checking the registrar's databases...)

[raf...@gmail.com]

El miércoles, 21 de octubre de 2015, 22:43:15 (UTC+2), Charles Reiss escribió:

"AC FNMT Usuarios" is the subCA that issues qualified certificates exclussively for natural persons (Spanish citizens). This subCA started operations on february 2015.

Regarding "ISA CA", the European Commission awarded the FNMT-RCM Company a contract for PKI services within the scope of European Public Administration (ISA Program). This subCA issues certificates exclusively within that scope and only for the specified EU Institutions entitled by the European Commission to request ISA SSL certificates.

All of the active server certificates have been issued for domains under:
- testa.eu for STESTA net. (STESTA is the European Community's own private network, composed of the EuroDomain backbone and Local Domain networks.The EuroDomain is totally isolated from the public Internet. This guarantees restricted access as only administrations may access the EuroDomain. Security is also enhanced by the implementation of IPSEC technology to prevent eavesdropping and advanced encryption mechanisms.)
- europa.eu which holds internal services of EU public administrations.

Both, europa.eu and testa.eu are domains property of the European Comission itself as you can verify at http://www.eurid.eu.

The server certificate that you refer (https://crt.sh/?id=8983568) is the only exception. "ec.fnmt.es" is a domain property of FNMT-RCM that just holds the portal for accesing ISA CA products and services.

The reasons why this subCAs don't figure in request are:
- "AC FNMT Usuarios" doesn't issue server certificates
- ISA CA server certificates are issued exlusively to a very restricted (almost private) environment

[Charles Reiss]

Since its subCA certificate is technically capable of having server
certificates chaining through it (there's no extendedKeyUsage extension that
would prevent this), under section 8 of Mozilla's certificate policy and section
8.1 of the BRs, it must be publicly disclosed and audited.

> - ISA CA server certificates are issued exlusively to a very restricted
> (almost private) environment

Again, based on its subCA certificate, the ISA CA is clearly required to be
publicly disclosed and audited under Mozilla's policy and the BRs.

My concern is not that it has been used to misissue certificates in the past,
but that lax domain/IP control validation procedures may allow mistakes in the
future.

It is fine to operate restricted subCAs like this (many commercial CAs seem to
do it for large organizations), but since they are capable of producing publicly
trusted certificates, they must follow the same standards as if they were
issuing certificates for the general public.

[Matt Palmer]

On Mon, Oct 26, 2015 at 08:57:15AM -0700, raf...@gmail.com wrote:
> The reasons why this subCAs don't figure in request are:
> - "AC FNMT Usuarios" doesn't issue server certificates

> - ISA CA server certificates are issued exlusively to a very restricted (almost private) environment

Unless there are technical constraints on the intermediate CA certificates
representing those subCAs which make it impossible for them to issue TLS or
S/MIME certificates, they are in-scope for this inclusion request, because
they are a potential source of misissuance which puts users of the Mozilla
trust store at risk.

- Matt

[Erwann Abalea]

Le mercredi 21 octobre 2015 21:18:26 UTC+2, Kathleen Wilson a écrit :
> FNMT has applied to include the "AC RAIZ FNMT-RCM" root certificate and
> enable the Websites trust bit.

[...]

> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=435736

[...]

> 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/

>From 31/10/2012, the CPS states that end-entity certificates are valid for a maximum of 3 years.
However, https://crt.sh/?id=8983568 shows a TLS server certificate valid for 4 years and delivered in 2015.

> * CA Hierarchy
>
> ** This root has internally-operated subordinate CAs
> - "AC Componentes Informáticos" issues certificates for SSL Servers and
> code signing.
> - "AC Administración Pública" is an updated version of the "APE CA" in
> order to meet new requirements from Spanish Government about
> certificates of Public Administrations.
> - "APE CA" is no longer used.
>
> * This request is to enable the Websites trust bit.
>

> ** From dpc_componentes_english.pdf...

>
>
> * EV Policy OID: Not applicable; not requesting EV treatment.
>
> * Root Cert URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt
>
> * Test Website: https://www.sede.fnmt.gob.es/certificados

The SubjectAlternativeName extension of this certificate contains a directoryName entry, this isn't BR-compliant (see section 7.1.4.2.1 of BR 1.3.1).

Why did you include an anyExtendedKeyUsage OID in the EKU extension, in addition to the serverAuth? Do you also add this OID in non TLS server certificates?

> * CRL
> ldap://ldapape.cert.fnmt.es/CN=CRL164,CN=AC%20Administraci%F3n%20P%FAblica,OU=CERES,O=FNMT-RCM,C=ES?certificateRevocationList
> ldap://ldapfnmt.cert.fnmt.es/CN=CRL,OU=AC%20RAIZ%20FNMT-RCM,O=FNMT-RCM,C=ES?authorityRevocationList;

There's 228 CRLs for this subCA. All are correctly restricted with a critical IssuingDistributionPoints extension. Good luck for OneCRL/CRLSets maintainers.
The LDAP URLs are non compliant, because of not being UTF8 (it's mandatory for LDAP), but I guess this isn't a problem for Mozilla's application. Anyway, any request returns an error because of this UTF8 problem. Change the "%F3" into "%C3%B3" and the "%FA" into "%C3%BA" for the URLs to work.

Looking at the CRLs content shows that a lot of certificates don't have the required 20bits minimum entropy (the serial number is sometimes a monotonic sequence). Did this practice stop? For all Sub-CAs? If yes, when?

> * OCSP
> http://ocspape.cert.fnmt.es/ocspape/OcspResponder
> http://ocspap.cert.fnmt.es/ocspap/OcspResponder

These OCSP responders give a "good" answer for a nonexistent certificate.

[raf...@gmail.com]

Thanks Erwann.

I'll try to answer to your questions.

> However, https://crt.sh/?id=8983568 shows a TLS server certificate valid for 4 years and delivered in 2015.

As already it has been commented, this subCA was developed for a private and restricted environment and it was considered that ISA CA wasn't under the scope of this request. However, as discussed, we have noticed that this SubCA is within the scope of this request. We are currently analyzing all the details to resolve issues related to ISA CA. In the next days we will take a decision about it.

> The SubjectAlternativeName extension of this certificate contains a directoryName entry, this isn't BR-compliant (see section 7.1.4.2.1 of BR 1.3.1).

About the subjectAlternativeName extension the BRs establish that this extension must contain at least a dNSName and our certificates are compliant with this requirement. In fact, you can see several CAs included in Mozilla CA List that set the value of SAN extension similarly as we do in order to comply with regulations related to eGovernment and identification of eOffices.

> Why did you include an anyExtendedKeyUsage OID in the EKU extension, in addition to the serverAuth? Do you also add this OID in non TLS server certificates?

This OID was included for backward compatibility of several information systems widely used on eAdministration.

> Change the "%F3" into "%C3%B3" and the "%FA" into "%C3%BA" for the URLs to work.

Thanks for this info. We have been working in that and we are analyzing several scenarios that guarantee backward compatibility with several old apps.

> Looking at the CRLs content shows that a lot of certificates don't have the required 20bits minimum entropy (the serial number is sometimes a monotonic sequence). Did this practice stop? For all Sub-CAs? If yes, when?

Yes, this practice stopped on December 2011.

> These OCSP responders give a "good" answer for a nonexistent certificate.

Yes, it has been detected and we have been working in this issue for a time. Currently, we plan to solve it within next weeks.

[Erwann Abalea]

Bonsoir,

Le mercredi 28 octobre 2015 14:53:39 UTC+1, raf...@gmail.com a écrit :

> > However, https://crt.sh/?id=8983568 shows a TLS server certificate valid for 4 years and delivered in 2015.
> As already it has been commented, this subCA was developed for a private and restricted environment and it was considered that ISA CA wasn't under the scope of this request. However, as discussed, we have noticed that this SubCA is within the scope of this request. We are currently analyzing all the details to resolve issues related to ISA CA. In the next days we will take a decision about it.

This is another problem. ISA CA MUST be audited and disclosed, as discussed with other participants.
The problem raised here is that the CPS is the root CPS, and this root CPS says that all end-entity certificates are valid for 3 years max. That is, even if ISA CA had been a technically constrained subCA, and as such unaudited, the certificates issued under it should still be limited to 3 years.

> > The SubjectAlternativeName extension of this certificate contains a directoryName entry, this isn't BR-compliant (see section 7.1.4.2.1 of BR 1.3.1).
> About the subjectAlternativeName extension the BRs establish that this extension must contain at least a dNSName and our certificates are compliant with this requirement.

What you're describing is the EV Guidelines, section 9.2.2: "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."

BR, section 7.1.4.2.1 says: "Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server." There's no other alternative.

> In fact, you can see several CAs included in Mozilla CA List that set the value of SAN extension similarly as we do in order to comply with regulations related to eGovernment and identification of eOffices.

That should be raised as a noncompliance, then.

> > Why did you include an anyExtendedKeyUsage OID in the EKU extension, in addition to the serverAuth? Do you also add this OID in non TLS server certificates?
> This OID was included for backward compatibility of several information systems widely used on eAdministration.

Do certificates issued under the "AC FNMT Usuarios" CA (for example) also have this OID?

[raf...@gmail.com]

Bon jour Erwann.

>The problem raised here is that the CPS is the root CPS, and this root CPS says that all end-entity certificates are valid for 3 years max. That is, the certificates issued under it should still be limited to 3 years.

I think there is a misunderstanding here. In General Certification Practices Statement (https://www.sede.fnmt.gob.es/documents/11614/67070/dgpc_english.pdf), section 9.3.2, paragraph 139 it's said: "Data Signature Creation and Data Verification Signature of the Electronic Community may be used throughout the lifetime of the certificate that may be up to five years. See each one of the different Particular Certification Practices covered by FNMT-RCM as Certification Services Provider."

Then, particular certification practice documents that apply to subCAs issuing "Website" certificates, limit specifically this period. As you can see, at particular CPS of "AC Administracion pública" and "AC Componentes Informáticos", it's said (respectively):
- "The electronic venue identification Certificates issued by the FNMT-RCM shall have a validity of three (3) years from the moment the Certificate is issued, provided its validity is not terminated. After this period and if the Certificate is still active, it shall expire and whenever the Subscriber wishes to continue using the services of the Certification Services Provide a new one must be issued."
- "The maximum term of validity of Component Certificates is three years as from the time they are issued, provided that their validity does not terminate for the reasons and procedures laid out in the section "Termination of a certificate validity"."

>What you're describing is the EV Guidelines, section 9.2.2: "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."

>From section 3.4.2.1 of https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_3_1.pdf
"7.1.4.2.1. Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. Each.."
As we commented, our certificates are compliant with this requirement as we set the Domain Name. Also, in order to comply with regulations related to eGovernment and identification of eOffices, administrative ID info must be set at SAN extension. Again, we are proceeding as several certification service providers that already have their root certificates included in Mozilla.

>Do certificates issued under the "AC FNMT Usuarios" CA (for example) also have this OID?

Regarding "AC FNMT Usuarios" subCA, server certificates are not issued. This subCA issues certificate only for natural persons (mainly Spanish citizens).

[raf...@gmail.com]

> > These OCSP responders give a "good" answer for a nonexistent certificate.
> Yes, it has been detected and we have been working in this issue for a time. Currently, we plan to solve it within next weeks.

We have already updated "ocspcomp.cert.fnmt.es" config.

So, following the directive of the BRs of CABForum, OCSP responds with a "revoked" answer for non-existent certificates (revocation reason stated as "suspended", suspension date of January 1, 1970, according to syntax of RFC 6960.)

In a few days OCSP reponder "ocspap.cert.fnmt.es" will be updated in the same way (we will inform)

[raf...@gmail.com]

> In a few days OCSP reponder "ocspap.cert.fnmt.es" will be updated in the same way (we will inform)

We have already updated "ocspap.cert.fnmt.es" config.

[Kathleen Wilson]

Thanks to all of you who have contributed to this discussion so far. I
believe that some of the concerns that were raised have been resolved,
and that the remaining open concerns are as follows. Please reply if I
missed any other items that still need to be resolved.

1) This root certificate has subordinate certificates that are not
technically constrained and not audited/disclosed according to sections
8-10 of Mozilla’s CA Certificate Policy. The noted subCAs are "AC FNMT
Usuarios" (doesn't issue server certificates) and “ISA CA” (server
certificates are issued exclusively to a very restricted (almost
private) environment). Unless there are technical constraints on the

intermediate CA certificates representing those subCAs which make it
impossible for them to issue TLS or S/MIME certificates, they are
in-scope for this inclusion request, because they are a potential source

of mis-issuance which puts users of the Mozilla trust store at risk.
References:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions

2) The allowed methods of verifying domain name ownership/control must
be in compliance with section 3.2.2.4 of version 1.3 (or later) of the
Baseline Requirements. Part of what was documented in the translation of
the ISA CA CPS said: “In the event that that such a check is not

possible, __the FNMT-RCM shall accept the Organization or Competent
Body’s ownership over said names or addresses on the basis of the

corresponding application.” It is not clear how this is in compliance
with the allowed domain validation procedures per the Baseline Requirements.
Reference: https://cabforum.org/documents/#Baseline-Requirements


Thanks,
Kathleen

[raf...@gmail.com]

Regarding this issues, we are working to develope an action plan to solve it.

we hope to communicate our action plan soon in this thread.

[raf...@gmail.com]

Hi all.

We have developed a solution plan for this issues.

> I believe that some of the concerns that were raised have been resolved,
> and that the remaining open concerns are as follows. Please reply if I
> missed any other items that still need to be resolved.
>
> 1) This root certificate has subordinate certificates that are not
> technically constrained and not audited/disclosed according to sections
> 8-10 of Mozilla's CA Certificate Policy. The noted subCAs are "AC FNMT
> Usuarios" (doesn't issue server certificates) and "ISA CA" (server
> certificates are issued exclusively to a very restricted (almost
> private) environment). Unless there are technical constraints on the
> intermediate CA certificates representing those subCAs which make it
> impossible for them to issue TLS or S/MIME certificates, they are
> in-scope for this inclusion request, because they are a potential source
> of mis-issuance which puts users of the Mozilla trust store at risk.

We are going to audit in-scope CAs. Finally our FNMT-RCM CAs hierarchy audit scheme will be as follows:

+ AC RAIZ FNMT-RCM
+ 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 Will be revoked in early 2016
+ AC APE No longer used. Will be revoked in early 2016

As you can see, the two subCAs in-scope will be audited ("AC Usuarios) and revoked ("ISA CA"). Also, "AC APE" which is no longer used will be revoked

> 2) The allowed methods of verifying domain name ownership/control must
> be in compliance with section 3.2.2.4 of version 1.3 (or later) of the
> Baseline Requirements.

ISA CA is going to be revoked.

With this audit scheme, the remaining open issues would be solved.

[Kathleen Wilson]

I think this approach is reasonable, because I think the additional
annual audit check to ensure the AC FNMT Usuarios intermediate has not
issued SSL certs meets the intention of Mozilla's Policy and the BRs.

Does anyone see any problems with this approach?

Thanks,
Kathleen

[Kathleen Wilson]

Should I interpret the non-response to mean that everyone is OK with
this approach?

Kathleen

[winpac...@gmail.com]

I think everything is OK here.

[kwi...@mozilla.com]

All, I've been thinking about this request to included FNMT's root certificate that is valid from 2008, has an intermediate cert to be revoked, has a different intermediate cert that would need to have a special type of audit to confirm non-existence of SSL certs, and concerns have been raised (many resolved) in regards to BR compliance and certlint testing.

I am wondering if rather than trying to fit this old cert and CA hierarchy into relatively new requirements, would it be better to ask the CA to create a new, fully BR compliant root certificate?

Then we could proceed with the remainder of the root inclusion process for the new root cert and clean CA hierarchy, and the CA would migrate their customers to the new hierarchy as needed.

I understand this is asking a lot of the CA, so I will appreciate your thoughtful and constructive input on the best way to proceed with FNMT's root inclusion request.

Thanks,
Kathleen

[raf...@gmail.com]

El viernes, 15 de enero de 2016, 13:42:41 (UTC+1), raf...@gmail.com escribió:
> Hi all.
>
> We have developed a solution plan for this issues.
>

> We are going to audit in-scope CAs. Finally our FNMT-RCM CAs hierarchy audit scheme will be as follows:
>
> + AC RAIZ FNMT-RCM
> + 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 Will be revoked in early 2016
> + AC APE No longer used. Will be revoked in early 2016
>

As we committed, we have been working intensively to follow this plan.

We migrated all of our ISA CA's customers and last week this subCA was revoked.

In the next days, "AC APE" will be revoked.

Next month we have date with TÜViT for "AC Administración Pública" and "AC FNMT Usuarios" ETSI auditing.

Currently, after corresponding audit, WebTrust for CAs seal and WebTrust SSL BRs audit report are beeing transacted and we hope to have them available in the coming days.

We migrated all of our ISA CA's customers and last week this subCA was revoked.

In the next days, "AC APE" will be revoked.

Next month we have date with TÜViT for "AC Administración Pública" and "AC FNMT Usuarios" ETSI auditing.

Currently, after corresponding audit, WebTrust for CAs seal and WebTrust SSL BRs audit report are beeing transacted and we hope to have them available in the coming days.

[Andrew Whalley]

> I am wondering if rather than trying to fit this old cert and CA hierarchy into relatively new requirements, would it be better to ask the CA to create a new, fully BR compliant root certificate?
>
> Then we could proceed with the remainder of the root inclusion process for the new root cert and clean CA hierarchy, and the CA would migrate their customers to the new hierarchy as needed.
>
> I understand this is asking a lot of the CA, so I will appreciate your thoughtful and constructive input on the best way to proceed with FNMT's root inclusion request.

I've been giving this quite a lot of thought. One thing that's certainly concerning are the lapses in attention to detail that have been brought to light during the inclusion request process.

The proposal to stand up a new CA is not without merit and could make the audit procedure for FNMT more straight forwarded. Though of course I can't speak for other root store programs, I imagine a clean slate might result in a faster inclusion path for them too, which would also benefit the CA.

However I still hold out some hope that the current proposal could be workable. I'm sorry if I missed it in the thread or bug, what is the rationale that a "AC FNMT Usuarios" doesn't require an ongoing WebTrust SSL BRs audit?

Many thanks,

Andrew

[raf...@gmail.com]

> However I still hold out some hope that the current proposal could be workable. I'm sorry if I missed it in the thread or bug, what is the rationale that a "AC FNMT Usuarios" doesn't require an ongoing WebTrust SSL BRs audit?
>

Hi Andrew.

As specified at CABForum Baseline Requirements documents, these requirements only address certificates intended to be used for autenticating servers accessible through Internet.

Notice that "AC FNMT Usuarios" issues qualified certificates for natural persons (citizens). Therefore, it can't be audited conforming BR requirements because we don't issue SSL certs with this subCA (in fact, we have technical configuration restrictions to prevent SSL certs issuing).

As I mentioned, "AC FNMT Usuarios" only issues "qualified certificates" where ETSI 101 456 audit criteria applies. Nevertheless, because this subordinate CA don't have the EKU extension, according to "CA:BaselineRequirements" document at mozilla wiki, "AC FNMT Usuarios" is "in scope" and it's necessary to perform "procedures to confirm that there are no SSL certificates".

Best Regards,

Rafa

[Andrew R. Whalley]

Hello Rafa,

Thank you for your reply. The background to my question was really about
ensuring ongoing compliance. I believe that an initial audit to verify
that no TLS certificate has ever been issued by "AC FNMT Usuarios", and a
recurring annual audit to confirm that remains so, is acceptable. However,
given the "AC FNMT Usuarios" is technically capable, if the audit ever
comes back inconclusive or if there is ever any doubt that such an audit
could detect any inadvertent issuance, the assumption should be that
miss-issuance has occurred and it would be reasonable to act accordingly.

With that stipulation, I don't have any objections to the roots in question
continuing the Mozilla inclusion process.

Andrew

On Mon, Mar 14, 2016 at 11:00 AM, <raf...@gmail.com> wrote:

> > However I still hold out some hope that the current proposal could be
> workable. I'm sorry if I missed it in the thread or bug, what is the
> rationale that a "AC FNMT Usuarios" doesn't require an ongoing WebTrust SSL
> BRs audit?
> >

> Hi Andrew.
>
> As specified at CABForum Baseline Requirements documents, these
> requirements only address certificates intended to be used for
> autenticating servers accessible through Internet.
>
> Notice that "AC FNMT Usuarios" issues qualified certificates for natural
> persons (citizens). Therefore, it can't be audited conforming BR
> requirements because we don't issue SSL certs with this subCA (in fact, we
> have technical configuration restrictions to prevent SSL certs issuing).
>
> As I mentioned, "AC FNMT Usuarios" only issues "qualified certificates"
> where ETSI 101 456 audit criteria applies. Nevertheless, because this
> subordinate CA don't have the EKU extension, according to
> "CA:BaselineRequirements" document at mozilla wiki, "AC FNMT Usuarios" is
> "in scope" and it's necessary to perform "procedures to confirm that there
> are no SSL certificates".
>
> Best Regards,
>
> Rafa

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[kwi...@mozilla.com]

I believe there is consensus that we may proceed with the inclusion of the current AC RAIZ FNMT-RCM root certificate as outlined by Rafa. With the following clarifications / action items:

1) FNMT and Mozilla will need to make sure the revoked intermediate certificates get added to OneCRL.

2) The "AC FNMT Usuarios" intermediate certificate will need to be audited annually to ensure that it never issues TLS/SSL certificates. If the audit ever comes back inconclusive or if there is ever any doubt that such an audit could detect any inadvertent issuance, the assumption should be that miss-issuance has occurred and it would be reasonable to act accordingly.

3) FNMT will work with the CAB Forum to resolve the conflicts between the BRs and the requirements that Spanish CAs must follow (i.e. the certlint errors, https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c160).

Thanks,
Kathleen

[raf...@gmail.com]

> + AC RAIZ FNMT-RCM
> + 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 Will be revoked in early 2016
> + AC APE No longer used. Will be revoked in early 2016

According to the plan, last week "AC APE" subordinate CA was revoked.

[raf...@gmail.com]

Nowadays, the whole hierachy has been completely audited.

We have updated audit reports at: https://bugzilla.mozilla.org/show_bug.cgi?id=435736

[Kathleen Wilson]

>> FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate

>> and enable the Websites trust bit.
>>
>> Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency
>> that provides services to Spain as a national CA.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=435736

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”

Intermediate certificates 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 action items that had resulted from the discussion of this request are as follows.

>> 1) FNMT and Mozilla will need to make sure the revoked intermediate
>> certificates get added to OneCRL.
>>
>> 2) The "AC FNMT Usuarios" intermediate certificate will need to be
>> audited annually to ensure that it never issues TLS/SSL certificates.
>> If the audit ever comes back inconclusive or if there is ever any doubt
>> that such an audit could detect any inadvertent issuance, the assumption
>> should be that miss-issuance has occurred and it would be reasonable to
>> act accordingly.
>>
>> 3) FNMT will work with the CAB Forum to resolve the conflicts between
>> the BRs and the requirements that Spanish CAs must follow (i.e. the
>> certlint errors, https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c160).

I believe that these action items have or are being addressed such that we may move forward with approving FNMT's request to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.

If there are no further concerns then I will close this discussion and recommend approval in the bug.
(https://bugzilla.mozilla.org/show_bug.cgi?id=435736)

Thanks,
Kathleen

[Kathleen Wilson]

On Thursday, August 11, 2016 at 4:36:02 PM UTC-7, Kathleen Wilson wrote:
> >> FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate
> >> and enable the Websites trust bit.
> >>
> >> Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency
> >> that provides services to Spain as a national CA.
> >>
> >> The request is documented in the following bug:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=435736
>

<snip>

> I believe that these action items have or are being addressed such that we may move forward with approving FNMT's request to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.
>
> If there are no further concerns then I will close this discussion and recommend approval in the bug.
> (https://bugzilla.mozilla.org/show_bug.cgi?id=435736)
>

Thanks again to all of you who participated in this discussion about FNMT's request to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit.

I am now closing this discussion and will recommend approval in the bug.

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

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen