Open Bug 1474556 Opened Last year Updated 4 months ago

Add UAE Global Root CA G4 E2 Root Certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: ahmed.alali, Assigned: wayne)

Details

(Whiteboard: [ca-cps-review] - Pending CPS Updates 2019-07-28)

Attachments

(7 files)

28.27 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
23.21 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
1.76 KB, application/zip
Details
161.45 KB, application/pdf
Details
31.26 KB, application/pdf
Details
738.22 KB, application/pdf
Details
60.77 KB, application/pdf
Details
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
You need to log in before you can comment on or make changes to this bug.