On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
<dev-security-policy@lists.mozilla.org> wrote:
>
> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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).
>
> [...]
>
> *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
>

I'm having trouble finding the end entity certificate profiles in this
CPS. According to the CPS s7.1.2, they are supposed to be available at
http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
[0] of which the only english-language document [1] does not contain
any end entity certificate profiles, but only the root and ICA
profiles in attachments. Similarly, I cannot find the CPS you linked
in their repository.

I noticed that the CPS defers a great amount of sections (section 5,
6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
probably is [1] but that is never explicitly confirmed in the CPS -
there is no explicit link to any repository in section 1.6.1 where the
acronym is defined, nor are there any other indications that this DGPC
is located in the repository under the link of [0]. This is confusing,
and detrimental to the readability of the document.

CPS s4.9.2 and s1.5.2 both mention that third parties may send
certificate problem reports, and select parties may send revocation
requests, which is great; but I cannot find a commitment to
communicating a preliminary report within 24 hours to the reporter as
stipulated by BR 4.9.5.

CPS / DGPC s5.2.2 includes by reference an internal policy, which may
or may not comply with the "at least dual control for CA private key
backup/storage/recovery" requirement of BR 5.2.2.

CPS / DGPC s5.3.1 only guarantee the "experience and knowledge", not
the "trustworthiness and identity" of the operators.

CPS / DGPC s5.3.3 does not provide information on the specific topics
that are SHALL-qualified in BR s5.3.3. This same can be said about
s5.3.4 and s5.3.7.

CPS / DGPC s5.4.1 does definately not mention logging
rejection/acceptance of certificate requests (BR s5.4.1(1)(3)), and
probably also doesn't cover some other parts, but the language is very
opaque (i.e. unclear).
... looks further
... those specific events are apparently included in 5.5.1 Types of
Records Archived (?)

CPS / DGPC s5.4.3 does not comply with BR 5.4.3: Audit log retention
of 15 years is not enough to cover the CA certificate event record log
retention timespan of 2 years past the latest of 1.) the destruction
of the CA private key, and 2.) the revocation or expiration of the
final CA certificate of that private key. Unless of course you expect
to revoke the root and destroy the CA keys within 13 years after
creation.

CPS / DGPC s6.1.1.1 (CA Key Pair Generation) fails to include the
procedure with which CA keys are generated.
More specifically, the current implication is that the auditor could
not be witness of the CA key generation ceremony, nor have seen any
evidence other than the report, and sign this report. This fails to
apply BR 6.1.1.1(1) items 2 and 3, and BR 6.1.1.1(2)(2). The procedure
included by reference is not accessible [3] and may add requirements,
but those requirements need not meet the baseline of the BR.

CPS s6.2 points to a section s6.2 in the DGPC, which is blank.
Therefore, I'm missing the documentation on that the CA is committed
to securing the CA private key material in a BR-compliant manner.

CPS / DGPC s6.2.4 does not apply the requirements of BR 6.2 nor 5.2.2
to their private key backup procedure.

CPS delegates s6.2.5 fully to the DGPC, but that s6.2.5 requires the
CPS to at least specify a maximum number of copies of the private key,
which is not specified.

CPS / DGPC s6.2.6 has the interesting construction "Consequently, the
Keys cannot be transferred, although there is a recovery procedure",
which implies a procedure to extract and transfer keys exists.

CPS / DGPC s6.2.7 fails to commit FNMT to using devices meeting FIPS
140 level 3 or higher (as that is apparently located in DGPC 6.2.1 and
6.2.8 (?))

CPS / DGPC does not mention "factor" or "2fa" according to my search,
even though BR 6.5.2 specifies 'The CA SHALL enforce multi-factor
authentication for all accounts capable of directly causing
certificate issuance.".

... skipped over similar issues in 7: failure to document a commitment
to the relevant sections of the BR
... skipped over similar issues in 8: failure to document a commitment
to the relevant sections of the BR

>
> *2020 BR Self Assessment* (pdf) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9179612

This self-audit mentions the CPS as having version 5.8, while the CP
is at version 1.4.
This makes me believe that the CPS is the document at [1] (which has a
version number of 5.8), while the CP would be the CPS you linked as it
is versioned 1.5. Either way, the document at [1] does not have
documentation on CAA record validation and does not have the same
section number to title mapping as the BR, making it difficult to
parse (and probably a failure to comply with

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

I can continue on with sifting throug this CPS/DGPC combo, but I'd
rather mark this CPS as "returned with feedback" and have them compare
it side-by-side with the BR, and have it at least document their
commitment to each of the baseline requirements explicitly in their
CPS (not by reference "see the corresponding section of the DGPC", as
that is not workable)  at each of the relevant sections. I'm very
concerned with the transparency of this (probably not intentional)
opaque document in a place where transparency is expected. I would
also greatly appreciate a sample end entity certificate profile, as
that is not available in the CPS/DGPC combo.


Enjoy,

-Matthias


[0] 
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
[1] https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf
[2] https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
[3] it is named "Gestión del ciclo de vida de las claves de la
FNMT-RCM como Prestador de Servicios de Certificación y Sellado",
implying a spanish-language procedure, making it not accessible per
the 'english language version of the CPS' requirement of the Mozilla
Root Store.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to