FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

All,

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre
(FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the
root store. See
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9).

Mozilla is considering approving FNMT’s request to add the root as a trust
anchor with the websites trust bit and EV enabled as documented in Bugzilla bug
#1559342 .

This email begins the 3-week comment period, after which, if no concerns
are raised, we will close the discussion and the request may proceed to the
approval phase (Step 10).

*A Summary of Information Gathered and Verified appears here in the CCADB:*

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0418

*AC RAIZ FNMT-RCM SERVIDORES SEGUROS* is valid from 12/20/2018 to 12/20/2043

SHA2 Certificate Hash:
554153B13D2CF9DDB753BFBE1A4E0AE08D0AA4187058FE60A2B862B2E4B87BCB

https://crt.sh/?id=1490711558

*Root Certificate Download:*

https://www.sede.fnmt.gob.es/documents/10445900/10526749/AC_Raiz_FNMT-RCM-SS.cer


*CP/CPS:*

https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf

Current CPS is version 1.5, published 1-October-2020.

Repository location:
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion

*2020 BR Self Assessment* (pdf) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9179612

*Audits:*  Annual audits are performed by AENOR Internacional. The most
recent audit was completed by AENOR, for the period ending January 12,
2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
Validation Certificate Policy).
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf
 The audit found “All the minor non-conformities have been scheduled to be
addressed in the corrective action plan of the Trust Service Provider. No
critical non-conformities were identified.”  Remediation of the minor
conformities was discussed in Bug # 1626805
.

*Incident Reports / Mis-Issuances *

*The following bugs/incidents (closed) have been reported. *

Bug 1495507  (filed
10/1/2018) OU field exceeding 64 characters

Bug 1544586  (filed
4/15/2019) 2019 audit findings

Bug 1596949  (filed
11/15/2019) CP/CPS lack CAA processing details

Bug 1626805  (filed
4/1/2020) 2020 audit findings

No misissuances were found under this root, and certificates issued under
it have passed testing.

Revocation checking at
https://certificate.revocationcheck.com/testactivetipo1.cert.fnmt.es
appears to work fine, except there are a few error messages -- "one of the
certificates in the chain could not be checked", "Valid signature but
response includes an unnecessary certificate chain" and "Certificate status
is 'Revoked' expecting 'Unknown'".  Hopefully, these errors can be
explained or remedied. Otherwise, I have no further questions or concerns
at this time.

I urge anyone with any additional concerns or questions to raise them on
this list by replying under the subject heading above.

Pursuant to Step 5 - "A representative of the CA responds to questions and
concerns posted during the public discussion of the CA's request."

Again, this email begins a three-week public discussion period, which I’m
scheduling to close on or about 9-December-2020.



Sincerely yours,

Ben Wilson

Mozilla Root Program
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Jakob Bohm via dev-security-policy]

On 2020-11-16 23:17, Ryan Sleevi wrote:

On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Hi Nils,

This is interesting, but unfortunately, doesn’t work. The 4-certificate
hierarchy makes the very basic, but understandable, mistake of assuming

the

Root CA revoking the SICA is sufficient, but this thread already

captures

why it isn’t.

Unfortunately, as this is key to the proposal, it all falls apart from
there, and rather than improving security, leads to a false sense of it.

To

put more explicitly: this is not a workable or secure solution.


Hello Ryan,

We agree that revoking SICA would not be sufficient and we mentioned that
in section 2.3 in the above message.

The new solution described in section 2.3, not only proposes to revoke
SICA (point (iv)) but also to revoke ICA (point (ii)) in the 4-level
hierarchy (RCA -> ICA -> SICA -> EE).

We believe this makes a substantial difference.



Sorry, I should have been clearer that even the assumptions involved in the
four-certificate design were flawed.

While I do want to acknowledge this has some interesting edges, I don't
think it works as a general solution. There are two critical assumptions
here that don't actually hold in practice, and are amply demonstrated as
causing operational issues.

The first assumption here is the existence of robust path building, as
opposed to path validation. In order for the proposed model to work, every
server needs to know about SICA2 and ICA2, so that it can properly inform
the client, so that the client can build a correct path and avoid ICA /
SICA1. Yet, as highlighted by
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6
, very few libraries actually implement path building. Assuming they
support revocation, but don't support path building, it's entirely
reasonable for them to build a path between ICA and SICA and treat the
entire chain as revoked. Major operating systems had this issue as recently
as a few years ago, and server-side, it's even more widespread and rampant.
In order to try to minimize (but impossible to prevent) this issue is to
require servers to reconfigure the intermediates they supply to clients, in
order to try to serve a preferred path, but has the same operational impact
as revoke-and-replace, under the existing, dominant approach.



Correct, thus most affected EE-certificate holders would still have to
reinstall the certificate configuration for their (unchanged) EE cert,
which is still less work than requesting and getting a new certificate.


The second assumption here is with an assumption on robust CRL support,
which I also hope we can agree is hardly the case, in practice. In order
for the security model to be realized by your proposed 4-tier plan, the
clients MUST know about the revocation event of SICA/ICA, in order to
ensure that SICA cannot spoof messages from ICA. In the absence of this,
the risk is entirely borne by the client. Now, you might think it somehow
reasonable to blame the implementer here, but as the recent outage of Apple
shows, there are ample reasons for being cautious regarding revocation. As
already discussed elsewhere on this thread, although Mozilla was not
directly affected due to a secondary check (prevent CAs from signing OCSP
responses), it does not subject responder certificates to OneCRL checks,
and thus there's still complexity lurking.


Actually, for the current major browsers, the situation is better:

1. Chrome would distribute the revocation of the "ICA" cert in it's
  centralized CRL mechanism.

2. Non-chrome Microsoft Browsers would actually check CRLs and or OCSP
 for the root CA to discover that the ICA cert is revoked.  This would
 be done against the CRL/OCSP servers of the root CA, not those of ICA.

3. Firefox would distribute the revocation of ICA (or any other
  intermediary CA) through its centralized "SubCA revocation" mechanism.






As it relates to the conclusions, I think the risk surface is quite
misguided, because it overlooks these assumptions with handwaves such as
"standard PKI procedures", when in fact, they don't, and have never, worked
that way in practice. I don't think this is intentional dismissiveness, but
I think it might be an unsupported rosy outlook on how things work. The
paper dismisses the concern that "key destruction ceremonies can't be
guaranteed", but somehow assumes complete and total ubiquity for deployment
of CRLs and path verification; I think that is, at best, misguided.
Although Section 3.4 includes the past remarks about the danger of
solutions that put all the onus on application developers, this effectively
proposes a solution that continues more of the same.

As a practical matter, I think we may disagree on some of the potential
positive outcomes from the path currently adopted by a number of CAs, such
as the separation of certificate hierarchies, a better awareness and
documentation