Open Bug 1474556 Opened 3 years ago Updated 18 days ago

Add UAE Global Root CA G4 E2 Root Certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: ahmed.alali, Assigned: bwilson, NeedInfo)

Details

(Whiteboard: [ca-cps-review] - Pending CPS Updates 2020-09-14)

Attachments

(7 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15
Attachment #8990947 - Attachment filename: UAE Global Root CA G4 E2_CA Information.docx → UAE Global Root CA G4 E2_CA Information
Attachment #8990947 - Attachment description: UAE Global Root CA G4 E2_CA Information.docx → UAE Global Root CA G4 E2_CA Information
Attachment #8990947 - Attachment filename: UAE Global Root CA G4 E2_CA Information → UAE Global Root CA G4 E2_CA Information.docx
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying]
The attached document shows the information that has been verified. Search the document for "NEED" to see where further clarification is needed.

In particular, the CA needs to:

1) List permitted CAA Domains in CP/CPS
https://wiki.mozilla.org
/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue.

2) Clarify Government subCA, since things like BR Commitment to comply and audit criteria are different in that CPS.
CPS indicates that the Government subCAs or not constrained.
Mozilla trusts at the root cert level, such that all subCAs chaining up to that root cert are trusted, and so must fully comply with Mozilla's root store policy and the BRs. If the Government subCA is not able to fully comply with Mozilla requirements, then this CA will need to separate out the two hierarchies.

3) Provide sufficient information about how the CA performs Domain Validation in the CP/CPS.
https://wiki.mozilla.org
/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership

4) Provide sufficient information about how the Ca verifies Email Address Control in the CP/CPS.
https://wiki.mozilla.org
/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

5) Update OCSP to meet Baseline Requirements
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#OCSP
Fix all errors listed here:
https://certificate.revocationcheck.com/good.pki.desc.gov.ae

6) Mozilla has the ability to name constrain root certs; e.g. to *.gov or *.mil. CAs should consider if such constraints may be applied to their root certs.


The biggest concern I have about this CA is that root also signs Unconstrained Root CAs for Government entities. These may be externally-operated by the government entities, and do not appear to be required to follow the BRs and be annually audited according to Mozilla's policy and the BRs. This is a show-stopper for inclusion in Mozilla's program.
Whiteboard: [ca-verifying] → [ca-verifying] - KW Comment #4 2018-09-13
Dear Kathleen,

This to confirm receiving your feedback on the information we provided. We will respond to each point at the earliest.
However, we would like to respond to the concern that you raised on the unconstrained Root CAs for Government entities. Please note that these CAs will be operated by DESC and not by other entities, which is mentioned in the Root CA CPS at section 1.1, 1.3.1 and 1.3.3.  All the Subordinate CAs that will be issued under CAs will be technically constrained as mentioned in the CPS as well.

Kind Regards,
Ahmed Al Ali
Correction:

Please replace this statement “All the Subordinate CAs that will be issued under CAs will be technically constrained as mentioned in the CPS as well.” With

“All the Subordinate CAs that will be issued under these government root CAs will be technically constrained as mentioned in the CPS as well.”


