1403453 - Add certSIGN Root CA G2 certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Cristian Garabet]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Comment 1

[Kathleen Wilson]

Cristian, please provide the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist

And attach your BR Self Assessment to this bug:
https://wiki.mozilla.org/CA/Information_Checklist#Baseline_Requirements_Self_Assessement

Comment 2

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 3

[Andrew]

Very concerned about the secrecy regarding the preparation for the inclusion of the new root certificate certSIGN ROOT CA G2 from ordinary users and whether it is possible in the light of this secrecy to trust the existing root certSIGN ROOT CA...

Comment 4

[Kathleen Wilson]

This request is still waiting for the CA to update this bug with the required information, per step 1 of Mozilla's root inclusion process:

https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Cristian, When you are ready to proceed, please provide the required information via a Root Inclusion Case in the CCADB, as described here:

https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Then add a comment to this bug to provide the "Mozilla Root Inclusion Case Information:" link.

Comment 5

[Andrew]

Thank you for this message, but what the URL with 'Access denied': https://bugzilla.mozilla.org/show_bug.cgi?id=1430324 ?

Andrew.

Comment 6

[Kathleen Wilson]

(In reply to Andrew from comment #5)

Thank you for this message, but what the URL with 'Access denied': https://bugzilla.mozilla.org/show_bug.cgi?id=1430324 ?

Andrew.

That was a request to re-assign all of the bugs to me that that had been assigned to Aaron, after he left Mozilla.

Comment 7

[Cristian Garabet]

Kathleen, we will make an effort to provide the required information to start the public discussions as soon as possible. Lately we were very busy with several international tenders and some new technological developments.

Comment 8

[Valentin Necoara]

Attachment: certSIGN_ROOT_ CA G2_BR Self Assessment_Bugzilla_SSL_OV_EV_2019.xlsx

Comment 9

[Valentin Necoara]

Hello,

This is the link to the CCADB case:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000403

If there is need for further information, I'll be happy to provide it.

Thank you,
Valentin.

Comment 10

[Kathleen Wilson]

(In reply to Valentin Necoara from comment #9)

This is the link to the CCADB case:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000403

Thank you for directly entering your root inclusion request data into the CCADB.

I have reviewed the data, and found 3 items that need to be fixed.

1)Required Practice 1.3 BR Commitment to Comply statement in CP/CPS: OV and EV CPS Section 2.2
I found this in Web CA QCW CPS.
NEED: I did not find the BR Commitment to Comply statement in Web CA OV CPS.

2. Required Practice 6 DNS names go in SAN: OV and EV CPS, Section 3.1
   NEED: Update Web CA OV CPS and Web CA QCW CPS to state that the domain MUST be in the SAN.
   Current text: "For SSL certificates, while FQDN or an authenticated domain name is placed in the Common Name (CN) attribute of the Subject field, it can also be copied in the Subject Alternative Name extension, in DNS Name."
   That is insufficient.
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#DNS_names_go_in_SAN

3. Forbidden Practice 1. Long-lived Certificates: OV and EV CPS, Section 6.3.2
   NEED: Update Web CA OV CPS to match current BRs "Certificates issued MUST have a Validity Period no greater than 825 daysand re-use of validation information limited to 825 days"

Comment 11

[Valentin Necoara]

Thank you for your comments.

1. Fixed, the OV CPS now has the same commitment as the EV/QCW.
2. Fixed in both CPSs. "For SSL certificates, while FQDN or an authenticated domain name can be placed in the Common Name (CN) attribute of the Subject field, it MUST be present in the Subject Alternative Name extension, in DNS Name. Subject Alternative Name are marked as non-critical, in accordance with RFC5280."
3. Fixed, the OV CPS now has the same content as the EV/QCW.
   Also specified in both CPSs "Re-use of validation information is limited to the lifetime of the issued certificate." since we require validation procedure to be performed for every new certificate.

Comment 12

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000403

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:

https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Comment 13

[Ryan Sleevi]

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

Comment 14

[Valentin Necoara]

Thank you Ryan for your extensive feedback.
We've started analyzing all your findings.

Comment 15

[Wayne Thayer]

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.

In order to add the root CA to the Mozilla program, the root and all subordinates must comply with all Mozilla policies. If that is difficult to achieve, Mozilla is willing to accept a modification of this request from certSIGN to only include the TLS subordinate CA.

Comment 16

[Cristian Garabet]

(In reply to Ryan Sleevi from comment #13)

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

Hi Ryan, can you clarify what do you mean by NSCCR?

Comment 17

[Wayne Thayer]

I believe Ryan's reference should be "NCSSRs".

Comment 18

[Ryan Sleevi]

Er, yes, apologies for that typo.

https://cabforum.org/network-security-requirements/

Comment 19

[Cristian Garabet]

Thank you guys!

Comment 20

[Valentin Necoara]

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 [5] 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 [5].

Initial Identity Validation: [PTC]: The verification methods shall follow those specified in clause 11 of the EVCG [4] and clause 3.2 of BRG [5].

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 3.2.2.4.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 (3.2.2.8 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 7.1.4.2.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 7.1.4.2.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.

Comment 21

[Ryan Sleevi]

Thanks for the responses, Valentin.

If it helps, Bugzilla supports markdown as well as quoting (as you can see below), which can make it easier to visually distinguish replies. Where applicable, I've modified the formatting of some of the replies below, to hopefully make it easier for your review in January. You don't need to do inline replies, since this is admittedly rather lengthy already, but I just wanted to mention it in the event it makes it easier to read or reply.

(In reply to Valentin Necoara from comment #20)

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.

That's great!

If there's an opportunity here to collaborate on the PKI design/hierarchy, to help ensure you have the maximum compatibility with your existing users and existing software that trusts your existing root, we'd be happy to help and explore ideas here, to minimize delays or challenges.

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.

Perhaps I misunderstood how certSIGN had approached its qualifications.

A 'simple' design, assuming one has the Root Certificate added to the TSL, is

        /--> Web CA
       /---> E-mail CA
Root  |----> Timestamping CA
       \---> Seal CA
        \--> Other CAs

At that point, if the Root is on the TSL as Qualified, then each of your (Web, Seal, Signature, Timestamp) certificates can also be qualified, as appropriate. Each of these sub-CAs can be separated by EKU, as appropriate, allowing compliance with the appropriate root program requirements audit for each EKU (e.g. Timestamping CA only subject to timestamping audits), rather than require your Qualified CA be subject to audits appropriate for (Web, E-amil, and timestamping)

Hopefully that makes sense! You can see how Microsoft applies audits-per-EKU at https://aka.ms/auditreqs . It also helps ensure compliance with Section 5.3 of the Mozilla Policy, and Section 4.A.11 of the Microsoft policy.

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 [5] 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 [5].

Initial Identity Validation: [PTC]: The verification methods shall follow those specified in clause 11 of the EVCG [4] and clause 3.2 of BRG [5].

Thanks. This is a result of using the older version, EN 319 411-1 v1.1.1, which is why it was important to highlight the lack of keeping up to date. If you examine EN 319 411-1 v1.2.2, it's hopefully much clearer the expectations.

REG-6.2.2-03 [PTC]: The verification methods shall follow those specified in clause 3.2 of BRG [5]. 
REG-6.2.2-04 [EVCP]: The verification methods shall follow those specified in clause 11 of the EVCG [4]. 

There's much more expansive discussion within 1.2.2, and I think it's important to review this, as the face-to-face validation is not required for OVCP, and for EVCP, there is flexibility and recognition for verification other than physical presence.

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.

I highlighted this particular restriction because in the event certSIGN makes an 'unintentional' mistake, such as a failure to appropriately validate domain names, it is seemingly disclaiming liability from any damage that may result. It sets up a significant burden with respect to establishing 'willful'.

This is not easily resolved, because it is understandable that certSIGN would wish to limit its liability to the maximum extent possible. It is something for the community to consider though: what might go wrong, particularly if certSIGN were negligent, and what resource, if any, might exist to Mozilla users?

The question of CA liability is understandably complex, and in some views, of questionable validity, so it may be that certSIGN and its legal department keep the existing language. Hopefully the above explanation, however, explains a bit more about the things I and other members of the community worry about, as an opportunity for how certSIGN might address that, if at all possible.

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.

The Baseline Requirements, v1.6.7, Section 2, requires that

The CA SHALL develop, implement, enforce, and annually ***update*** a Certificate Policy and/or Certification
Practice Statement that describes in detail how the CA implements the latest version of these Requirements.

The requirement is to publish a new version, even if there are no changes made, to help provide public assertion to the community that management has indeed reviewed.

Mozilla Root Store Policy, v2.7, as well as previous versions, further emphasizes and clarifies this Baseline Requirements rule, in Section 3.3

CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.

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.

Right, but the identification of the physical persons is a requirement, at least with respect to EV, and so it's performing a requirement of the CA, which means it is a Delegated Third Party. In the context of EN 319 411-1, v1.1.1, that's similarly an expression of a requirement on the CA (for PTC), and thus would expect that they are Delegated Third Parties.

That said, this is an area of significant complexity here, so I want to be careful about encouraging you to take any particular steps. For example, there's understandable complexity and debate about whether they are DTPs. The primary recommendation to satisfy this concern is to be very explicit within your CPS about the role these notaries play, how the CA determines these notaries fulfill their role (and/or how these notaries are verified). If the CA determines they're not Delegated Third Parties, which may very well be an acceptable answer, being very clear and explicit about this at least helps the community understand.

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)

Attestation Letter is just one of the possibilities to validate Identity, as mentioned also in BR.

Correct. Although permitted, the use of Attestation Letters can easily lead to incorrect information or abuse. This is why they were forbidden from use in the domain name validation process. CAs which rely on Attestation Letters benefit from documenting their process and procedures for detecting and/or preventing abuse (for example, misuse of signed letterhead, forgery, entities not actually in the legal profession, etc). In short, if I (a non-lawyer) were to write an attestation letter for myself, how would that be detected or prevented, and is that clear from the CPS?

This emphasizes a broader point for the CPS, as part of your review, which is for elements that are risky - such as attestation letters, public notaries, use of third-party data sources, or any other element where the CA "trusts" someone else - having clarity that the CA has procedures to detect and prevent abuse, and potentially disclosing some of those procedures, is very useful. It helps demonstrate that a CA is aware of the potential risks, and mitigates them, making it easier for others to trust the CA and the CA's decision making process.

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.

Some approaches that other CAs have used is to use appendices or supporting documents, similarly made publicly available, to help provide transparency. The previous clarifications hopefully help explain the goal of these CP/CPS reviews and why concrete information is valuable and useful.

[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.

Thanks. I think your explanation may be clearer, as it seems you revoke not because the employment status changed, but because a natural or legal person who was previously authorized by the domain holder, may no longer be authorized.

[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).

In particular, the concern was about requirement 1.c within the Network and Certificate System Security Requirements, v1.3, that

Maintain Root CA Systems in a High Security Zone and in an offline state or air-gapped from all other networks;

Thus, it's not sufficient to have a security procedure in place to protect such systems between zones, but that at least with respect to the High Security Zone and the Secure Zone, there must be physical separation, and either offline or, when online, physically air-gapped.

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.

Thanks, that's an important clarification (the lack of pre-computed responses). In general, pre-computed responses may be the only way for a CA to satisfy the requirements of the Baseline Requirements around availability. This is where the previously-mentioned hierarchy split may be useful, to ensure that at least for TLS, pre-computed responses can be used and high-availability can be delivered.

To be clear: using pre-computed responses is not mandatory explicitly, but it significantly reduces the risk of a BR violation. A BR violation could occur for a number of reasons, such as incorrect key protection for the OCSP responder (as the BRs require these be protected like intermediate CAs) or through a service outage caused by DoS.

Removing nonces, and adopting precomputed, at least for TLS, may help ensure your system is robust and scalable.

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?

I highlight this because this is a general point of confusion between the application of WebTrust and ETSI. While browsers do not require the detailed audit report, the expectation is that the result of the audit will still disclose any non-conformities that were detected, both minor and major, and which may involve disclosing that a security issue was discovered. The browsers will then work with the CA to understand the nature of the issue and how it was mitigated, but the expectation is that it will be disclosed if something is found.

I mention this because while your suggested edit may comply with this expectation, it may not be clear that browsers expect the "result of the audit" to disclose the number and nature of non-conformities found.

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.

This may be worth clarifying in future revisions of your CPS to make it clear, as you have here.

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.

Based on the earlier response regarding Initial Identity Validation, I'm not sure I'm confident that this was the case. I definitely want to make sure the January review carefully addresses this and any changes through EN 319 411-1 and related.

Section 2.2 of the CPS does not list the CAA domains (3.2.2.8 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.

This is a Baseline Requirements requirement (the particular disclosure in Section 2.2), and that's why I flagged this: it's indicative of a lack of keeping up to date with the BRs, even if you may have implemented CAA.

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.

Yes, but please be aware of the significant discussions in the CA/Browser Forum around the Baseline Requirements not permitting the use of these additional fields within CA certificates. A lengthy thread was originally started at https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html and has seen significant discussion. Most recently, DigiCert and myself are working to clarify this in the BRs (as mentioned in https://cabforum.org/pipermail/validation/2019-December/001387.html ), but at present, this is not explicitly permitted.

While it is, admittedly, a lengthy discussion in the CA/Browser Forum, I encourage certSIGN to review that discussion (and the F2F minutes from Guangzhou), because one of the key takeaways has been the need for CAs to carefully review to make sure that what they do is actually and explicitly permitted by the BRs, and to raise issues or seek clarification when it's ambiguous.

[OCSP certificates use otherName subjectAltName]

This is a software limitation, at the moment we cannot issue OCSP certificates without specifying Subject Alternative Name

Similar to the above, the Baseline Requirements do not permit this, so it is a BR violation. That's why this was flagged.

Comment 22

[Valentin Necoara]

Thanks Ryan, we'll review your input and come back with some expanations.

Comment 23

[Ben Wilson]

I went through and reviewed the above comments and compared them to the updated PKI Disclosure Statement and Certification Practices Statement. Here are my observations.

PKI Disclosure Statement v2.15

https://www.certsign.ro/media/document/MnFVcDYzN0tvcStGYVRMaU1lY3hFQT09/original/PDS%20for%20CERTSIGN%20ROOT%20CA%20G2_v2.15.pdf

Date of PDS: 5 February 2020

Meh

PKI Disclosure Statement states "Distribution and reproduction prohibited without authorization by CERTSIGN SA"]

This will be removed from the document

Fixed (but not fixed in the CPS)

The limitation on liability only asserts liability for fraud or willful misconduct, to the extent under Romanian law.]

No change. See discussion below.

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.

I highlighted this particular restriction because in the event certSIGN makes an 'unintentional' mistake, such as a failure to appropriately validate domain names, it is seemingly disclaiming liability from any damage that may result. It sets up a significant burden with respect to establishing 'willful'.

This is not easily resolved, because it is understandable that certSIGN would wish to limit its liability to the maximum extent possible. It is something for the community to consider though: what might go wrong, particularly if certSIGN were negligent, and what resource, if any, might exist to Mozilla users?

The question of CA liability is understandably complex, and in some views, of questionable validity, so it may be that certSIGN and its legal department keep the existing language. Hopefully the above explanation, however, explains a bit more about the things I and other members of the community worry about, as an opportunity for how certSIGN might address that, if at all possible.

Web CA OV CPS v. 1.12

Date of CPS: 7 February 2020

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.]

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.

The requirement is to publish a new version, even if there are no changes made, to help provide public assertion to the community that management has indeed reviewed.

The CPS could contain a statement that certSIGN publishes the CPS at least annually, even if there are no changes.

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.

Right, but the identification of the physical persons is a requirement, at least with respect to EV, and so it's performing a requirement of the CA, which means it is a Delegated Third Party. In the context of EN 319 411-1, v1.1.1, that's similarly an expression of a requirement on the CA (for PTC), and thus would expect that they are Delegated Third Parties.

That said, this is an area of significant complexity here, so I want to be careful about encouraging you to take any particular steps. For example, there's understandable complexity and debate about whether they are DTPs. The primary recommendation to satisfy this concern is to be very explicit within your CPS about the role these notaries play, how the CA determines these notaries fulfill their role (and/or how these notaries are verified). If the CA determines they're not Delegated Third Parties, which may very well be an acceptable answer, being very clear and explicit about this at least helps the community understand.

Instances of "notary" were removed from sections 3.2.3 and 4.2.

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)

Attestation Letter is just one of the possibilities to validate Identity, as mentioned also in BR.

Correct. Although permitted, the use of Attestation Letters can easily lead to incorrect information or abuse. This is why they were forbidden from use in the domain name validation process. CAs which rely on Attestation Letters benefit from documenting their process and procedures for detecting and/or preventing abuse (for example, misuse of signed letterhead, forgery, entities not actually in the legal profession, etc). In short, if I (a non-lawyer) were to write an attestation letter for myself, how would that be detected or prevented, and is that clear from the CPS?

This emphasizes a broader point for the CPS, as part of your review, which is for elements that are risky - such as attestation letters, public notaries, use of third-party data sources, or any other element where the CA "trusts" someone else - having clarity that the CA has procedures to detect and prevent abuse, and potentially disclosing some of those procedures, is very useful. It helps demonstrate that a CA is aware of the potential risks, and mitigates them, making it easier for others to trust the CA and the CA's decision making process.

"Attestation Letter" has been removed from Section 3.2.2.1, which is re-written to describe the required documents and procedure to be followed by the RA. However, it is a little unclear what is meant by the "Template statement of the domain’s owner." What language would the statement contain?

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.

Some approaches that other CAs have used is to use appendices or supporting documents, similarly made publicly available, to help provide transparency. The previous clarifications hopefully help explain the goal of these CP/CPS reviews and why concrete information is valuable and useful

Without disclosing trade secrets or information security techniques, certSIGN should consider providing a more detailed explanation in its CPS of some actual practices it uses to handle high risk requests (rather than just repeating requirements language).

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.

Fixed

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.

Fixed

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.

Thanks. I think your explanation may be clearer, as it seems you revoke not because the employment status changed, but because a natural or legal person who was previously authorized by the domain holder, may no longer be authorized.

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.

Fixed

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.

Section 4.9.10 now states, "For the status of Subscriber Certificates, the CA updates information provided via an Online Certificate Status Protocol at list [sic] every hour. OCSP responses from this service MUST have a maximum expiration time 24h."

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).

In particular, the concern was about requirement 1.c within the Network and Certificate System Security Requirements, v1.3, that

Maintain Root CA Systems in a High Security Zone and in an offline state or air-gapped from all other networks;

Thus, it's not sufficient to have a security procedure in place to protect such systems between zones, but that at least with respect to the High Security Zone and the Secure Zone, there must be physical separation, and either offline or, when online, physically air-gapped.

Section 5 is well-written, but it could contain more about the physical protection of CA private keys. Also, in Section 5, instead of or in addition to asserting compliance with the CA/B Forum Baseline Requirements, which it already does in section 2.2, certSIGN should assert that it complies with the above-referenced CA/Browser Forum Network and Certificate System Security Requirements. (That would address the air-gapped requirement.)

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.

Fixed

Question: In the profile for the OCSP server certificate (Table 7.5 on page 82), the AIA URL says www.certsign.ro/certcrl/certsign-qualifiedca.crt shouldn't it be http://www.certsign.ro/certcrl/certsign-webca.crt or is the Qualified CA being used?

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.

Thanks, that's an important clarification (the lack of pre-computed responses). In general, pre-computed responses may be the only way for a CA to satisfy the requirements of the Baseline Requirements around availability. This is where the previously-mentioned hierarchy split may be useful, to ensure that at least for TLS, pre-computed responses can be used and high-availability can be delivered.
To be clear: using pre-computed responses is not mandatory explicitly, but it significantly reduces the risk of a BR violation. A BR violation could occur for a number of reasons, such as incorrect key protection for the OCSP responder (as the BRs require these be protected like intermediate CAs) or through a service outage caused by DoS.
Removing nonces, and adopting precomputed, at least for TLS, may help ensure your system is robust and scalable.

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?

I highlight this because this is a general point of confusion between the application of WebTrust and ETSI. While browsers do not require the detailed audit report, the expectation is that the result of the audit will still disclose any non-conformities that were detected, both minor and major, and which may involve disclosing that a security issue was discovered. The browsers will then work with the CA to understand the nature of the issue and how it was mitigated, but the expectation is that it will be disclosed if something is found.

I mention this because while your suggested edit may comply with this expectation, it may not be clear that browsers expect the "result of the audit" to disclose the number and nature of non-conformities found.

It does not appear that this issue has been fully resolved. However, there is an expectation that security and compliance are reported on a timely basis. Section 5.7.1 could be amended to state that in the case of incident, "The security incident management procedure also specifies how to notify the appropriate parties in line with the applicable regulatory rules of any breach of security or loss of integrity that has a significant impact on the trust service provided and <u>or</u> on the personal data maintained therein within 24 hours of the breach being identified. In case of security incident, internal procedures are used. The procedures include the notification of <u>Application Software Suppliers, certSIGN's auditors, and</u> the Supervisory body.

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.

This may be worth clarifying in future revisions of your CPS to make it clear, as you have here.

certSIGN could edit section 2.2 to state that it publishes pre-certificates to Certificate Transparency logs.

Bad

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.

Based on the earlier response regarding Initial Identity Validation, I'm not sure I'm confident that this was the case. I definitely want to make sure the January review carefully addresses this and any changes through EN 319 411-1 and related.

Replaced with simply "ETSI EN 319 411-1"

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 1.4.2 now reads, "Certificates must only be used to the extent consistent with applicable law and for the purposes specified in chapter 1.4.1" Language in Section 1.4.1 has been edited to read, "The applications for which the certificate is deemed to be trustworthy shall be decided by the Relying Parties themselves based on the nature and purpose (incl. key usage) of the certificate, including any applicable limitation as written in the certificate. It is the responsibility of the Relying Party to decide for which purpose the certificates are considered trustworthy."

Section 2.2 of the CPS does not list the CAA domains (3.2.2.8 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.

This is a Baseline Requirements requirement (the particular disclosure in Section 2.2), and that's why I flagged this: it's indicative of a lack of keeping up to date with the BRs, even if you may have implemented CAA.

Fixed

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.]

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.

Fixed - Certsign's CPS now states it does not issue SSL OV certificates for natural persons. The description of the DN components is:
Mandatory
• Field O – name of the organization,
• Field L – residence city of the Subscriber,
• Field C – international abbreviation for country name.
Optional
• Field CN – Fully-Qualified Domain Name,
• Field OU – name of the organization’s department,
• Field S – county/district where the organization functions,
• Field streetAddress – Subscriber’s street address information.
This appears to be consistent with section 7.1.4.2.2 of the Baseline Requirements

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.

Fixed - This section now reads "Name uniqueness is ensured using O field which is mandatory and must be unique for a given entity and through the use of the Fully Qualified Domain Name in Subject Alternative Name. The uniqueness of a domain name is guaranteed by Internet Corporation for Assigned Names and Numbers (ICANN)."

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.]

