FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson]

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).

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

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

*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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1626805>.

*Incident Reports / Mis-Issuances *

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

Bug 1495507 <https://bugzilla.mozilla.org/show_bug.cgi?id=1495507> (filed
10/1/2018) OU field exceeding 64 characters

Bug 1544586 <https://bugzilla.mozilla.org/show_bug.cgi?id=1544586> (filed
4/15/2019) 2019 audit findings

Bug 1596949 <https://bugzilla.mozilla.org/show_bug.cgi?id=1596949> (filed
11/15/2019) CP/CPS lack CAA processing details

Bug 1626805 <https://bugzilla.mozilla.org/show_bug.cgi?id=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

[Ben Wilson]

FNMT provided the following clarification regarding its audits:

*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

It is mentioned that the audit was performed according to ETSI EN 319
411-1, but the link is the one for our audit ETSI 319 411-2 for QCP-w; EVCP:
Policy for EU qualified website certificate issued to a legal person and
linking the website to that person

Our root is being audited according to both ETSI EN 319 411-2 and ETSI 319
411-1 since we have 2 dedicated subordinate CA: AC Servidores Tipo 1 - for
EVCP and AC Servidores Tipo 2 - for OVCP

https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

[Matthias van de Meent]

On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
<dev-secur...@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.

[Santiago Brox]

Thank you Matthias for your comments which we have considered with great interest.

After evaluating all these issues, we have decided to create a new CPS version which integrates all the sections that are now referred to in the DGPC and which applied in general to all our CAs. At the same time, we will take the chance to clarify all that aspects you have pointed out.

We agree that it will improve transparency. From version 1.6 our CPS, our CPS will collect in a single document all the information and BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS.
We will then also update our BRs Self-Assessment with this new CPS version and we will be approving and publishing the new CPS version asap.

Santiago.

[Santiago Brox]

El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de Meent escribió:

All the relevant documentation (CPS, PDS, Terms and conditions, certificate profiles, and old versions of CPSs) of each CA is published in its corresponding channel in the website, all of them accessible from:
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion

For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each intermediate CA):
AC SERVIDORES SEGUROS TIPO 1:
https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
and
AC SERVIDORES SEGUROS TIPO 2:
https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2

In regards the certificate profiles, we have included in CPS v1.6 section 7.1.2. direct links to the published documents of profiles.

The document describing the profiles of the Website authentication certificates, including all extensions, are published at
AC SERVIDORES SEGUROS TIPO 1:
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
AC SERVIDORES SEGUROS TIPO 2:
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf

> 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 new version (v1.6) integrates all the sections that were referred to in the DGPC (v5.8) and which applied in general to all our CAs. From version 1.6 our CPS collects in a single document all the information and BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS

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

Detailed information has been included in CPS v1.6 sections 4.9.5. and 5.2.2. following BRs.

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

Our HR selection department and the engagement process guarantees the fulfilment of requirements in BRs 5.3.1, verifying also the trustworthiness and identity of the operators. In addition, the trustworthiness and suitability of assigned trusted roles are reviewed periodically by the TSP Management Committee. We have included more detailed information in this regard in CPS section 5.3.1.

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

We have enclosed further the information in these sections, specifying the topics covered by the FNMT’s Annual Training Plan, the periodicity of its revision and the verification of compliance of the required experience and knowledge in case of hiring independent contractors for trusted duties.

>
> 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 (?)
>

Detailed specification of the events recorded has been included in CPS v1.6 section 5.4.1

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

Spanish Lay 6/2020 establishes the period of time during which we must keep the information regarding the services provided in accordance with article 24.2.h) of Regulation (EU) 910/2014. This will be 15 years from the expiration of the certificate or the end of the service provided. We have specified in CPS section 5.4.3. that records will be kept for at least 15 years after the occurrence of the events indicated in BRs.

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

We confirm that prior to the ceremony day for a CA Key Pair Generation, a Key Generation Script is sent to the qualified auditor who will witness on the agreed day all the process, being then able to confirm in his report the process and the controls used to ensure the integrity and confidentiality of the Key Pair. These details have been specified in our CPS v1.6 section 6.1.1.1.

