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: > > > > 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. > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