We do not issue OV certificates for natural persons and we will update the CPSs accordingly.

Fixed - this e-mail language has been removed

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.

It is unclear how this was addressed.

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".

Fixed - This has been modified to 12 months.

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.

Fixed - Section 4.9.4 of the CPS no longer lists the different revocation e-mail address.

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.

Yes, but please be aware of the significant discussions in the CA/Browser Forum around the Baseline Requirements not permitting the use of these additional fields within CA certificates. A lengthy thread was originally started at https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html and has seen significant discussion. Most recently, DigiCert and myself are working to clarify this in the BRs (as mentioned in https://cabforum.org/pipermail/validation/2019-December/001387.html ), but at present, this is not explicitly permitted.

While it is, admittedly, a lengthy discussion in the CA/Browser Forum, I encourage certSIGN to review that discussion (and the F2F minutes from Guangzhou), because one of the key takeaways has been the need for CAs to carefully review to make sure that what they do is actually and explicitly permitted by the BRs, and to raise issues or seek clarification when it's ambiguous.

See discussion above.

OCSP certificates use otherName subjectAltName]

This is a software limitation, at the moment we cannot issue OCSP certificates without specifying Subject Alternative Name

Similar to the above, the Baseline Requirements do not permit this, so it is a BR violation. That's why this was flagged.