> CPS s 6.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 v1.6 section 6.2 include now the following statement:
FNMT-RCM protects its Private Key(s) in accordance with the provisions specified in the CPS and in a compliance with CA/Browser Forum's Baseline Requirements

> 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 1.6 section 6.2.4. states now that backup copies of CA Private Keys SHALL be backed up by multiple persons in Trusted Role positions and only be stored in encrypted form on cryptographic modules that meet the requirements specified in Section 6.2.1

> 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 1.6 section 6.2.5. clarifies now that only the FNMT-RCM may make a backup of the Private keys and that the number of data duplicated does not exceed the minimum necessary to assure service continuity. The Signature creation data are not duplicated for any other purpose.

>
> 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 v.1.6 section 6.2.6 has been drawn up as follows “The Certification Authorities’ Private keys are generated as described in point “6.1 Key generation and installation”. In the event that a Private Key is to be transported from one Cryptographic Module to another, the Private Key must be encrypted during transport. Private Keys must never exist in plain text form outside the Cryptographic Module boundary”

> 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 (?))

We have included this reference also in 6.2.7. “Root CA private keys of the FNMT-RCM are generated and stored inside cryptographic modules which meet the requirements of 6.2.1 of this CPS”

>
> 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.".

In CPS v1.5 section 4.3.1. it was mentioned that “ The processes related to the issuance of electronic Certificates guarantee that all the accounts that interact with them include multi-factor authentication.” We confirm it is also applicable under section 6.5.1, and so we have expressly indicated it under such section in CPS v1.6.

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

Sections 7 and 8 have been reviewed and more detailed information has been included in CPS v.1.6 sections 7.1.2, 8, 8.1, and 8.5.

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

We have updated a new BRs Self-Assessment document with CPS v1.6: https://bug1559342.bmoattachments.org/attachment.cgi?id=9189942

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

I hope that we have been able to resolve all the issues raised with this new version of the CPS (1.6) and have gained in transparency.
Thanks
Santiago.

[Matthias van de Meent]

On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
Meent escribió:

> > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > <dev-secur...@lists.mozilla.org> wrote:
> > >
> > > [...]
> > >
> > > *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.
> >

> All the relevant documentation (CPS, PDS, Terms and conditions,
certificate profiles, and old versions of CPSs) of each CA is published in
its corresponding channel in the website, all of them accessible from:
>
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion

I'm sorry, but I'm having trouble finding a link to the latest version of
the CPS of the to-be-included root in that repository. If you add this CPS,
it would be useful to take Mozilla Root Store Policy section 3.3 (6) into
account ("CAs must provide a way to clearly determine which CP and CPS
applies to each of its root and intermediate certificates").

> For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each
intermediate CA):
> AC SERVIDORES SEGUROS TIPO 1:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> and
> AC SERVIDORES SEGUROS TIPO 2:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
>
> In regards the certificate profiles, we have included in CPS v1.6 section
7.1.2. direct links to the published documents of profiles.
>
> The document describing the profiles of the Website authentication
certificates, including all extensions, are published at
> AC SERVIDORES SEGUROS TIPO 1:
>
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> AC SERVIDORES SEGUROS TIPO 2:
>
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>

Thank you for the links, I probably overlooked them before.

> > 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 new version (v1.6) integrates all the sections that were referred to
in the DGPC (v5.8) and which applied in general to all our CAs. From
version 1.6 our CPS collects in a single document all the information and

BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS
> [...]

> I hope that we have been able to resolve all the issues raised with this
new version of the CPS (1.6) and have gained in transparency.
> Thanks
> Santiago.

Thanks for the update, it sounds promising. I'll check it again once I can
find the CPS in the repository.

Regards,

Matthias

[Ben Wilson]

Matthias,
Have you been able to obtain the CPS downloadable from here:
https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or
here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
? (They both lead to the same CPS v. 1.6 document.)
Ben

