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 <bwil...@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-security-policy@lists.mozilla.org> wrote: > >> El viernes, 4 de diciembre de 2020 a las 18:20:41 UTC+1, Matthias van de >> Meent escribió: >> > 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. >> > >> > > >> > >> > 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 >> > >> _______________________________________________ >> > >> dev-security-policy mailing list >> > >> dev-secur...@lists.mozilla.org >> > >> https://lists.mozilla.org/listinfo/dev-security-policy >> Thanks Matthias. We will work with the web content management team to >> evaluate possible improvements in the distribution of our CPSs site. >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