It is unclear how this was resolved.

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.

Comment 24

[Valentin Necoara]

Thank you so much for your patience all the review and update process took us longer than expected.
Please find the responses to Comment 21 & 23

PKI Disclosure Statement

MEH

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).

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.

That's great!

Fixed

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.

Perhaps I misunderstood how certSIGN had approached its qualifications.
A 'simple' design, assuming one has the Root Certificate added to the TSL, is:
/--> Web CA
/---> E-mail CA
Root |----> Timestamping CA
---> Seal CA
--> Other CAs
At that point, if the Root is on the TSL as Qualified, then each of your (Web, Seal, Signature, Timestamp) certificates can also be qualified, as appropriate. Each of these sub-CAs can be separated by EKU, as appropriate, allowing compliance with the appropriate root program requirements audit for each EKU (e.g. Timestamping CA only subject to timestamping audits), rather than require your Qualified CA be subject to audits appropriate for (Web, E-amil, and timestamping)
Hopefully that makes sense! You can see how Microsoft applies audits-per-EKU at https://aka.ms/auditreqs . It also helps ensure compliance with Section 5.3 of the Mozilla Policy, and Section 4.A.11 of the Microsoft policy.

We are considering & analyzing how we can best create our future CAs that will be according to the best practices.

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 [5] 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 [5].
Initial Identity Validation: [PTC]: The verification methods shall follow those specified in clause 11 of the EVCG [4] and clause 3.2 of BRG [5].
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.