On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
> Meent escribió:

> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > > <dev-secur...@lists.mozilla.org> wrote:
> > > >
> > > > [...]
> > > >
> > > > *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 new version (v1.6) integrates all the sections that were referred to
> in the DGPC (v5.8) and which applied in general to all our CAs. From
> version 1.6 our CPS collects in a single document all the information and
> BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS
> > [...]
> > I hope that we have been able to resolve all the issues raised with this
> new version of the CPS (1.6) and have gained in transparency.
> > Thanks
> > Santiago.
>
> Thanks for the update, it sounds promising. I'll check it again once I can
> find the CPS in the repository.
>
> Regards,
>
> Matthias

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

[Matthias van de Meent]

Thanks for the pointer, Ben.

I didn't realise that the links in section 'Particulares AC Raíz
FNMT-RCM Servidores Seguros' of their main repository [1] were links
to repositories that would include the applicable CPS... As those
sections seemed to be for ICAs of the root, I didn't consider them as
a source for the CPS of their parent CA. Together with that the CPS
pointers in the certificate profile point to the main repository and
that the QcPDS links in the certificate profiles don't seem to point
to anything, I got lost...

So, sorry for the noise, I was very confused by the structure of the repository.

Now that I know where to look, I'll probably check the contents more
thoroughly sometime in the following weekend, at first glance they
already looked much better.

-Matthias

[1] https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion

On Wed, 2 Dec 2020, 23:44 Ben Wilson, <bwi...@mozilla.com> wrote:
>
> Matthias,
> Have you been able to obtain the CPS downloadable from here:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2 ? (They both lead to the same CPS v. 1.6 document.)
> Ben
>
> On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>> >
>> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
>> Meent escribió:

>> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
>> > > <dev-secur...@lists.mozilla.org> wrote:
>> > > >
>> > > > [...]
>> > > >
>> > > > *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.
>> > >

[Santiago Brox]

Thanks Matthias. We will work with the web content management team to evaluate possible improvements in the distribution of our CPSs site.

[Ben Wilson]

Just a reminder - today, the public discussion period will close and then
I'll be preparing a summary of the discussion. In addition to reviewing
FNMT's response of 27-November, I also reviewed the CPS v. 1.6 and make the
following observations:

Matthias van de Meent wrote:

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 was able to review the end entity certificate profiles at
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
and
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf

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.

I noticed that the acronym "DPPP" has been replaced with "CPS" and that
language from the "DGPC" has been copied into the CPS.

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 section 4.9.5 now states that "Within 24 hours after receiving a CPR,
the CA will investigate the facts and circumstances related to the CPR and
provide a preliminary report to both the Subscriber and the entity who
filed the CPR."

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 section 5.2.2 now states, "The FNMTs Private Key are backed up, stored,
and recovered only by personnel in trusted roles using, at least, dual
control in a physically secured environment."

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

CPS section 5.3.1 now states, "These requirements are guaranteed by the
corresponding criteria in the personnel selection processes, verifying the
identity and trustworthiness of such person and that the employee's
professional profile is as appropriate as possible to the characteristics
of the tasks to be developed. The trustworthiness and suitability of the
assigned trusted roles are reviewed periodically."

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.

As noted by FNMT, these sections now reference its Annual Training Plan,

the periodicity of its revision and the verification of compliance of the
required experience and knowledge in case of hiring independent contractors
for trusted duties.

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 (?)

Subsections a) and b) in section 5.4.1 now mention "Approval and rejection
of certificate requests".

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.

As noted, BR section 5.4.3 only requires retention for two years after
expiration. As now worded in the CPS (with 15-year retention), the BRs are
satisfied.

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 Section 6.1.1.1 now specifies, "Following this procedure, the FNMT-RCM
will prepare and follow a Key Generation Script, have a Qualified Auditor
witness the CA Key Pair generation process, and have a Qualified Auditor
issue a report opining that the CA followed its key ceremony during its Key
and Certificate generation process and the controls used to ensure the

