Request to Include certSIGN Root CA G2 certificate

[Ben Wilson]

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

[Wayne Thayer]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Gabriel Petcu]

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

[Ben Wilson]

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-secur...@lists.mozilla.org> wrote:

> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:

> 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,

[Ben Wilson]

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

>> 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,