Thanks. This is a result of using the older version, EN 319 411-1 v1.1.1, which is why it was important to highlight the lack of keeping up to date. If you examine EN 319 411-1 v1.2.2, it's hopefully much clearer the expectations.

REG-6.2.2-03 [PTC]: The verification methods shall follow those specified in clause 3.2 of BRG [5].
REG-6.2.2-04 [EVCP]: The verification methods shall follow those specified in clause 11 of the EVCG [4].
There's much more expansive discussion within 1.2.2, and I think it's important to review this, as the face-to-face validation is not required for OVCP, and for EVCP, there is flexibility and recognition for verification other than physical presence.

Fixed

BAD

PKI Disclosure Statement states "Distribution and reproduction prohibited without authorization by CERTSIGN SA"

This will be removed from the document

Checked OK in version 2.15 of the PDS public pdf

Fixed (but not fixed in the CPS)

Corrected in CPS OV SSL v1.13.
Fixed

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.

I highlighted this particular restriction because in the event certSIGN makes an 'unintentional' mistake, such as a failure to appropriately validate domain names, it is seemingly disclaiming liability from any damage that may result. It sets up a significant burden with respect to establishing 'willful'.
This is not easily resolved, because it is understandable that certSIGN would wish to limit its liability to the maximum extent possible. It is something for the community to consider though: what might go wrong, particularly if certSIGN were negligent, and what resource, if any, might exist to Mozilla users?
The question of CA liability is understandably complex, and in some views, of questionable validity, so it may be that certSIGN and its legal department keep the existing language. Hopefully the above explanation, however, explains a bit more about the things I and other members of the community worry about, as an opportunity for how certSIGN might address that, if at all possible.