integrity and confidentiality of the Key Pair."

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.

Section 6.2 now states, "FNMT-RCM shall protect its Private Key(s) in
accordance with the provisions of this CPS and in a compliance with

CA/Browser Forum's Baseline Requirements"

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

Section 6.2.4 of the CPS now states, "Backup copies of CA Private Keys
shall be backed up by multiple persons in Trusted Role position sand only

be stored in encrypted form on cryptographic modules that meet the

requirements specified in Section 6.2.1."

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.

Section 6.2.5 now states, "Only the FNMT-RCM may make a backup of the
Private keys, guaranteeing that the security level of the copied data is at
least equal to that of the original data and that the number of data

duplicated does not exceed the minimum necessary to assure service
continuity. The Signature creation data are not duplicated for any other
purpose."

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 Section 6.2.6 now states, "The Certification Authorities’ Private keys

are generated as described in point “6.1 Key generation and installation”.
In the event that a Private Key is to be transported from one Cryptographic
Module to another, the Private Key must be encrypted during transport.
Private Keys must never exist in plain text form outside the Cryptographic

Module boundary."

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
(?))

Section 6.2.7 now states, "Root CA private keys of the FNMT-RCM are

generated and stored inside cryptographic modules which meet the
requirements of 6.2.1 of this CPS"

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.".

Section 6.5.1 now states, "The FNMT-RCM 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

FNMT indicated "Sections 7 and 8 have been reviewed and more detailed

information has been included in CPS v.1.6 sections 7.1.2, 8, 8.1, and 8.5.
"

On Fri, Dec 4, 2020 at 12:40 PM Santiago Brox via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> El viernes, 4 de diciembre de 2020 a las 18:20:41 UTC+1, Matthias van de

> Thanks Matthias. We will work with the web content management team to
> evaluate possible improvements in the distribution of our CPSs site.

[Ben Wilson]

On November 17, 2020, the public discussion period [Step 4 of the Mozilla
Root Store CA Application Process
<https://wiki.mozilla.org/CA/Application_Process>] began on FNMT’s
inclusion request.

*Summary of Discussion and Completion of Action Items [Steps 5-8]:*

On November 18, 2020, FNMT clarified that it is audited to both ETSI EN 319
411-2 and ETSI 319 411-1.

Also, on that day, a comment was received with the following observations:

(1) certificate profiles could not be located for review - as indicated
subsequently in the thread, FNMT provided links to the certificate profiles
for end entity certificates;

(2) cross-references to a document called the “DGPC” were difficult to
follow - an overall comment was that FNMT’s Certification Practices
Statement (CPS) was confusing with its numerous cross-references to its
DGPC (CPS for its Root CA). FNMT republished its CPS with these
cross-references removed and replaced them with applicable text. There
were also references to the "DPPP" (FNMT’s CPS), which were replaced by
“CPS”;

(3) there were numerous observations about the CPS (e.g. it lacked a
commitment to communicate back to third parties within 24 hours of
receiving a Certificate Problem Report, etc.) - see
https://groups.google.com/g/mozilla.dev.security.policy/c/T5bYrPznCXQ/m/Rv4ddGh6BQAJ,
and the subsequent response from FNMT, and my similar summary of these
issues in this thread; and

(4) a final suggestion was “[to] have them compare [the CPS] side-by-side

with the BR, and have it at least document their commitment to each of the

baseline requirements explicitly in their CPS”. FNMT responded, “We have

updated a new BRs Self-Assessment document with CPS v1.6:

https://bug1559342.bmoattachments.org/attachment.cgi?id=9189942”. I
believe that the BR self-assessment serves this purpose.

This is notice that I am closing public discussion [Step 9] and that it is
Mozilla’s intent to approve FNMT's request for inclusion [Step 10].

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

On Wed, Dec 9, 2020 at 12:09 PM Ben Wilson <bwi...@mozilla.com> wrote:

> Just a reminder - today, the public discussion period will close and then
> I'll be preparing a summary of the discussion. In addition to reviewing
> FNMT's response of 27-November, I also reviewed the CPS v. 1.6 and make the
> following observations:
> Matthias van de Meent wrote:
>

> 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 was able to review the end entity certificate profiles at
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> and
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>

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

> I noticed that the acronym "DPPP" has been replaced with "CPS" and that
> language from the "DGPC" has been copied into the CPS.
>

> 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 section 4.9.5 now states that "Within 24 hours after receiving a CPR,
> the CA will investigate the facts and circumstances related to the CPR and
> provide a preliminary report to both the Subscriber and the entity who
> filed the CPR."
>

> 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 section 5.2.2 now states, "The FNMTs Private Key are backed up,
> stored, and recovered only by personnel in trusted roles using, at least,
> dual control in a physically secured environment."
>

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

> CPS section 5.3.1 now states, "These requirements are guaranteed by the
> corresponding criteria in the personnel selection processes, verifying the
> identity and trustworthiness of such person and that the employee's
> professional profile is as appropriate as possible to the characteristics
> of the tasks to be developed. The trustworthiness and suitability of the
> assigned trusted roles are reviewed periodically."
>

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

> As noted by FNMT, these sections now reference its Annual Training Plan,
> the periodicity of its revision and the verification of compliance of the
> required experience and knowledge in case of hiring independent contractors
> for trusted duties.
>

> 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 (?)
>

> Subsections a) and b) in section 5.4.1 now mention "Approval and rejection
> of certificate requests".
>

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

