Having received no further comments, I have recommended approval of this request in bug 1403453 <https://bugzilla.mozilla.org/show_bug.cgi?id=1403453>
- Ben On Thu, May 28, 2020 at 12:06 PM Ben Wilson <bwil...@mozilla.com> wrote: > In accordance with the CA inclusion process[1], this is a summary of the > public discussion of Certsign’s application for inclusion of the certSIGN > ROOT CA G2 into the Mozilla root store with the websites trust bit and EV > enabled. The request is documented in Bugzilla #1403453[2]. The public > discussion began on 6-May-2020[3]. > > During the public discussion, it was noted that the audit report listed > six minor non-conformities regarding documentation and process > implementation[4]. Of primary concern was recordkeeping of the CA key > shares. Certsign responded that all six non-conformities, including key > share recordkeeping, had been remediated[5]. Specifically with regard to > the CA key shares, Certsign has registered its DR backup shares in its > asset inventory, card custody is recorded, use of secrets by the > application is logged by a script, and person(s) with access to the > safeboxes no longer has/have access to the room where the safeboxes are > stored.[6] > > No other comments were received. > > Based on a totality of the information presented and reviewed, I am > planning to recommend that Certsign’s application be approved. > > > I appreciate any feedback on this proposed course of action. > > [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 > > [3] > https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ > > > [4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635 > > [5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366 > > [6] > https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ > > > On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote: >> > The ETSI audit attestation statement referenced by Ben [1] lists 6 >> > non-conformities that were to be corrected within 3 months of the onsite >> > audit that occurred on 2020-02-10 until 2020-02-14: >> > >> > Findings with regard to ETSI EN 319 401: >> > -REQ-7.8-06–Documentation shall be improved >> > >> > Findings with regard to ETSI EN 319 411-1: >> > -REG-6.3.1-01–Implementation shall be improved >> > -GEN-6.5.1-04-Implementation shall be improved >> > >> > Findings with regard to ETSI EN 319 411-2: >> > -SDP-6.5.1-02 -Implementation shall be improved >> > -GEN-6.6.1-05–Documentation shall be improved >> > -CSS-6.3.10-13–Documentation shall be improved >> > >> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for >> > signing certificates shall be created under, at least, dual control. >> > >> > I'd like to see an explanation of these non-conformities and the >> > remediation from certSIGN, and confirmation from LSTI that they have >> been >> > fixed. >> > >> > - Wayne >> > >> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635 >> > >> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy < >> > dev-security-policy@lists.mozilla.org> wrote: >> > >> > > This request is for inclusion of the certSIGN Root CA G2 certificate >> and to >> > > turn on the Websites trust bit and for EV treatment. >> > > >> > > >> > > The request is documented in Bugzilla and in the CCADB as follows: >> > > >> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 >> > > >> > > >> > > >> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000403 >> > > >> > > (Summary of info gathered and verified, URLs for test websites, etc.) >> > > >> > > >> > > >> > > * certSIGN’s BR Self Assessment is here: >> > > >> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673 >> > > >> > > The Certsign document repository can be found here: >> > > >> > > https://www.certsign.ro/en/certsign-documents/policies-procedures >> > > >> > > * Root Certificate Locations: >> > > >> > > http://crl.certsign.ro/certsign-rootg2.crt >> > > >> > > http://registru.certsign.ro/certcrl/certsign-rootg2.crt >> > > >> > > http://www.certsign.ro/certcrl/certsign-rootg2.crt >> > > >> > > >> > > >> https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305 >> > > >> > > >> > > >> https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem >> > > >> > > >> > > * EV Policy OID: 2.23.140.1.1 >> > > >> > > * CRL URL: http://crl.certsign.ro/certsign-rootg2.crl >> > > >> > > * OCSP URL: http://ocsp.certsign.ro >> > > >> > > >> > > >> > > * Audit: See https://bugzilla.mozilla.org/attachment.cgi?id=9142635 ( >> > > >> > > >> http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1612-163_V10_Certsign_S.pdf >> > > ) >> > > which shows that a recent annual audit was performed on the certSIGN >> Root >> > > CA G2 by LSTI Group according to ETSI EN 319 411-2, V2.2.2 (2018-04)”, >> > > “ETSI EN 319 411-1, V1.2.2 (2018-04)” and “ETSI EN 319 401, V2.2.1 >> > > (2018-04)” as well as the CA/Browser Forum’s “EV SSL Certificate >> > > Guidelines, version 1.7.1” and “Baseline Requirements, version 1.6.7” >> > > considering the requirements of the “ETSI EN 319 403, V2.2.2 >> (2015-08)” for >> > > the Trust Service Provider Conformity Assessment. >> > > >> > > >> > > * CP/CPS Review >> > > >> > > Ryan Sleevi conducted a preliminary review the PKI Disclosure >> Statement and >> > > CPS - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13 >> > > >> > > I followed up, and now Comment #24 in Bugzilla shows the latest >> responses >> > > from Certsign - >> https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c24 >> > > >> > > >> > > >> > > This begins the 3-week comment period for this request. >> > > >> > > I will greatly appreciate your thoughtful and constructive feedback >> on the >> > > acceptance of this root into the Mozilla CA program. >> > > >> > > Thanks, >> > > Ben >> > > _______________________________________________ >> > > dev-security-policy mailing list >> > > dev-security-policy@lists.mozilla.org >> > > https://lists.mozilla.org/listinfo/dev-security-policy >> > > >> >> We, certSIGN, are waiting for the formal document assessing the closure >> of all the minor non-conformities by the LSTI auditor, and we will publish >> this report immediately. >> As requested by Wayne, we present more details on the minor >> non-conformity no.1, GEN-6.5.1-04. >> In the audit detailed report LSTI auditors stated on **GEN-6.5.1-04: The >> CA key pair used for signing certificates shall be created under, at least, >> dual control**, the following: >> CA keys were generated by personnel in trusted roles under dual control, >> and an external witness was involved. The CARL was also generated by two >> persons in trusted roles. Some issues could however be noticed during the >> audit, which led to the following deviation: Deviation no 1: A full >> traceability of the usage of the PKI’s secrets is not guaranteed: >> - The inventory of the secrets is not complete nor up to date (e.g. >> credentials (PIN codes) or backups of CA private keys are not explicitely >> identified, some secrets were allocated to the wrong persons in the >> inventory); >> - No measures are in place to follow precisely the usage of each secret; >> - The CISO can technically accede to all individual safes, thus >> potentially to all secrets of the PKI at the same time, without generating >> any retained records and without any oversee from a second person in a >> trusted role. >> certSIGN details on this issue: >> Since we started the operations, we have detailed info and records of the >> HSM cards allocations and on their usage. >> To activate one key, we require the simultaneous presence of two distinct >> persons, with trusted roles, one of them with access to HSM cards and one >> with access to the CA Admin System interface. >> Being with trusted roles, all these persons are trusted persons, named >> and verified with management roles attributes. >> The HSM cards are protected by PINs and are permanently stored in >> mini-safe with access codes. >> The mini-safe access is CCTV monitored. To access the card readers an >> operator need to pass through three access-controlled doors, each CCTV >> monitored. >> Outside working hours access is done only with preliminary scheduling and >> approval. >> A dedicated security person permanently monitors the security measures >> implementation. This person keeps the updated inventory of the HSM cards >> and of their allocated persons and monitor in real-time the access through >> all the doors, getting notifications on any CA key activation/usage. On any >> event the actions are done according to the internal instructions. >> Our corrective measures for this are the following: >> * We started to keep a separate inventory for all secrets recording the >> actual owner and each change of ownership >> * all secrets that are used daily will be followed at destination (that >> is in the application) by recording their usage in the application logs. >> * a second register was created for usage of the master key of the >> mini-safe boxes. The person that will know the code of the master mini-safe >> box will not have access to the room of the mini-safe boxes. Therefore, all >> accesses to the master mini-safe box will mandatory be obtained through the >> cooperation of two persons. Access to the master mini-safe box and usage of >> the master key will be recorded in the register. A procedure is in place >> and communicated to secrets owners. >> Thank you >> Gabriel Petcu >> _______________________________________________ >> 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