No change. See discussion below.

We updated the PDS on the liability limitation section.
Fixed

Web CA OV CPS

BAD

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.

Based on the earlier response regarding Initial Identity Validation, I'm not sure I'm confident that this was the case. I definitely want to make sure the January review carefully addresses this and any changes through EN 319 411-1 and related.

Replaced with simply "ETSI EN 319 411-1"

Fixed

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 1.4.2 now reads, "Certificates must only be used to the extent consistent with applicable law and for the purposes specified in chapter 1.4.1" Language in Section 1.4.1 has been edited to read, "The applications for which the certificate is deemed to be trustworthy shall be decided by the Relying Parties themselves based on the nature and purpose (incl. key usage) of the certificate, including any applicable limitation as written in the certificate. It is the responsibility of the Relying Party to decide for which purpose the certificates are considered trustworthy."
Section 1.4.1 was corrected from version 1.12 of the CPS OV SSL

Fixed

Section 2.2 of the CPS does not list the CAA domains (3.2.2.8 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.

This is a Baseline Requirements requirement (the particular disclosure in Section 2.2), and that's why I flagged this: it's indicative of a lack of keeping up to date with the BRs, even if you may have implemented CAA.

Fixed

Fixed

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.

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.

Fixed - Certsign's CPS now states it does not issue SSL OV certificates for natural persons. The description of the DN components is:
Mandatory
• Field O – name of the organization,
• Field L – residence city of the Subscriber,
• Field C – international abbreviation for country name.
Optional
• Field CN – Fully-Qualified Domain Name,
• Field OU – name of the organization’s department,
• Field S – county/district where the organization functions,
• Field streetAddress – Subscriber’s street address information.
This appears to be consistent with section 7.1.4.2.2 of the Baseline Requirements

Fixed

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.

Fixed

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.

Fixed

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.

We do not issue OV certificates for natural persons and we will update the CPSs accordingly.

Fixed - this e-mail language has been removed

Fixed

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.

It is unclear how this was addressed.
If the requester has a qualified certificate there is no need for a physical exchange, as specified in para 4.2 of the updated CPS:
• The request form (received via e-mail or from the web site www.certsign.ro) is electronically signed with a valid (not revoked or expired) qualified digital 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".

Fixed - This has been modified to 12 months.

Fixed

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.

Fixed - Section 4.9.4 of the CPS no longer lists the different revocation e-mail address.

Fixed

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.

Yes, but please be aware of the significant discussions in the CA/Browser Forum around the Baseline Requirements not permitting the use of these additional fields within CA certificates. A lengthy thread was originally started at https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html and has seen significant discussion. Most recently, DigiCert and myself are working to clarify this in the BRs (as mentioned in https://cabforum.org/pipermail/validation/2019-December/001387.html ), but at present, this is not explicitly permitted.
While it is, admittedly, a lengthy discussion in the CA/Browser Forum, I encourage certSIGN to review that discussion (and the F2F minutes from Guangzhou), because one of the key takeaways has been the need for CAs to carefully review to make sure that what they do is actually and explicitly permitted by the BRs, and to raise issues or seek clarification when it's ambiguous.

See discussion above.

We have the organizationIdentifier field set since we last updated the CAs, in 2017. We are closely following the discussions in the forum on the subject and we are prepared to plan & do what the CAs and the community will suggest that are the best approaches on this issue.

OCSP certificates use otherName subjectAltName

This is a software limitation, at the moment we cannot issue OCSP certificates without specifying Subject Alternative Name

Similar to the above, the Baseline Requirements do not permit this, so it is a BR violation. That's why this was flagged.

It is unclear how this was resolved.

We will revoke the OCSP certificates and re-issue them with corrected fields in the next version of our application. For now we are trying to understand the exact nature of this BR violation, as it is still ambiguous to us, and we do want to be sure we are correcting it properly.

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.

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.

The Baseline Requirements, v1.6.7, Section 2, requires that
The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification
Practice Statement that describes in detail how the CA implements the latest version of these Requirements.
The requirement is to publish a new version, even if there are no changes made, to help provide public assertion to the community that management has indeed reviewed.
Mozilla Root Store Policy, v2.7, as well as previous versions, further emphasizes and clarifies this Baseline Requirements rule, in Section 3.3
CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Re

The CPS could contain a statement that certSIGN publishes the CPS at least annually, even if there are no changes.
We updated all the CPS last versions with the following statement on Chapert 2:
certSIGN publishes the CPS at least annually, even if there are no changes.

Fixed

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 NCSSRs

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.

Right, but the identification of the physical persons is a requirement, at least with respect to EV, and so it's performing a requirement of the CA, which means it is a Delegated Third Party. In the context of EN 319 411-1, v1.1.1, that's similarly an expression of a requirement on the CA (for PTC), and thus would expect that they are Delegated Third Parties.
That said, this is an area of significant complexity here, so I want to be careful about encouraging you to take any particular steps. For example, there's understandable complexity and debate about whether they are DTPs. The primary recommendation to satisfy this concern is to be very explicit within your CPS about the role these notaries play, how the CA determines these notaries fulfill their role (and/or how these notaries are verified). If the CA determines they're not Delegated Third Parties, which may very well be an acceptable answer, being very clear and explicit about this at least helps the community understand.

Instances of "notary" were removed from sections 3.2.3 and 4.2.

We updated also in the CPS OV SSL v1.13 - section 1.3.5
Fixed

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)

Attestation Letter is just one of the possibilities to validate Identity, as mentioned also in BR.

Correct. Although permitted, the use of Attestation Letters can easily lead to incorrect information or abuse. This is why they were forbidden from use in the domain name validation process. CAs which rely on Attestation Letters benefit from documenting their process and procedures for detecting and/or preventing abuse (for example, misuse of signed letterhead, forgery, entities not actually in the legal profession, etc). In short, if I (a non-lawyer) were to write an attestation letter for myself, how would that be detected or prevented, and is that clear from the CPS?
This emphasizes a broader point for the CPS, as part of your review, which is for elements that are risky - such as attestation letters, public notaries, use of third-party data sources, or any other element where the CA "trusts" someone else - having clarity that the CA has procedures to detect and prevent abuse, and potentially disclosing some of those procedures, is very useful. It helps demonstrate that a CA is aware of the potential risks, and mitigates them, making it easier for others to trust the CA and the CA's decision making process.

"Attestation Letter" has been removed from Section 3.2.2.1, which is re-written to describe the required documents and procedure to be followed by the RA. However, it is a little unclear what is meant by the "Template statement of the domain’s owner." What language would the statement contain?

We updated in the CPS OV SSL v1.13
In Section 3.2.2.1 we detailed the expression "Template statement of the domain's owner"
Also in section 3.2.2.2 Attestation letters were replaced with other options, accoding to BR 3.2.1 & 3.2.2

Fixed

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.

Some approaches that other CAs have used is to use appendices or supporting documents, similarly made publicly available, to help provide transparency. The previous clarifications hopefully help explain the goal of these CP/CPS reviews and why concrete information is valuable and useful.

Without disclosing trade secrets or information security techniques, certSIGN should consider providing a more detailed explanation in its CPS of some actual practices it uses to handle high risk requests (rather than just repeating requirements language).

Updated in CPS OV SSL v1.13 on 4.2.1
We added the main actions that our operators take according to our internal procedures. The detailed steps and techniques are still within our internal instructions as these are differentiators between CAs performances.

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.

Checked OK in CPS Web CA for OV SSL

Fixed

Fixed

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.

Defined in 6.3.2 Certificate operational periods and key pair usage periods, as:
Generally, beginning date of the certificate validity period complies with the date of its
issuance.

Fixed

Fixed

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.

Thanks. I think your explanation may be clearer, as it seems you revoke not because the employment status changed, but because a natural or legal person who was previously authorized by the domain holder, may no longer be authorized.

Fixed

Fixed

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.

Fixed

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.

Section 4.9.10 now states, "For the status of Subscriber Certificates, the CA updates information provided via an Online Certificate Status Protocol at list [sic] every hour. OCSP responses from this service MUST have a maximum expiration time 24h."

CSP OV SSL v1.13 updated
Fixed

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).