> As noted, BR section 5.4.3 only requires retention for two years after
> expiration. As now worded in the CPS (with 15-year retention), the BRs are
> satisfied.
>

> 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 Section 6.1.1.1 now specifies, "Following this procedure, the FNMT-RCM
> will prepare and follow a Key Generation Script, have a Qualified Auditor
> witness the CA Key Pair generation process, and have a Qualified Auditor
> issue a report opining that the CA followed its key ceremony during its Key
> and Certificate generation process and the controls used to ensure the
> integrity and confidentiality of the Key Pair."
>

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

> Section 6.2 now states, "FNMT-RCM shall protect its Private Key(s) in
> accordance with the provisions of this CPS and in a compliance with
> CA/Browser Forum's Baseline Requirements"
>

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

> Section 6.2.4 of the CPS now states, "Backup copies of CA Private Keys
> shall be backed up by multiple persons in Trusted Role position sand only
> be stored in encrypted form on cryptographic modules that meet the
> requirements specified in Section 6.2.1."
>

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

> Section 6.2.5 now states, "Only the FNMT-RCM may make a backup of the
> Private keys, guaranteeing that the security level of the copied data is at
> least equal to that of the original data and that the number of data
> duplicated does not exceed the minimum necessary to assure service
> continuity. The Signature creation data are not duplicated for any other
> purpose."
>

> 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 Section 6.2.6 now states, "The Certification Authorities’ Private keys
> are generated as described in point “6.1 Key generation and installation”.
> In the event that a Private Key is to be transported from one Cryptographic
> Module to another, the Private Key must be encrypted during transport.
> Private Keys must never exist in plain text form outside the Cryptographic
> Module boundary."
>

> 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
> (?))
>

> Section 6.2.7 now states, "Root CA private keys of the FNMT-RCM are
> generated and stored inside cryptographic modules which meet the
> requirements of 6.2.1 of this CPS"
>

> 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.".
>

> Section 6.5.1 now states, "The FNMT-RCM 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
>

> FNMT indicated "Sections 7 and 8 have been reviewed and more detailed
> information has been included in CPS v.1.6 sections 7.1.2, 8, 8.1, and 8.5.
> "
>
>
>

> On Fri, Dec 4, 2020 at 12:40 PM Santiago Brox via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> El viernes, 4 de diciembre de 2020 a las 18:20:41 UTC+1, Matthias van de

>> Thanks Matthias. We will work with the web content management team to
>> evaluate possible improvements in the distribution of our CPSs site.