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 < > [email protected]> 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 > > [email protected] > > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