In particular, the concern was about requirement 1.c within the Network and Certificate System Security Requirements, v1.3, that
Maintain Root CA Systems in a High Security Zone and in an offline state or air-gapped from all other networks;
Thus, it's not sufficient to have a security procedure in place to protect such systems between zones, but that at least with respect to the High Security Zone and the Secure Zone, there must be physical separation, and either offline or, when online, physically air-gapped.

Maintain Root CA Systems in a High Security Zone and in an offline state or air-gapped from all other networks;

Updated in CPS OV SSL v1.13.
Fixed

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.

Fixed
Question: In the profile for the OCSP server certificate (Table 7.5 on page 82), the AIA URL says www.certsign.ro/certcrl/certsign-qualifiedca.crt shouldn't it be http://www.certsign.ro/certcrl/certsign-webca.crt or is the Qualified CA being used?

Corrected the URL in CPS OV SSL v1.13
Fixed

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.

Thanks, that's an important clarification (the lack of pre-computed responses). In general, pre-computed responses may be the only way for a CA to satisfy the requirements of the Baseline Requirements around availability. This is where the previously-mentioned hierarchy split may be useful, to ensure that at least for TLS, pre-computed responses can be used and high-availability can be delivered.
To be clear: using pre-computed responses is not mandatory explicitly, but it significantly reduces the risk of a BR violation. A BR violation could occur for a number of reasons, such as incorrect key protection for the OCSP responder (as the BRs require these be protected like intermediate CAs) or through a service outage caused by DoS.
Removing nonces, and adopting precomputed, at least for TLS, may help ensure your system is robust and scalable.

