Bugzilla

I've completed a preliminary review, based on the information provided in Comment #12.

My preliminary review involved detailed review of the PKI Disclosure Statement and the Web CA OV CPS and cursory review of the other documents, particularly in a PDF-diff mode. I'm setting N-I for Kathleen to review the "High Level" feedback, and to get her input on her recommendations on how best to proceed here, particularly with trusting the root vs sub-CA.

## High Level
Overall, given that this is request the Websites trust bit, my high-level recommendation is to question whether it makes sense to add the certSIGN Web CA as the trust root, rather than Root CA G2. As documented in the Root CP/CPS, Section 1.3.1, all Website certificates are issued from the Web CA (qualified and non-qualified). It does not seem necessary or disable to trust the other forms?

From a design, it's clear that certSIGN's issuance practices are not inherently restricted by CA. Rather, the types of certificates are structured based on their certificate policy, expressed based on the issued certificate. This creates a particular challenge - a given CA key may have multiple CPSes associated with it, making it difficult to understand how the key is managed or what the key may sign. This makes it quite challenging to accurately review and understand the operations, and runs the risk that future CPSes may be introduced in which "TLS-like" certificates are introduced and which do not comply with the BRs.

Further, the CPSes of the Root and the Web CA do not nest; that is, the Web CA CPS does not seem to be "compatible" or "subordinate" to the root. For example, 4.9.5. of the Root CPS guarantees revocation of certificates issued by the Root within 8 hours, while the Web CA uses the 24 hour maximum of the BRs. This would appear to be incompatible, except the wording within the Root CPS may only be applying to subordinate CAs, and not any certificates issued from or by those subordinate CAs. Separate from that, it seems unlike that certSIGN would revoke a sub-CA in 8 hours, given that it has the effect of revoking all certificates issued by that sub-CA.

So these high-level comments are meant to question the overall design and approach, and to carefully understand what is being trusted and how it is trusted. NSS/Mozilla lacks the ability to trust only based on policy OID, which seems a necessary component given how certSIGN's system is designed.

### Concrete Feedback

Below are more detailed notes for the PKI Disclosure Statement and the Web OV CPS. Overall, the issues I highlight suggest a systemic lack of awareness of changes to the Baseline Requirements and to various browser program requirements, both Mozilla and Microsoft. This suggests that a systemic, and holistic, review of all of the CPSes is necessary by certSIGN, before performing another detailed review, to ensure that they are adhering to the current requirements both within the BRs and within Browser Program requirements.

Overall, I appreciated the extensive documentation, because I would greatly prefer more documentation and a clearer understanding of how the CA operates. The documentation around the physical and operational security controls was extremely useful, and more thorough than other CP/CPSes I've reviewed. I think if it was possible to build a coherent picture of how the Web CA is operated (for all certificates), it'd be a net-win, although I don't think the current CP/CPS approach facilitates that, unfortunately.

Please note, that many of the "Bad" issues are, judging by cursory scans, repeated in other documents. This is why I encourage a holistic review, and making sure that the policies appropriately "nest" - that is, that anything a subordinate does is compatible with the root, and any subordinate certificate profiles are compatible with how that subordinate is generally operated.

## PKI Disclosure Statement v2.12
https://www.certsign.ro/media/document/TDVzREg4ZFErb1hoN0dteU9BM1FyQT09/original/PDS%20for%20CERTSIGN%20ROOT%20CA%20G2_Version%202.12.pdf
Date 11 July 2019

### Good
  * Clear documentation about each of the types of certificates issued from each of the applicable CAs
  * 1 year lifetime for certs
  
### Meh
  * 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.
  * 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.
 
### Bad
  * PKI Disclosure Statement states "Distribution and reproduction prohibited without authorization by CERTSIGN SA"
  * The limitation on liability only asserts liability for fraud or willful misconduct, to the extent under Romanian law.

## Web CA OV CPS
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf
Date 25 April 2019

### Good
  * Clearly documenting the annual review and versioning.
  * Clearly documenting that they do not issue names with underscores
  * 5.1.1 documents many of the physical security protections
  * 6.1.1 is great documentation for the key ceremony

### Meh
  * 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.
  * 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
  * 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 3.2.2.4.4 (Constructed email)
  * 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.
  * 4.2.2 still has the (since expired) language about internal server names and gTLDs, which hasn't been applicable since 2016.
  * 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.
  * The CA may revoke if the person who requested the certificate is no longer employed by the company o_O
  * Overall, 4.9.1 follows the old-BRs, which suggests a lack of review since SC6 (September 2018)
  * 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.
  * Reliance on logical security controls (e.g. firewalls), rather than physical security controls (i.e. not networking the devices together)
  * 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
  * 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)
  * 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"
  * 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.

### Bad
  * Uses ETSI EN 319 411-1 v1.1.1 (2016-02)
  * 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)
  * Section 2.2 of the CPS does not list the CAA domains (3.2.2.8 does, however)
  * 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 7.1.4.2.2(a) of the BRs.
  * 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.
  * 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.
  * 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 7.1.4.2.2(j), which requires Subject fields contain verified data.
  * 4.2 emphasizes that there is some physical exchange required in order to get a certificate or validate the documents.
  * 4.2.1 still refers to 36-months, although the BRs have limited this at 825 days.
  * 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.
  * 7.1 documents they use the organizationIdentifier in a CA Subject
  * OCSP certificates use otherName subjectAltName

