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