(In reply to Ahmed Al Ali from comment #5)
> Dear Kathleen,
> 
> This to confirm receiving your feedback on the information we provided. We
> will respond to each point at the earliest.
> However, we would like to respond to the concern that you raised on the
> unconstrained Root CAs for Government entities. Please note that these CAs
> will be operated by DESC and not by other entities, which is mentioned in
> the Root CA CPS at section 1.1, 1.3.1 and 1.3.3.  All the Subordinate CAs
> that will be issued under CAs will be technically constrained as mentioned
> in the CPS as well.
> 
> Kind Regards,
> Ahmed Al Ali
Dear Ahmed Al Ali,

I have updated my documentation about this root inclusion request, after finding the information that you pointed out in comment #5 and #6.

Mozilla's process has changed from using PDF documents to directly pulling information from the Root Inclusion Case in the CCADB. The information for this root inclusion request is available at the following URL.

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

The other items listed in Comment #4 are still needed.  

Thanks,
Kathleen
QA Contact: kwilson
Whiteboard: [ca-verifying] - KW Comment #4 2018-09-13 → [ca-verifying] - KW Comment #7 2018-11-14
Dear Kathleen
 
Please find our detailed response to all the points raised in comment #4. I am still attaching our responses as a PDF, I am assuming you only have a write permission to update the online Root Inclusion Case. Please let me know if I should otherwise.
 
Kind Regards
Ahmad Al Ali
Dear Kathleen
 
Please find our detailed response to all the points raised in comment #4. I am still attaching our responses as a PDF, I am assuming you only have a write permission to update the online Root Inclusion Case. Please let me know if I should otherwise.
 
Kind Regards
Ahmad Al Ali
With respect to responding with OCSP status REVOKED for non-issued certificates per RFC 6960, do your OCSP responses contain the id-pkix-ocsp-extended-revoke extension that the RFC requires for that condition?
I see now that it does; nevermind.
(In reply to Ahmed Al Ali from comment #9) 
> Please find our detailed response to all the points raised in comment #4.

I have updated the information in the Root Inclusion Case in the CCADB. Please double-check that the information is correct.

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

Mozilla is moving to a process in which CAs requesting inclusion in our program will be given CA Community access to the CCADB, and be asked to enter their CA hierarchy into the system. I have sent email to you about this.
Whiteboard: [ca-verifying] - KW Comment #7 2018-11-14 → [ca-verifying] - KW Comment #11 2018-12-13
Intermediate CAs have been added to the CCADB.

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

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

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.

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW Comment #11 2018-12-13 → [ca-cps-review] - KW 2019-01-08

I have performed a preliminary review of this request and have the following questions and concerns:

  • The Devices intermediate is intended for TLS and the Corporate intermediate is intended for S/MIME, but neither is EKU constrained and their respective CPSes only cover one usage or the other. The binding from each certificate to the respective CPS is weak - as far as I can tell, only the name of the CPS is used to indicate the applicable certificate. This creates the possibility the each issuing CA could claim to be adhering to whichever CPS is convenient.
  • The BR audit statement lists policies applicable to each intermediate in the scope in Appendix A. From this, it’s not 100% clear if the Corporate CA is in-scope for the BR audit.
  • The Corporate CA CPS, which does not cover TLS Certificates, states in section 1.6.3 that it complies with the BRs.
    Devices CA CPS section 3.2.4 contains an IP address validation method that is forbidden after July 31 due to ballot SC7.
  • Is the RKGC audit report available? If so, please provide it.
  • Root is valid from 6-Feb 2018 and intermediates are valid from 14-Feb 2018, but period for first period-of-time audit doesn’t begin until 28-Feb 2018, leaving a 2-week audit gap.
  • Devices CPS section 4.9.1 enumerates reasons for revoking a certificate, but does not list all of the reasons required by the BRs. The Subordinate CAs CP also lists revocation reasons without providing a complete set.
  • Section 4.9 of the Root CA CPS contains a subheading named “Subscribers” that contains no content.
  • Do any Dubai Government Entity Issuing CAs exist at this time? Are any currently planned?
  • The Corporate CA CPS permits delegated RAs in section 1.3.3 but does not exclude email validation from delegation (section 3.2.3). Delegating email validation is listed as a Forbidden Practice [1].
  • The Dubai Government Entity Issuing CAs CPS lacks a commitment to comply with the BRs.
  • Mozilla Policy section 5.2 forbids CA generation of Subscriber key pairs. Devices CPS section 6.1.1.2 permits local RAs to do this, which I believe violates the intent if not the letter of Mozilla policy. The Dubai Government Entity Issuing CAs CPS section 6.1.1.2 also grants the right to generate subscriber key pairs without restriction.
  • Section 1.4.1 of the Subordinate CAs CP and CPS' grants DESC the right to issue short-lived “test” certificates. The implication is that these certificates do no need to be validated in accordance with Mozilla policies.
  • Devices CPS section 7.1.3 describes the CN of a “VPN certificate” as “System unique common name or DNS name or IP address that are applicable, potentially linked to the Subject Alternative Name extension” This implies that certificates which are in-scope for the Bus and Mozilla policy may contain internal domain names in the CN field.
  • What is the purpose of the “Verification Response Signing Certificate” profile described in section 7.1.5, and why is there no EKU extension? This profile appears to be in scope for Mozilla policy and is clearly not BR compliant (36 month validity).
  • Section 1.5.2 of these CP/CPSs does not provide the clear instructions for problem reporting required by BR 4.9.3.

I would recommend that you fix or explain as many of these issues as possible before I begin the public review period for this request.

Please reply if you would like to make changes to the CP/CPS' before the public discussion.

Flags: needinfo?(ahmed.alali)

Dear Wayne

Thank you for your feedback.
This is to acknowledge receiving your comments, our team will work on them so that we revert back to you at the earliest.

Flags: needinfo?(ahmed.alali)
Whiteboard: [ca-cps-review] - KW 2019-01-08 → [ca-cps-review] - Pending CPS Updates 2019-07-28
Attached file RKGC Audit Report
Assignee: wthayer → bwilson

I have reviewed the comments and responses in this bug, as well as DESC’s current CPs and CPSes, here are my additional comments to the Root CPS (v.1.3), Devices CPS (v.1.5) and Corporate CPS (v.1.3), downloaded from https://ca-repository.desc.gov.ae/.

1.3.1 Dubai Root CA

Section 1.1 of the Mozilla Root Store Policy says that technical constraints consist of “an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; and/or: name constraints which do not allow Subject Alternative Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, rfc822Name”. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope

Section 1.3.1 of the Root CPS says, “This excludes technically constrained Dubai Government entity issuing CAs, for which the particular Dubai government entity will maintain its own set of policies and practices aligned with the applicable CP and CPS as published by the Dubai PKI Policy Authority. Through its Policy Authority, DESC has ultimate control.”

How will these subordinate CAs be “technically constrained”? Will all signed CAs be both EKU-constrained and name-constrained? I did not see name constraints anywhere in section 3.1 or section 7.1. Will other constraints not listed above be implemented? (DESC should also consider replacing its current existing subordinate CAs with ones that have serverAuth and secureMail EKU constraints, as currently required by root programs for newer CA certificates.)

Also, it is not entirely clear how the Dubai PKI Policy Authority will ensure that other entities' policies and practices are aligned with the CPs and CPSes that Mozilla has reviewed as part of this trust-bit decision.

1.3.2 Registration Authorities

Section 1.3.2. of the Baseline Requirements says, “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, ….”). Also, section 2.2.2 of Mozilla Policy states, “The CA SHALL NOT delegate validation of the domain portion of an email address.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

While the CPSes say that the “DESC RA” performs these functions, there is inadequate language in the CPSes to ensure that domain validation is not delegated. It is recommended that explicit language be added to either section 1.3.2. or section 3.2.4 of the Devices CPS that DESC does not delegate domain validation.

Also, section 3.2.3 of the Corporate CPS says an LRA performs email validation. For example, this sentence, “The verification could be made based on the entity’s internal employee records where emails are formally assigned/specified for each employee” assumes that DESC first validates that the domain is owned/controlled by the employer. This should be stated. Also, how will DESC ensure that the LRA is performing the Challenge-Response mechanism properly? It seems like DESC could build, manage and operate a single Challenge-Response mechanism without having it operated by a third party LRA.

3.2.4 Authentication of Domain name

Mozilla Root Store Policy 2.2.3 requires specific reference to the domain/IP address validation methods used: “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

Section 3.2.4 of the Devices CPS needs to be more specific. It must clearly specify the particular methods from section 3.2.2.4 of the Baseline Requirements that are being used. A similar CPS revision should be made to that same section for the IP-address validation described in section 3.2.4 of the Devices CPS, i.e. specific reference should be made to those provisions of 3.2.2.5 of the Baseline Requirements that are used for IP-address validation.

4.2.2. Approval or rejection of certificate applications

Section 2.1.3 of Mozilla Policy requires that CAs “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations

It would be good to add, “Multi-factor authentication is implemented whenever RA/LRA officers approve certificate applications for issuance.” Otherwise, DESC should then explain “the technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.”

4.9.1 Circumstances for Revocation

Section 6.1 of the Mozilla Root Store Policy says, “CAs MUST revoke certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#61-ssl

Sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements were modified in the last year. DESC should revisit and review the revocation reasons stated in sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. These BR sections can be helpful in ensuring that DESC revokes end entity and subordinate certificates on a timely basis. The Devices CPS should be updated with these reasons and timelines from BR 4.9.1.1 and 4.9.1.2.

4.10 Certificate Status Services

I did not see OCSP issuance and expiration timeframes as set forth in Mozilla Policy Section 6, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation:

For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service:

· it MUST update that service at least every four days; and

· responses MUST have a defined value in the nextUpdate field, and it MUST be no more than ten days after the thisUpdate field; and

· the value in the nextUpdate field MUST be before or equal to the notAfter date of all certificates included within the BasicOCSPResponse.certs field or, if the certs field is omitted, before or equal to the notAfter date of the CA certificate which issued the certificate that the BasicOCSPResponse is for.

DESC should consider adding similar language to section 4.10.

Whiteboard: [ca-cps-review] - Pending CPS Updates 2019-07-28 → [ca-cps-review] - Pending CPS Updates 2020-04-22

Dear Ben,

Thank you for the comments. We appreciate your follow up on the status of our CA application.

Please notice that we are currently in the middle of the annual review/update of our CP/CPS. We expect to complete the review and get the approval by PA by Mid-May . We will ensure that below comments are addressed in the ongoing review and we will provide you with our responses to your comments and how we address them in the third week of May.

Please let us know if you need any additional information from our side.

Dear Ben,

Please note that we have updated our CP/CPS on our repository https://ca-repository.desc.gov.ae. Please check and confirm wither it answers your questions and let us know if you need any additional information from our side.

Thank you for providing me with your updated audit and policy documentation.

Please see my follow-up comments below.

I have reviewed the comments and responses in this bug, as well as DESC’s current CPs and CPSes, here are my additional comments to the Root CPS (v.1.3), Devices CPS (v.1.5) and Corporate CPS (v.1.3), downloaded from https://ca-repository.desc.gov.ae/.

This is a review of the Root CPS (v.1.4), Devices CPS (v.1.6) and Corporate CPS (v.1.4) (available at https://ca-repository.desc.gov.ae/)

1.3.1 Dubai Root CA

How will these subordinate CAs be “technically constrained”? Will all signed CAs be both EKU-constrained and name-constrained? I did not see name constraints anywhere in section 3.1 or section 7.1. Will other constraints not listed above be implemented? (DESC should also consider replacing its current existing subordinate CAs with ones that have serverAuth and secureMail EKU constraints, as currently required by root programs for newer CA certificates.)

Also, it is not entirely clear how the Dubai PKI Policy Authority will ensure that other entities' policies and practices are aligned with the CPs and CPSes that Mozilla has reviewed as part of this trust-bit decision.

I am not sure that the foregoing questions have been adequately addressed / answered. I am concerned that the Dubai Root might be considered a Super CA. See https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs. Maybe the root should not be added to the Mozilla Trust Store and instead the Devices CA should be added with the Websites bit and the Corporate CA added with the secure email trust bit enabled?

1.3.2 Registration Authorities

Section 1.3.2. of the Baseline Requirements says, “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, ….”). Also, section 2.2.2 of Mozilla Policy states, “The CA SHALL NOT delegate validation of the domain portion of an email address.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

While the CPSes say that the “DESC RA” performs these functions, there is inadequate language in the CPSes to ensure that domain validation is not delegated. It is recommended that explicit language be added to either section 1.3.2. or section 3.2.4 of the Devices CPS that DESC does not delegate domain validation.

This section 1.3.2 of the Devices CPS appears to have been fixed to clarify that only the DESC RA performs domain validation.

Also, section 3.2.3 of the Corporate CPS says an LRA performs email validation. For example, this sentence, “The verification could be made based on the entity’s internal employee records where emails are formally assigned/specified for each employee” assumes that DESC first validates that the domain is owned/controlled by the employer. This should be stated. Also, how will DESC ensure that the LRA is performing the Challenge-Response mechanism properly? It seems like DESC could build, manage and operate a single Challenge-Response mechanism without having it operated by a third party LRA.

It appears that section 3.2.3 of the Corporate CPS was changed in an attempt to clarify that domain control would be done according to section 1.3.3. However, it is unclear from a review of section 1.3.3. of the Corporate CPS exactly how that would be done. So I don't think this resolves the issue. Also, why was language about the challenge-response mechanism removed? That was not the intent of my previous comment. I was asking for more explanation about DESC oversight of the LRA process. This still needs more detailed explanation of the issuance process for email certificates. Is this done solely by the DESC RA, or are some steps performed by the LRA?

3.2.4 Authentication of Domain name

Mozilla Root Store Policy 2.2.3 requires specific reference to the domain/IP address validation methods used: “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

Section 3.2.4 of the Devices CPS needs to be more specific. It must clearly specify the particular methods from section 3.2.2.4 of the Baseline Requirements that are being used. A similar CPS revision should be made to that same section for the IP-address validation described in section 3.2.4 of the Devices CPS, i.e. specific reference should be made to those provisions of 3.2.2.5 of the Baseline Requirements that are used for IP-address validation.

Section 3.2.4 of the Devices CPS has been improved with more specificity about the process.

4.2.2. Approval or rejection of certificate applications

Section 2.1.3 of Mozilla Policy requires that CAs “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations

It would be good to add, “Multi-factor authentication is implemented whenever RA/LRA officers approve certificate applications for issuance.” Otherwise, DESC should then explain “the technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.”

I could not find where it is stated in the CPS that multi-factor authentication (or other technical controls implemented) for accounts capable of causing certificate issuance. This still needs to be addressed.

4.9.1 Circumstances for Revocation

Section 6.1 of the Mozilla Root Store Policy says, “CAs MUST revoke certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#61-ssl

Sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements were modified in the last year. DESC should revisit and review the revocation reasons stated in sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. These BR sections can be helpful in ensuring that DESC revokes end entity and subordinate certificates on a timely basis. The Devices CPS should be updated with these reasons and timelines from BR 4.9.1.1 and 4.9.1.2.

Language has been added to section 4.9.4 of the Root CA CPS for 7-day revocation of intermediate CAs. Section 4.9.5 of the Devices CPS says that revocation requests will be processed within 24 hours. However, it also states that "manual certification revocation requests must be submitted to DESC during working hours." This language is unclear and may lead DESC into delaying revocation past 24 hours. If that occurs, then Mozilla considers that delay an incident, and an incident report will need to be filed in Bugzilla.

4.10 Certificate Status Services

I did not see OCSP issuance and expiration timeframes as set forth in Mozilla Policy Section 6, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation:

For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service:

· it MUST update that service at least every four days; and

· responses MUST have a defined value in the nextUpdate field, and it MUST be no more than ten days after the thisUpdate field; and

· the value in the nextUpdate field MUST be before or equal to the notAfter date of all certificates included within the BasicOCSPResponse.certs field or, if the certs field is omitted, before or equal to the notAfter date of the CA certificate which issued the certificate that the BasicOCSPResponse is for.

DESC should consider adding similar language to section 4.10.

Section 4.10.1 of the Devices CPS now states that OCSP responses have a next update field of no greater than 26 hours.

Additional Comments

1 - Future subordinate CAs/issuing CAs under the Dubai Root must specify applicable EKUs in accordance with section 7.1.2.2 of the Baseline Requirements. This is because "While RFC 5280, Section 4.2.1.12, notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of subordinate certificates, as implemented by a number of Application Software Suppliers." The Appendix I certificate profile for new subordinate CAs should be updated to require applicable EKUs.

2 - Have you considered expressly prohibiting the use of certificates (see CPS section 1.4.2) for traffic management or man-in-the-middle attacks? Most CAs include the following language "Certificates shall not be used for man-in-the-middle (MITM) or traffic management of domain names or IPs that the certificate holder does not legitimately own or control. Such certificate usage is expressly prohibited."

I continue to conduct my CPS review and will provide you with additional feedback.

Whiteboard: [ca-cps-review] - Pending CPS Updates 2020-04-22 → [ca-cps-review] - Pending CPS Updates 2020-09-14

This is a request for an update on the status of your efforts to update your CP / CPS and/or responses to Comment #24 above.

Flags: needinfo?(ahmed.alali)
You need to log in before you can comment on or make changes to this bug.