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