Currently we are in compliance with the existing requirements of the CAB Forum, with audits performed both from WebTrust and ETSI auditors.
Still, we may consider removing nonces and adopting precomputed responses, in close relation to our business strategy and according to the company operational plans.
Fixed

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?

I highlight this because this is a general point of confusion between the application of WebTrust and ETSI. While browsers do not require the detailed audit report, the expectation is that the result of the audit will still disclose any non-conformities that were detected, both minor and major, and which may involve disclosing that a security issue was discovered. The browsers will then work with the CA to understand the nature of the issue and how it was mitigated, but the expectation is that it will be disclosed if something is found.

It does not appear that this issue has been fully resolved. However, there is an expectation that security and compliance are reported on a timely basis. Section 5.7.1 could be amended to state that in the case of incident, "The security incident management procedure also specifies how to notify the appropriate parties in line with the applicable regulatory rules of any breach of security or loss of integrity that has a significant impact on the trust service provided and <u>or</u> on the personal data maintained therein within 24 hours of the breach being identified. In case of security incident, internal procedures are used. The procedures include the notification of <u>Application Software Suppliers, certSIGN's auditors, and</u> the Supervisory body.

Updated in 9.3.1 in CPS OV SSL v1.13
Fixed

Comment 25

[Ben Wilson]

