1474556 - Add UAE Global Root CA G4 E2 Root Certificate

Status: RESOLVED WONTFIX

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

Description

[Ahmed Al Ali]

Attachment: UAE Global Root CA G4 E2_CA Information

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

Comment 1

[Ahmed Al Ali]

Attachment: CA's BR Self Assessment

Comment 2

[Ahmed Al Ali]

Attachment: Root CA Certificate file

Comment 3

[Kathleen Wilson]

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

Comment 4

[Kathleen Wilson]

Attachment: 1474556-CA-Information-Sept13-2018.pdf

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.

Comment 5

[Ahmed Al Ali]

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

Comment 6

[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

Comment 7

[Kathleen Wilson]

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

Comment 8

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

Comment 9

[Ahmed Al Ali]

Attachment: DESC Response on Mozilla comment #4_15112018.pdf

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

Comment 10

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

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?

Comment 11

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

I see now that it does; nevermind.

Comment 12

[Kathleen Wilson]

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

Comment 13

[Ahmed Al Ali]

Intermediate CAs have been added to the CCADB.

Comment 14

[Kathleen Wilson]

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.

Comment 15

[Ahmed Al Ali]

Please find below the renewed audit reports published at CPA:

WebTrust for CA (standard audit)
https://www.cpacanada.ca//GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=230858

SSLBR
https://www.cpacanada.ca//GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=230859

Code Signing
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?AttachmentID=230860

Comment 16

[Wayne Thayer]

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.

Comment 17

[Ahmed Al Ali]

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.

Comment 18

[Ahmed Al Ali]

Attachment: RKGC Audit Report

Comment 19

[Ahmed Al Ali]

Attachment: DESC Response on Mozilla comments recieved on 24th July 2019

Comment 20

[Ben Wilson]

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.

Comment 21

[Ahmed Al Ali]

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.

Comment 22

[Ahmed Al Ali]

Please find below the renewed audit reports published at CPA:

WebTrust for CA (standard audit)
https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=241452

SSL BR
https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=241453

Code Signing
https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=241461

Comment 23

[Ahmed Al Ali]

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.

Comment 24

[Ben Wilson]

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.

Comment 25

[Ben Wilson]

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.

Comment 26

[Ahmed Al Ali]

Dear Ben,

We would like to let you know that we have updated our CP/CPS to address your latest comments, the final version is going to approved during the policy authority meeting planned this week then it will be published next week.

Please accept our apologies for the delay, that was out of our control due to circumstances caused by the pandemic. However the situation is getting back to normal and we have our team now fully focused and dedicated to support your comments in order to progress the processing our bug report. We would like also to emphasis the importance of having Mozilla’s approval on our CA and how crucial it is to our PKI program. Hence we have not only dedicated our existing team to follow up on this case, we also augmented the team to ensure timely and quality responses.

Last but not least, we noticed that you changed the priority of our bug, we hope that this can be reverted back once you review the updated documents. Otherwise please let us know if there is anything else is expected from our side.

Comment 27

[Ahmed Al Ali]

Dear Ben,

This is to let you know the CP/CPs updates are under the policy authority approval which is taking longer than expected, however it should be granted by early next week hence we expect to publish the new versions during that coming week at latest.

Comment 28

[Ahmed Al Ali]

Attachment: DESC response to Mozilla comment #24

Dear Ben,

Please find attached our responses to Comment #24.
Should you have any further clarifications or comments, please let us know.

Kind Regards,

Comment 29

[mohamed abdelshahid]

Dear Ben,

This is to follow up with your review on our latest response.

We also wanted to let you know that we are working on the following changes:

1. Address the extkeyUsage requirements specified under section 7.1.2.2 of the SSL BR for subordinate CA certificates,
2. For the CAs falls under the scope of Mozilla’s Root Store policy, ensure presence of EKU extension in all end-entity certificates as specified in section 5.2 “Forbidden and Required Practices”,
3. Various enhancements and detailing of practices in the CPS documents for a clearer alignment of applicable requirements.

In relation to point No. 1 above, there are internal discussions going with PA for assessing the stop of issuing email protection certificates. Please note that we don’t currently have any active certificates of that type anyway due to the lack of business demand. We will keep you posted on updates related to this matter.

Kind Regards,
Mohamed Abdelshahid

Comment 30

[mohamed abdelshahid]

(In reply to mohamed abdelshahid from comment #29)

Dear Ben,

This is to follow up with your review on our latest response.

We also wanted to let you know that we are working on the following changes:

1. Address the extkeyUsage requirements specified under section 7.1.2.2 of the SSL BR for subordinate CA certificates,
2. For the CAs falls under the scope of Mozilla’s Root Store policy, ensure presence of EKU extension in all end-entity certificates as specified in section 5.2 “Forbidden and Required Practices”,
3. Various enhancements and detailing of practices in the CPS documents for a clearer alignment with applicable requirements.

In relation to point No. 1 above, there are internal discussions going with PA for assessing the stop of issuing email protection certificates. Please note that we don’t currently have any active certificates of that type anyway due to the lack of business demand. We will keep you posted on updates related to this matter.

Kind Regards,
Mohamed Abdelshahid

Comment 31

[Ben Wilson]

Thanks for the update. Do you have access to the CCADB Case #318 where you can update all of the information (audit and CPS) to bring it current?
Here is the URL https://ccadb.force.com/5001J00000bv2dCQAQ
Thanks,
Ben

Comment 32

[mohamed abdelshahid]

Information (Audit reports and CPS) has been updated in the CCADB.

Kind Regards,
Mohamed Abdelshahid

Comment 33

[mohamed abdelshahid]

Dear Team,

Few updates please:

1. We would like to seek only the "Server Authentication" trust bit only, not the "Secure Email" anymore

2. We are not able to update the references to the latest CP/CPS under Root CA and Case #318 at the CCADB, so can you please help us to update those references as follows:
   Root CA CP/CPS:
   https://ca-repository.desc.gov.ae/Repository/source/cps/DubaiPKI-DubaiRootCA-CertificationPracticeStatement_v1.6.pdf
   Subordinate CAs CP:
   https://ca-repository.desc.gov.ae/Repository/source/cp/DubaiPKI-DESCSubordinateCAs-CertificatePolicy_v1.6.pdf
   Devices CA CPS:
   https://ca-repository.desc.gov.ae/Repository/source/cps/DubaiPKI-DevicesCA-CertificationPracticeStatement_v1.8.pdf
   Corporate CA CPS:
   https://ca-repository.desc.gov.ae/Repository/source/cps/DubaiPKI-CorporateCA-CertificationPracticeStatement_v1.7.pdf

3. We have added the new Intermediate CAs (Corporate CA & Devices CA) to the CCADB, the new certificates have got the EKU extension

4. We are going to establish soon a Timestamping CA and Code Signing CA dedicated for Timestamping certificates and Code Signing certificates respectively. Once the key generation ceremony is conducted, we will update the CCADB.

Kind Regards,
Mohamed Abdelshahid

Comment 34

[mohamed abdelshahid]

Dear Mozilla team,

The Timestamping CA and Code Signing CA have been established and the CCADB was updated. Please find below the corresponding CPS documents for both CAs.

https://ca-repository.desc.gov.ae/Repository/source/cps/DubaiPKI-CodeSigningCA-CertificationPracticeStatement_v1.0.pdf
https://ca-repository.desc.gov.ae/Repository/source/cps/DubaiPKI-TimestampingCA-CertificationPracticeStatement_v1.0.pdf

We are looking forward to hear from you on next steps.

Kind Regards,
Mohamed Abdelshahid

Comment 35

[mohamed abdelshahid]

Dear All,

We have updated the references to latest CP/CPS under Case #318 at the CCADB. We will also update the references to audit reports soon, once we have it published.

Looking forward to hearing from you on any updates or further comments.

Kind Regards,

Comment 36

[Ben Wilson]

I'll review your CPS again. Also, when you have your audits ready, let me know, and I will help you update the CCADB with the new audit references.

Comment 37

[mohamed abdelshahid]

Attachment: Latest Self-Assessment of CP/CPS and Compliance to CABF and Mozilla Requirements

Comment 38

[mohamed abdelshahid]

Attachment: The Dubai PKI - Value vs. Risk justification

Comment 39

[Kathleen Wilson]

Ben, per https://wiki.mozilla.org/CA/Root_Inclusion_Considerations I think we should deny this request.

Comment 40

[Ben Wilson]

I agree. I am closing this because of concerns related to the Root Inclusion Considerations and other reasons, including lack of a response regarding questions about spyware.