I've completed a preliminary review, based on the information provided in Comment #12.

My preliminary review involved detailed review of the PKI Disclosure Statement and the Web CA OV CPS and cursory review of the other documents, particularly in a PDF-diff mode. I'm setting N-I for Kathleen to review the "High Level" feedback, and to get her input on her recommendations on how best to proceed here, particularly with trusting the root vs sub-CA.

## High Level
Overall, given that this is request the Websites trust bit, my high-level recommendation is to question whether it makes sense to add the certSIGN Web CA as the trust root, rather than Root CA G2. As documented in the Root CP/CPS, Section 1.3.1, all Website certificates are issued from the Web CA (qualified and non-qualified). It does not seem necessary or desirable to trust the other forms?

From a design, it's clear that certSIGN's issuance practices are not inherently restricted by CA. Rather, the types of certificates are structured based on their certificate policy, expressed based on the issued certificate. This creates a particular challenge - a given CA key may have multiple CPSes associated with it, making it difficult to understand how the key is managed or what the key may sign. This makes it quite challenging to accurately review and understand the operations, and runs the risk that future CPSes may be introduced in which "TLS-like" certificates are introduced and which do not comply with the BRs.

Further, the CPSes of the Root and the Web CA do not nest; that is, the Web CA CPS does not seem to be "compatible" or "subordinate" to the root. For example, 4.9.5. of the Root CPS guarantees revocation of certificates issued by the Root within 8 hours, while the Web CA uses the 24 hour maximum of the BRs. This would appear to be incompatible, except the wording within the Root CPS may only be applying to subordinate CAs, and not any certificates issued from or by those subordinate CAs. Separate from that, it seems unlike that certSIGN would revoke a sub-CA in 8 hours, given that it has the effect of revoking all certificates issued by that sub-CA.

So these high-level comments are meant to question the overall design and approach, and to carefully understand what is being trusted and how it is trusted. NSS/Mozilla lacks the ability to trust only based on policy OID, which seems a necessary component given how certSIGN's system is designed.

### Concrete Feedback

Below are more detailed notes for the PKI Disclosure Statement and the Web OV CPS. Overall, the issues I highlight suggest a systemic lack of awareness of changes to the Baseline Requirements and to various browser program requirements, both Mozilla and Microsoft. This suggests that a systemic, and holistic, review of all of the CPSes is necessary by certSIGN, before performing another detailed review, to ensure that they are adhering to the current requirements both within the BRs and within Browser Program requirements.

Overall, I appreciated the extensive documentation, because I would greatly prefer more documentation and a clearer understanding of how the CA operates. The documentation around the physical and operational security controls was extremely useful, and more thorough than other CP/CPSes I've reviewed. I think if it was possible to build a coherent picture of how the Web CA is operated (for all certificates), it'd be a net-win, although I don't think the current CP/CPS approach facilitates that, unfortunately.

Please note, that many of the "Bad" issues are, judging by cursory scans, repeated in other documents. This is why I encourage a holistic review, and making sure that the policies appropriately "nest" - that is, that anything a subordinate does is compatible with the root, and any subordinate certificate profiles are compatible with how that subordinate is generally operated.

## PKI Disclosure Statement v2.12
https://www.certsign.ro/media/document/TDVzREg4ZFErb1hoN0dteU9BM1FyQT09/original/PDS%20for%20CERTSIGN%20ROOT%20CA%20G2_Version%202.12.pdf
Date 11 July 2019

### Good
  * Clear documentation about each of the types of certificates issued from each of the applicable CAs
  * 1 year lifetime for certs
  
### Meh
  * 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.
  * 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.
 
### Bad
  * PKI Disclosure Statement states "Distribution and reproduction prohibited without authorization by CERTSIGN SA"
  * The limitation on liability only asserts liability for fraud or willful misconduct, to the extent under Romanian law.

## Web CA OV CPS
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf
Date 25 April 2019

### Good
  * Clearly documenting the annual review and versioning.
  * Clearly documenting that they do not issue names with underscores
  * 5.1.1 documents many of the physical security protections
  * 6.1.1 is great documentation for the key ceremony

### Meh
  * 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.
  * 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
  * 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 3.2.2.4.4 (Constructed email)
  * 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.
  * 4.2.2 still has the (since expired) language about internal server names and gTLDs, which hasn't been applicable since 2016.
  * 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.
  * The CA may revoke if the person who requested the certificate is no longer employed by the company o_O
  * Overall, 4.9.1 follows the old-BRs, which suggests a lack of review since SC6 (September 2018)
  * 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.
  * Reliance on logical security controls (e.g. firewalls), rather than physical security controls (i.e. not networking the devices together)
  * 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
  * 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)
  * 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"
  * 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.

### Bad
  * Uses ETSI EN 319 411-1 v1.1.1 (2016-02)
  * 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)
  * Section 2.2 of the CPS does not list the CAA domains (3.2.2.8 does, however)
  * 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 7.1.4.2.2(a) of the BRs.
  * 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.
  * 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.
  * 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 7.1.4.2.2(j), which requires Subject fields contain verified data.
  * 4.2 emphasizes that there is some physical exchange required in order to get a certificate or validate the documents.
  * 4.2.1 still refers to 36-months, although the BRs have limited this at 825 days.
  * 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.
  * 7.1 documents they use the organizationIdentifier in a CA Subject
  * OCSP certificates use otherName subjectAltName