I believe this is ready to move into the 3-week discussion period, but I was wondering whether to wait for the updated audit report, which is about due. Do we know when we might be seeing that?

Comment 26

[Valentin Necoara]

The audit was performed, It took place from 2020-02-10 until 2020-02-14 and covered the period from 2019-02-15 - 2020-02-14.
The attestation letter is already published in a draft form and will be in its final form in max 2 weeks:
https://bugzilla.mozilla.org/attachment.cgi?id=9142635

Comment 27

[Gabriel PETCU]

Attachment: Non-conformities found and corrected on LSTI audit Feb2020

Here it is the signed document from the LSTI auditor after the review and closure of the six minor non-conformities found during the audit.

Comment 28

[Ben Wilson]

On 28-May-2020 I announced an intention to approve the inclusion request for this root CA. See https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/z9EQ3HtrAAAJ
There have been no comments in opposition thus far, and I believe it is now appropriate to begin the process of adding this root CA into NSS.

Comment 29

[Ben Wilson]

The discussion period for this request has ended. I believe that all questions have been answered, so I am recommending approval of this request.
Link(s) to the discussion:
https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ

Comment 30

[Kathleen Wilson]

On behalf of Mozilla I approve this request from certSIGN to include the following root certificate:

** 'certSIGN ROOT CA G2' (Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 31

[Kathleen Wilson]

I have filed bug #1645186 against NSS and bug #1645192 against PSM for the actual changes.

Comment 32

[Gabriel PETCU]

Attachment: 2017-03-17-Initial-Full-Audit-Stage1-1612-9.pdf

Initial-Full-Audit-Stage1-2017

Comment 33

[Gabriel PETCU]

Attachment: 2017-06-27-Initial-Full-Audit-Stage2-1612-10.pdf

Initial-Full-Audit-Stage2-2017

Comment 34

[Gabriel PETCU]

Attachment: 2018-07-23-Full-Audit-1612-52.pdf

Full-Audit-2018

Comment 35

[Gabriel PETCU]

Attachment: 2019-06-13-Full-Audit-1612-120.pdf

Full-Audit-2019

Comment 36

[Gabriel PETCU]

Attachment: 2020-04-29-Full-Audit-1612-163.pdf

Full-Audit-2020

Comment 37

[Gabriel PETCU]

Attachment: 2021-05-10-Full-Audit-1612-222.pdf

Full-Audit-2021