First of all, thank you for your comments; since we already have the annual review planned on January 2020, we’ll also do an extensive review of all CPSs as suggested.
Considering all arguments we feel that the better approach at the moment is to enable the trust bit only on the Web CA since is the only CA issuing website certificates. We are prospecting the creation of a root CA dedicated to issue CA certificates aimed only at Mozilla usages but since the inclusion is a lengthy process, we will focus on the Web CA now.
Indeed, our architecture allows us to issue different type of certificates with the same CA having of course different CPSs. We fully disclosed all our CPSs and CAs as per Mozilla BR so if a new CPS is to be created on the same CA then this will be publicly available, audited and inline with BR. And we understand your point, we will nest all the CPSs because this finding is also valid for the CAs which do not issue website certificates.
Now, on the concrete feedback:
We will perform a general review of all the CPSs. As we speak we are in the process of hiring a new PKI Policy Manager, hopefully more suitable for the job and that will allow us to keep a highest level of awareness to the changes to BR and other browser program requirements.
[The Qualified CA includes multiple distinct types of issuances (signatures, seals, and timestamping), thus meaning it's a multi-purpose sub-CA. While e-mail and web are clearly separated, the combination of signature certificates (which may be used for e-mail) and timestamping certificates may represent a potential concern for other root programs or if Mozilla recognizes timestamping in the future. Further segmenting out the types of intermediates is encouraged for consideration in the future.
Qualified CA is a multi-purpose Qualified CA; according to EIDAS regulation, in order to perform a Qualified Timestamping Service, the certificate issued for the Timestamping Service must be issued by a CA which is Qualified. Hence the issuance of timestamp certificates from this CA. Indeed, if Mozilla is considering also the timestamping recognition in the future, we’ll consider this on the future Mozilla oriented Root CA.
[The validation process for OV websites requires in-person validation, per page 20. This introduces significant challenges to ensuring timely revocation, due to the challenges potentially faced with replacement or reverification. certSIGN only issues OV and EV (via QWAC) certificates, and thus there is no option to ensure a more timely replacement with minimal disruption]
According to ETSI 319411-1: An Organizational Validation Certificate Policy (OVCP) for TLS/SSL certificates offering the level of assurance required by CAB Forum for OVC. The policy requirements for this CP are built on the policy requirements for the issuance and management of LCP certificates, enhanced to refer to requirements from BRG  as applicable to organizational validation certificates. It includes, except where explicitly indicated, all the Lightweight Certificate Policy (LCP) requirements, plus additional provisions suited to support OVC issuance and management as specified in BRG .
Initial Identity Validation: [PTC]: The verification methods shall follow those specified in clause 11 of the EVCG  and clause 3.2 of BRG .
EVCG 11: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency’s face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation.
[PKI Disclosure Statement states "Distribution and reproduction prohibited without authorization by CERTSIGN SA"]
This will be removed from the document
[The limitation on liability only asserts liability for fraud or willful misconduct, to the extent under Romanian law.]
We kindly ask you to clarify this observation, because we did not understand if the problem is that limitation on liability only asserts liability for fraud or willful misconduct or the problem is that the limitation of liability is presented within the limit set by the Romanian Law.
[Annual Review is conducted by Information Security Officer. Alignment to the BRs did not happen until several months later (Feb 2018 to May 2018), conducted by the PKI Policies Manager. Prior update was September 2017.]
Annual review was done yearly. Our PKI policies manager deemed the CPSs aligned with BR and we considered there is no need to publish a new version of CPS. As mentioned we are in the process of selecting a new PKI policies manager as we speak and we are also redefining the approval flow of the modifications related to BR alignment.
[Clearly disclosed that Public Notaries may perform some RA functionality (1.3.5, p18), but it is unclear whether their activities are in the scope of the audit, particularly around NSCCRs]
Public notary performs only identification of the physical persons and does not access the CA/RA certificate system. So, Public notary is not a Delegated Third Party as defined in NCSSR and his activity is not in the scope of the audit.
[There is a seemingly heavy dependence on Attestation Letters in the identity validation process for 3.2.2, albeit not for the domain validation, which uses 184.108.40.206.4 (Constructed email)
Attestation Letter is just one of the possibilities to validate Identity, as mentioned also in BR.
[4.2.1 copies the language about "high risk requests", but does not document what the CA procedures are, just that the CA maintains them. This isn't useful for a CP/CPS.]
For instance, one of the internal procedures mandates that the operator checks at least the updated list of persons, groups and entities subject to Articles 2,3 and 4 of Common Position 2001/931/CFSP on the application of specific measures to combat terrorism. Since the procedures are specific to versions of the documents checked, we feel that is too much information for the CPS.
[4.2.2 still has the (since expired) language about internal server names and gTLDs, which hasn't been applicable since 2016.]
You are right, we will update the CPS to be in line with BR 1.6.7.
[4.7.3 describes the rekey validity period as having obtained documents within the past 12 moonths. This may be OK, as it would mean the effective reuse of data is less than 825-days. However, because they describe it based on when documents were obtained, rather than validated, it does run the risk that if someone sent the same (previously-validated) document, they may not re-validate the document within the required timeframe.]
Agreed, the wording is not proper. Since we always validate the documents, for us obtaining and validating were interchangeable.
[The CA may revoke if the person who requested the certificate is no longer employed by the company o_O]
If there is no longer a relationship between the subscriber and certificate applicant, CA may revoke the certificate if the revocation request came from the subscriber.
[Overall, 4.9.1 follows the old-BRs, which suggests a lack of review since SC6 (September 2018)]
We are aware of the SC6 regarding the possibility of revocation in at most 5 days, but we decided to maintain the revocation period to 24h as our procedures for the other subordinates are also set at 24h.
[4.9.11 is not compatible with the Microsoft requirements. While this is not a Mozilla requirement, it highlights a lack of awareness of program-specific requirements that may signal more problematic management practices.]
You are correct. The CPS does not reflect adequately the technical controls put in place to be compliant with Microsoft’s requirement. Although we have modified the OCSP response validity from a few minutes to 24 hours to be compliant, we have failed to update the CPS to reflect this also. We will specify our validity of 24h for OCSP response in the CPS.
[Reliance on logical security controls (e.g. firewalls), rather than physical security controls (i.e. not networking the devices together)]
Can you specify please more details about which device should not be networked together? As per our CPS, “CERTSIGN maintains and protect all CA systems in at least a secure zone and has in place a security procedure that protects systems and communications between systems inside secure zones and high security zones.” This includes non-ethernet communication between critical systems (CA) and other secure systems(RA).
[7.1 documents that they are using the absolute minimum number of bytes for serial numbers, in a way that may lead to serial number violations]
Serial numbers are constructed using a database constrained unique incremental prefix which is concatenated to a 8 bytes random sequence. Technically it is impossible to generate identical serial numbers. We will update the table 7.2 to be specific about the algorithm.
[OCSP server supports nonces, which have been problematic in the past (e.g. SHA-1) and potentially leave the OCSP server at risk of DoS attacks (by random nonces)]
Our OCSP system is compliant with RFC 6960 and has support for nonce to prevent replay attacks. Furthermore, we do not use precomputed responses, hence removing nonce does not help avoiding a DoS attack. We will analyze the opportunity to remove the nonce support from our software.
[9.3.1 describes confidential information, which is generally well-written, but notes "Results of internal and external audits, if they are a threat for CERTSIGN’s security,", which may lead to hiding or not reporting security or compliance incidents by deaming them "confidential"]
This note states that we can deem confidential information about vulnerabilities discovered for which a fix is not yet available. We can update the section like this: “...the results of the audit will be made public but the detailed audit report may be deemed confidential if they...”. Do you find this acceptable?
[9.3.2 makes it clear that certificate contents are not confidential, except this may conflict with or be modified by 2.2, which states that certificates won’t be made available without express consent. The concern here is disclosure for Certificate Transparency or for incident reports.]
All our web server certificates can be found in the CT logs, the process of issuing certificates is hardcoded to use pre-certificates and CT. General availability refers to publishing them on our site.
[Uses ETSI EN 319 411-1 v1.1.1 (2016-02)]
We use latest ETSI EN 319 411-1, the section was not updated accordingly.
[Section 1.4.2 prohibits the use of certificate for anything not expressly permitted. Section 1.4.1 details the acceptable uses, but the Subject/Subscriber is the one that has requirements placed on the software used to verify, rather than the Relying Party. Altogether, it’s confusing whether or not it’s suitable to be used on a web server, if only because it’s not clearly permitted, and a Web Server lacks the functionality to display certificate information to the user or to potentially retrieve status information (depending on the web server used, since this is traditionally a relying party obligation)]
You are right yet once more, we need to adapt this.
[Section 2.2 of the CPS does not list the CAA domains (220.127.116.11 does, however)]
Correct, we are using CAA records as a required step when the certificate request is inserted in the system. So, although we have the technical controls in place, we need to have the documentation on par with that.
[Section 3.1.2 conflicts with the Baseline Requirements in the case of natural persons or legal entities, as the commonName field is not constructed according to 18.104.22.168.2(a) of the BRs.]
The section states that even if the commonName may contain the domain name, this MUST be included in the DNS Name. If our understanding is correct, we must specify instead that “the commonName, if present, MUST contain one of the values from SAN”, right?
We do not issue OV certificates for natural persons and we will update the CPSs accordingly.
[Section 3.1.2 makes it clear that PII may also be included in publicly trusted TLS certificates, such as an person’s phone number, street address, or email address. This creates risk for the CA issuing such certificates, as the CA will be publicly disclosing this information.]
We do not issue OV/EV certificates for natural persons and we will update the CPSs accordingly.
[Section 3.1.5 indicates that Subject name uniqueness is not guaranteed, as certSIGN relies upon SANs to distinguish between two Subjects with the same fields. This is not the intended purpose of this section, as it suggests two distinct entities may end up with the same Subject.]
Since O is mandatory and must be unique, then we cannot have two entities with the same subject, but we can have an entity with two different SANs.
[3.1.1 makes it clear it uses the rfc822Name within the Subject DN, while 3.2.4 makes it clear that no steps to verify this e-mail address as performed. This violates the BRs 22.214.171.124.2(j), which requires Subject fields contain verified data.]
We do not issue OV certificates for natural persons and we will update the CPSs accordingly.
[4.2 emphasizes that there is some physical exchange required in order to get a certificate or validate the documents.]
At the moment, in our proceedings, this is the only reliable method to validate the documentation behind issuance of an OV or EV certificate.
[4.2.1 still refers to 36-months, although the BRs have limited this at 825 days.]
Agreed, since we always validate the documents, this will be updated to "at most 1 year".
[BRs 4.9.3 requires the problem reporting in Section 1.5.2. While the CP does have contact details in 1.5.2, the CPS lists a different problem reporting mechanism in Section 4.9.4, suggesting a lack of BR adherence here due to the different email, and a lack of discussion about providing an initial problem report.]
Correct, section 1.5.2 should contain the information which was specified in 4.9.3 related to revocation requests and address to submit them.
[7.1 documents they use the organizationIdentifier in a CA Subject]
Presence of OrganizationIdentifier in CA certificate is in line with ETSI EN 319 412-1: Subject and issuer names (X.509 [i.3]) can include attributes that do not disclose the semantics of its information content. serialNumber (X.509 [i.3]) and organizationIdentifier (X.520 [i.10]) are examples of such attributes. The serialNumber attribute can contain a national identification number, passport number or any type of locally defined identifier such as random or pseudo-random generated identifier. The organizationIdentifier attribute can contain several types of organizational identifiers.
[OCSP certificates use otherName subjectAltName]
This is a software limitation, at the moment we cannot issue OCSP certificates without specifying Subject Alternative Name
As a conclusion, we have a lot of work to do in the January review and we are welcoming any suggestions/remarks/feedback on the above answers. Of course, we'll come back with the revised versions as soon as possible to resume the process.