Open Bug 1403453 Opened 2 years ago Updated 22 days ago

Add certSIGN Root CA G2 certificate

Categories

(NSS :: CA Certificate Root Program, task)

3.32
task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: cristian.garabet, Assigned: ryan.sleevi)

Details

(Whiteboard: [ca-cps-review] - Pending CPS updates 04-Dec 2019)

Attachments

(1 file)

62.26 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622
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
Assignee: kwilson → awu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - Need BR Self Assessment
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson

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

Flags: needinfo?(kwilson)

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.

Flags: needinfo?(kwilson)
QA Contact: kwilson

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

Andrew.

Flags: needinfo?(kwilson)

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

Flags: needinfo?(kwilson)

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.

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.

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

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

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

Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - KW 2019-03-28 - Comment #10

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.

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

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-03-28 - Comment #10 → [ca-cps-review] - KW 2019-04-01

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
Assignee: wthayer → ryan.sleevi
Flags: needinfo?(kwilson)
Flags: needinfo?(kwilson) → needinfo?(wthayer)

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

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.

Flags: needinfo?(wthayer)

(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?

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

Er, yes, apologies for that typo.

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

Thank you guys!

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.

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.

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

Whiteboard: [ca-cps-review] - KW 2019-04-01 → [ca-cps-review] - Pending CPS updates 04-Dec 2019
You need to log in before you can comment on or make changes to this bug.