1427262 - Add DarkMatter Root Certificates

Status: RESOLVED WONTFIX

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

Description

[Scott Rea]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171128222554




Expected results:

Add the following Roots to NSS (and Mozilla products):
DarkMatter Root CA G3
DarkMatter Root CA G4
UAE Global Root CA G3
UAE Global Root CA G4

Comment 1

[Scott Rea]

CA Info to be added shortly as a file attachment, but the certs are as follows:

CA Certificate: DarkMatter Root CA G3

            Certificate details:
			    Data:
			        Version: 3 (0x2)
			        Serial Number: 7703069413505335275 (0x6ae6ccd1a8297feb)
			    Signature Algorithm: ecdsa-with-SHA384
			        Issuer: C=AE, O=DarkMatter LLC, CN=DarkMatter Root CA G3
			        Validity
			            Not Before: May 18 13:25:34 2017 GMT
			            Not After : May 13 13:25:34 2037 GMT
			        Subject: C=AE, O=DarkMatter LLC, CN=DarkMatter Root CA G3
			        Subject Public Key Info:
			            Public Key Algorithm: id-ecPublicKey
			                Public-Key: (384 bit)
			                ASN1 OID: secp384r1
			                NIST CURVE: P-384
			        X509v3 extensions:
			            X509v3 Subject Key Identifier:
			                EE:7D:9E:FB:00:70:B0:FA:5C:0C:76:DA:A4:12:D1:1B:D0:D1:1C:A0
			            X509v3 Basic Constraints: critical
			                CA:TRUE
			            X509v3 Key Usage: critical
			                Digital Signature, Certificate Sign, CRL Sign
			    Signature Algorithm: ecdsa-with-SHA384
			-----BEGIN CERTIFICATE-----
			MIICATCCAYegAwIBAgIIaubM0agpf+swCgYIKoZIzj0EAwMwRjELMAkGA1UEBhMC
			QUUxFzAVBgNVBAoMDkRhcmtNYXR0ZXIgTExDMR4wHAYDVQQDDBVEYXJrTWF0dGVy
			IFJvb3QgQ0EgRzMwHhcNMTcwNTE4MTMyNTM0WhcNMzcwNTEzMTMyNTM0WjBGMQsw
			CQYDVQQGEwJBRTEXMBUGA1UECgwORGFya01hdHRlciBMTEMxHjAcBgNVBAMMFURh
			cmtNYXR0ZXIgUm9vdCBDQSBHMzB2MBAGByqGSM49AgEGBSuBBAAiA2IABCKiU1SB
			eVOMEfq0VvEmNrVUCo2ZOPzHbbh/t5Q7aARs1p61Rm5/T/Mrz0eaULjE3ZezYA1p
			nvJet+GfrXr48SG+KAatwJsZbdYJJ9InUkd0rfNCE/8mCyi5uu2ABgo3vqNCMEAw
			HQYDVR0OBBYEFO59nvsAcLD6XAx22qQS0RvQ0RygMA8GA1UdEwEB/wQFMAMBAf8w
			DgYDVR0PAQH/BAQDAgGGMAoGCCqGSM49BAMDA2gAMGUCMBqUFv0fIMptjGY5kdBm
			8sCnp7wxexUaXDfiL1b255Z+LPa879+29kHzSGeuGmX4cQIxAK59jHo4Ylg2fkuF
			f4rkycVpxbLkQk18eJwdRekEWZq0cBsdQMQvDaeVLB7OvY5PAQ==
			-----END CERTIFICATE-----
			

CA Certificate: DarkMatter Root CA G4

            Certificate:
			    Data:
			        Version: 3 (0x2)
			        Serial Number: 6996146270132526980 (0x61174df72bec5f84)
			    Signature Algorithm: sha384WithRSAEncryption
			        Issuer: C=AE, O=DarkMatter LLC, CN=DarkMatter Root CA G4
			        Validity
			            Not Before: May 18 13:57:45 2017 GMT
			            Not After : May 13 13:57:45 2037 GMT
			        Subject: C=AE, O=DarkMatter LLC, CN=DarkMatter Root CA G4
			        Subject Public Key Info:
			            Public Key Algorithm: rsaEncryption
			                Public-Key: (4096 bit)
			                Exponent: 65537 (0x10001)
			        X509v3 extensions:
			            X509v3 Subject Key Identifier:
			                89:01:3B:CC:49:BA:96:2C:6D:C7:84:84:99:13:4F:32:F1:B1:25:F4
			            X509v3 Basic Constraints: critical
			                CA:TRUE
			            X509v3 Key Usage: critical
			                Digital Signature, Certificate Sign, CRL Sign
			    Signature Algorithm: sha384WithRSAEncryption
			-----BEGIN CERTIFICATE-----
			MIIFUDCCAzigAwIBAgIIYRdN9yvsX4QwDQYJKoZIhvcNAQEMBQAwRjELMAkGA1UE
			BhMCQUUxFzAVBgNVBAoMDkRhcmtNYXR0ZXIgTExDMR4wHAYDVQQDDBVEYXJrTWF0
			dGVyIFJvb3QgQ0EgRzQwHhcNMTcwNTE4MTM1NzQ1WhcNMzcwNTEzMTM1NzQ1WjBG
			MQswCQYDVQQGEwJBRTEXMBUGA1UECgwORGFya01hdHRlciBMTEMxHjAcBgNVBAMM
			FURhcmtNYXR0ZXIgUm9vdCBDQSBHNDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
			AgoCggIBAKHLi+6F+oG4eHwrdj+3LOEI6+CpaRFygT6fPdvdOOYhAAxwLest+sja
			PplQJgtyCngNr8OEmMtKYciGc1CnTNrUnpBQnfY7pHrDfVQoETPSyRcmaBiESxWG
			W+b3DZ0MQSabA+LnF9tx6VNH58c4tZlV31BRSxoRT+PnAllpi756SyNYFjVjkAc1
			lwJXyxrYVZVq4IrYskclo+RL6430AFWibufzXz8MKWRjjUv/4kGPuefap52HcFjU
			1rndpmxHZXDRxTsoqq8nJDONYX+1L90q5Q+b0B9Xayk8LXQRT0nHn1OkXfZfAKoe
			BNBKJDuB25ekSvI2kzWsQ17J8YvN/uJyRFUWK7fkclB/nIpAkrm6nLTDXBghhUYw
			Gx7WIrPt+S0IroVSXXC6m0G5eb9K/bXigXEgf5bHqjhYqek/OwbMOcVspm862PMA
			MGA80PpuwsbUTa9H0V7B5pUR9fJiWuhN6BrpUi1vZ5zGYTg0SzVhPG5voRaZDsd6
			MoQydoae75Z3+ShUX4PkAO5aShWPahFLLCdsFw6aMMi6YAJSU9sEicYYS0zUXyge
			KL8rmsTNMLeWTNkpgCzXKqv5jwJSk7QxOQ2RZxiXE7xTVNnuqGreksp6Xc6XOApZ
			kp58Tr9i835t4492VBZdGvMXX+XKqy6yS3cTArcwb8RIkpWJLtUtAgMBAAGjQjBA
			MB0GA1UdDgQWBBSJATvMSbqWLG3HhISZE08y8bEl9DAPBgNVHRMBAf8EBTADAQH/
			MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQwFAAOCAgEAc78T/xsMMMQYOoMG
			z5X8gyl+STiEHWMXMdGQhg/5OTQb+HhMc4WQWXwfFgtRIbrAZE1+0xMMsADVwI76
			CykJEQJCYo5vAk8KecnRtm88GgtZIDh7DFLbIFRsM5US8VqsyT0f6BqUKjMBahjg
			GL8VKGXZNnElcynsRUlms7lvGpoMUvMLN95ByefGA3RDdN3y4W1kahBY2SN4jtSx
			HSl/uTpT2OBRVSmNbVQYPp3CccTz2bDh7YNkHc3Ay2+ssqfyNG2LJd2xLH5lwJUa
			nxV2Nd+3k66rB1EUYOdKJmtqq5ewjjSc0wQtVd28p3FK6S2vx4sFUNmMHTe9Uohf
			38i1MBlLo6/7FvxpDYkzbg6jgGk21MZcmYt1gTi8TzKoWjFMmtMLoKVNoFXLKA8v
			Z6dHpmR376nZhPFimWBuG3+WY7DAomIvSVKphhKC0AMlr/V25gikmCFj0ObOHspr
			r4/Z2WCP2tCcFXOIiLHDRaSkYP+x88cLs7Q4fCpSMmV+dMAIN+0LII8ZJdoIdmA0
			6lC+5LdjbwTFWeZamZqpSLqTtaLpoQH4RzID/LB0bYDLgWDhI/TxPTylXSAjBJnI
			MI4nVb2z2OgfOkKl4yUBH0SIZWxSglMNmQJBlwp4IjKzpsYoqepnPbSxVdEMmnxJ
			Ftq5oH6HDO6A6miVaHMg3eXaaBY=
			-----END CERTIFICATE-----
            

CA Certificate: UAE Global Root CA G3

            Certificate details:
                Data:
			        Version: 3 (0x2)
			        Serial Number: 5120310249860072256 (0x470eff0b2eb38340)
			    Signature Algorithm: ecdsa-with-SHA384
			        Issuer: C=AE, O=UAE Government, CN=UAE Global Root CA G3
			        Validity
			            Not Before: May 17 10:40:31 2017 GMT
			            Not After : May 12 10:40:31 2037 GMT
			        Subject: C=AE, O=UAE Government, CN=UAE Global Root CA G3
			        Subject Public Key Info:
			            Public Key Algorithm: id-ecPublicKey
			                Public-Key: (384 bit)
			                ASN1 OID: secp384r1
			                NIST CURVE: P-384
			        X509v3 extensions:
			            X509v3 Subject Key Identifier:
			                F8:77:BE:28:15:AD:E8:52:17:98:06:A7:B6:20:52:95:82:81:0E:65
			            X509v3 Basic Constraints: critical
			                CA:TRUE
			            X509v3 Key Usage: critical
			                Digital Signature, Certificate Sign, CRL Sign
			    Signature Algorithm: ecdsa-with-SHA384
			-----BEGIN CERTIFICATE-----
			MIICATCCAYegAwIBAgIIRw7/Cy6zg0AwCgYIKoZIzj0EAwMwRjELMAkGA1UEBhMC
			QUUxFzAVBgNVBAoMDlVBRSBHb3Zlcm5tZW50MR4wHAYDVQQDDBVVQUUgR2xvYmFs
			IFJvb3QgQ0EgRzMwHhcNMTcwNTE3MTA0MDMxWhcNMzcwNTEyMTA0MDMxWjBGMQsw
			CQYDVQQGEwJBRTEXMBUGA1UECgwOVUFFIEdvdmVybm1lbnQxHjAcBgNVBAMMFVVB
			RSBHbG9iYWwgUm9vdCBDQSBHMzB2MBAGByqGSM49AgEGBSuBBAAiA2IABBzPhVTP
			5JbCFb0SSoBG8MNFnwrbW19ZdISr7GNXYtTYMSXxWHQhhztrHXXQzgAAZGfxQtDi
			zbdaLzpxhYVQUQXUEx/jo5ndLfGWxUlqRtPQWLbH95iiISrhY1+erxWipaNCMEAw
			HQYDVR0OBBYEFPh3vigVrehSF5gGp7YgUpWCgQ5lMA8GA1UdEwEB/wQFMAMBAf8w
			DgYDVR0PAQH/BAQDAgGGMAoGCCqGSM49BAMDA2gAMGUCMCfxvqN8QVOw+ohtXmTa
			LpqrYYd/yDh0gIlfJDPTF+Wv4lJB3bDxrGc6WCMP3ltAlQIxAPYdYbgNni3Fcrn7
			CT0MwtgsjAzy09UZk54fkHvPi8KpcfajCnmQnoyf21PI1XjFVQ==
			-----END CERTIFICATE-----
			

CA Certificate: UAE Global Root CA G4

            Certificate details:
			    Data:
			        Version: 3 (0x2)
			        Serial Number: 2199526952165000767 (0x1e864a1c01b1463f)
			    Signature Algorithm: sha384WithRSAEncryption
			        Issuer: C=AE, O=UAE Government, CN=UAE Global Root CA G4
			        Validity
			            Not Before: May 17 10:54:59 2017 GMT
			            Not After : May 12 10:54:59 2037 GMT
			        Subject: C=AE, O=UAE Government, CN=UAE Global Root CA G4
			        Subject Public Key Info:
			            Public Key Algorithm: rsaEncryption
			                Public-Key: (4096 bit)
			                Exponent: 65537 (0x10001)
			        X509v3 extensions:
			            X509v3 Subject Key Identifier:
			                D5:2F:9A:E9:E8:17:00:D9:57:52:D0:3F:07:2B:4F:66:08:EB:F5:54
			            X509v3 Basic Constraints: critical
			                CA:TRUE
			            X509v3 Key Usage: critical
			                Digital Signature, Certificate Sign, CRL Sign
			    Signature Algorithm: sha384WithRSAEncryption
			-----BEGIN CERTIFICATE-----
			MIIFUDCCAzigAwIBAgIIHoZKHAGxRj8wDQYJKoZIhvcNAQEMBQAwRjELMAkGA1UE
			BhMCQUUxFzAVBgNVBAoMDlVBRSBHb3Zlcm5tZW50MR4wHAYDVQQDDBVVQUUgR2xv
			YmFsIFJvb3QgQ0EgRzQwHhcNMTcwNTE3MTA1NDU5WhcNMzcwNTEyMTA1NDU5WjBG
			MQswCQYDVQQGEwJBRTEXMBUGA1UECgwOVUFFIEdvdmVybm1lbnQxHjAcBgNVBAMM
			FVVBRSBHbG9iYWwgUm9vdCBDQSBHNDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
			AgoCggIBAI5XcjWIP2RRkeVsK0wdu1maFbxZSzmyTihYbwXRyPnpMzYt4J9KKn3w
			ul/VW2TceanbEwbWZlxYP0hcFYKFK5qinS0pmgKqjry7qA1siWGEpzNxgEr4IDz3
			GZPs/QaPTki8XqdBs331wejWzd7GEle1HMG6OQwc76acp1OAC7M671V77239VxK4
			f5EqY5eaDO6tAF3e/vN5mYdkn2NPUtikpnJ2kmCkha2iEJNdw9OAXBRJJTtFRxqD
			UkVXfZH4JgIMiJDFwlp2mNC1D4MP8UMNYvJBCMuYA+t4BXV+WgaqrzlmMSOo514h
			VfcY3h4WWHNw5tGGH0E4vy4MibA33sFyr70Ve1XCiGDOfC5Kdxc/DbzeGb7ClDP4
			1I/6tTpim+62MAhQMhwmZwRq318bVaPLMXa9DeKx0tIMPgVIac5ovvsoYjqog4Np
			JYuiAZ7Sb6mlztUqWRwtdC/bw4kfZ0Saole14y7Ms+sRCmE1w9d/ONmew34B98zv
			/Zry2xqzvSoHW1uWql3n5GMbdYefp+c3Or7XA/n2vb2WsFpbP3JJQdtRIysVJW0j
			jvFS1l2xpVS68eqQwDqh3Pp5TaH5Z4uTLKbmXprj85Rpqni7Nm5F9VlKnA8su0Gm
			LYWiX/Ggu3fmS6FPecBblhQezWUUDQAwUmQsxGGnpXavhdv+aXmXAgMBAAGjQjBA
			MB0GA1UdDgQWBBTVL5rp6BcA2VdS0D8HK09mCOv1VDAPBgNVHRMBAf8EBTADAQH/
			MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQwFAAOCAgEAWlqeU2rAlpCnuch1
			xPYl54qmoNPVCO6GxVwVU9P7CBoSZSXagGu7GwKJQ/QuleeotkoZL39EFXehBuWN
			BJKxmEfpi+L+a7rvsgnMT21ifhrQK88WOALkopY36NO59Lsnnw6DU/S6i1xL4Utg
			DzjNoEUvO41/tPkQMu34Q5KRBzAbK+b4F2xb33TVX1CmUYe/OcDvKtoSjodsSuh7
			AThpVctEjK2pIIDwwVjPd/vZS0V01IZk6yydmQrtYOJ70Hce62AMw+zkCu60jA1T
			O+THiJoPnHmMRvpdjHUIZkGXZi+xodEIZauV7AmKsDRB90vFevWZFUY9YRMsR0L3
			rC8iIQL/phAT/TyhfoJmnuzrdQVKuEGQ7SGvqfL+0nExYrWD1bmpPHo7+ts2OyEj
			nrDk2SZkavRJ9mOeBxIo9Voe56K0+95TPJ1wSPPXk17biW0XxFHCLOE2005hKn77
			QHjcbrCpLuADDftSW+uWWVKlELGBWyrIzVwXewom6umRu0Bge1X3xnIMwq6LTKnD
			N9z1J9WorqZd1KJGdtloneVoVMPTPamywG6Q62ordhoYLHJ8iNnIDHxexHX3GRIz
			bJxXn06Dgj1CRwLh/VOOHVlc5CqSFb0Y026m2KHYiUTqKr55Jrw4lC71STAY+mQh
			1PdEGZicLpQScDQFYv50fRA0gic=
			-----END CERTIFICATE-----

Comment 2

[Scott Rea]

Attachment: DarkMatter CA Information.pdf

Completed template for Root Inclusions

Comment 3

[Scott Rea]

Attachment: DMWebTrustSealFile.pdf

CA WebTrust Assertions and Auditor Report

Comment 4

[Scott Rea]

Attachment: PKI-SelfAuditCheckList_18_Oct_2017.pdf

DM Self Audit Checklist

Comment 5

[Kathleen Wilson]

My apologies for my delay...

I have not yet had time to look into this bug, but from first glance it looks like the BR Self Assessment might still be needed.
https://wiki.mozilla.org/CA/Information_Checklist#Baseline_Requirements_Self_Assessement

Comment 6

[Scott Rea]

(In reply to Scott Rea from comment #2)
> Created attachment 8939230 [details]
> DarkMatter CA Information.pdf
> 
> Completed template for Root Inclusions

There was a duplication in one of the submitted roots - I will upload a fixed version of the document: DarkMatter CA Information2.pdf

Also adding the Self Assessment in the requested format...

Comment 7

[Scott Rea]

Attachment: DarkMatter CA Information2.pdf

Comment 8

[Scott Rea]

Attachment: CA's BR Self Assessment - DarkMatter.xlsx

Comment 9

[Kathleen Wilson]

Attachment: 1427262-CA-Information.pdf

The attached file shows the information that has been verified for this request.

Search for "NEED" in the file to find where clarification is still needed.

The primary things to note:

1) 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 recognises in CAA "issue" or "issuewild" records as permitting it to issue.

2) NEED 3 test websites (valid, revoked, expired) for each root cert -- the TLS cert in the site must chain up to the root cert for which inclusion is requested.

3) **OV SSL: 42 Months -- This does not meet section 6.3.2 of the Baseline Requirements

4) It is clear in the CP/CPS that the CA may generate/escrow private keys. The CP/CPS does not appear to say that this is not allowed for TLS/SSL certs.

5) Mozilla can apply constraints at the root cert level. If this root inclusion request proceeds, may these roots be constrained to *.ae?

6) Make sure that your future audit statements satisfy section 3.1.4 of Mozilla's Root Store Policy requirements.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information
In particular: "3. Distinguished Name and SHA256 fingerprint of each root and intermediate certificate that was in scope;"

Comment 10

[Scott Rea]

G'day Kathleen et al,

This feedback is in response to your Comment #9 above.

I will specifically list responses to the the 6 highlighted NEEDs in comment#9 above, and will review PDF for any additional items. As a general comment, DM has always updated its SOPs in accordance with CABF requirements, and the CPS updates follow on a slower update schedule. In most cases the compliance questions being asked by Mozilla were already in the SOPs validated as part of our WebTrust audit, but corresponding updated procedures may not have been published in an updated CPS at that time...
NOTE: DM has taken the approach of keeping our SOPs up to date ahead of the BR and EV requirements, and these have been (and will be in future) validated by our WT auditors. We estimated this to be the most agile way of staying ahead of CABF requirements in terms of operations, as long as any SOP adjustments do not contradict current CPS text, they are free to be more restrictive, and to date, this has been the case.

NOTE1) 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 recognises in CAA "issue" or "issuewild" records as permitting it to issue.

[DM Response1]:
Our last CPS (V1.5) was published in June, prior to the CAA requirement for BRs coming into effect. However, DM did update it's Standard Operating Procedures (SOPs) in respect to CAA for OV and EV issuance on 14th August, 2017 (again in advance of the September date required in BRs). It was these SOPs that were reviewed and verified as part of our WebTrust audit (completed in October 2017), so these SOPs have been validated under our audit.
Our next version of CPS is due out soon (anticipate June 2018), and it includes the updated text in respect to CAA checking that is currently reflected in our SOPs. The following is an extract of the text to be included in next CPS release in this regard (added to CPS Section 4.2.1 Performing Identification and Authentication Functions):

----

In accordance with BaseLine Requirements section 3.2.2.8, prior to issuing of publicly trusted SSL/TLS certificates, DarkMatter validates each of the requested FQDNs against the domain’s CAA records for listed authorized CA(s). 
If a CAA record exists that does not contain darkmatter.ae as an authorized CA, DarkMatter will reject the request and not issue the certificate.  

Darkmatter processes the CAA records as follows: 
•	Validate and act on, Issue and Issuewild
•	Validate but don’t act on iodef 
•	Do not validate nor act on any other property tags 
•	If no property tags are found, DarkMatter considers it approved to issue

If a request is rejected for any of the reasons above, DarkMatter will document the details for reporting purposes. DarkMatter does not commit to submit reports to contacts mentioned in the iodef properety tag. 

---- 



NOTE2) NEED 3 test websites (valid, revoked, expired) for each root cert -- the TLS cert in the site must chain up to the root cert for which inclusion is requested.

[DM Response2]:
DM intends to re-sign the existing public trust ICAs under a couple of the submitted Roots. The same infrastructure and profiles for validating the currently issued Test TLS certs will be used by future certs chained to the submitted Roots. Therefore DM considers the current test certs as demonstrative of accomplishing the same purpose whether issued from the DM chain or the QV chain. Can Mozilla please clarify which aspect of verification is not satisfied by the current approach?



3) **OV SSL: 42 Months -- This does not meet section 6.3.2 of the Baseline Requirements

[DM Response3]:
DM has Private Trust Organizationally validated TLS certificates - these are not subject to BRs and do not chain to the certs in question, but belong to the Research and Education space profiles of our products. Hence the CP makes reference to OV but this was not intended to exclusively mean BRs.
Within the CPS, Section 6.3.2 Certificate Operational Periods and Key Pair Usage Periods says "...The maximum validity period for Digital Certificates issued within the UAE PKI is 1 to 3 years. The operational periods for keys are contained in the corresponding certificate profiles." Our SOPs at the time of audit restricted only EV to 2 years, but OV (for BR purposes) was allowed to 3 years. Current SOPs were updated in February this year to restrict both OV and EV that are Public Trust (in scope for Mozilla) to 2 years.  
Please also refer to DM CPS Section 1.3.7.1 CA and Browser Forum:

----
DarkMatter PKIs conform to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (“Baseline Requirements”) and the Guidelines for Extended Validation Certificates (“EV Guidelines”) both of which are published at https://www.cabforum.org. With regard to SSL/TLS Server Certificates or Code Signing Certificates, if any inconsistency exists between DarkMatter's CPS and the Baseline Requirements or the EV Guidelines, then the EV Guidelines take precedence for EV Certificates and the Baseline Requirements take precedence for publicly trusted SSL certificates.
The DMPPA reviews changes to published CAB Forum guidelines at least annually and more frequently when updated guidelines are published to ensure new requirements are incorporated into CP and CPS that DarkMatter uses in conjunction with any publicly trusted CA operations, in a timely manner.
----
Profiles for EV and OV certs, including validity periods, are aligned with Mozilla and CABF EV and BR requirements.


4) It is clear in the CP/CPS that the CA may generate/escrow private keys. The CP/CPS does not appear to say that this is not allowed for TLS/SSL certs.

[DM Response4]:
Please refer to CPS Section 6.2.3.2 Escrow of Subscribers Private Signature Key: 
----
The DarkMatter CA is never in possession of Subscribers private signature keys. Subscribers may not escrow their private signature keys. DarkMatter may provide escrow services for other types of Certificates in order to provide key recovery as described in section 4.12.1.
----
TLS/SSL certificates are subscriber Signature keys and therefore not eligible for escrow.



5) Mozilla can apply constraints at the root cert level. If this root inclusion request proceeds, may these roots be constrained to *.ae?

[DM Response5]:
DM started with such constraints in the Issuing CAs we provisioned under the QV chain, however, these constraints were later removed because NPKI is designed to provide trusted certificates for entities within UAE, and many of those entities already operate under non .ae TLDs e.g. .com, .org, .net etc. So even though the UAE Global Roots are designed for entities in-country, there is still a need to provide services to in-country entities who operate services not in the .ae TLD. The 2 DM Roots are designed for global trust and therefore restricting to the .ae TLD defeats the purpose of their instantiation. DM requests that all 4 roots be enable without the suggested constraints.


6) Make sure that your future audit statements satisfy section 3.1.4 of Mozilla's Root Store Policy requirements.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information
In particular: "3. Distinguished Name and SHA256 fingerprint of each root and intermediate certificate that was in scope;" 

[DM Response6]: DM commits to ensuring that SHA256 Fingerprint of Issuers in scope of audit will be named. We are somewhat dependent on the WT Audit provider for their specific assertions, but at least the DM Management assertions can include the respective SHA256 fingerprints
NOTE: The Audit Reports do include the names of Issuers in scope, and do reference the CPS which includes the SHA1 fingerprint of Issuers in scope (See CPS 7.5.2), and we will update the CPS with SHA256 fingerprint in next release

Comment 11

[Scott Rea]

G'day folks,

Just adding further info to make it easy to find responses to the NEED questions in Kathleen's PDF that was attached to Comment #9 above.

For Test web sites - we have populated with valid, revoked, expired certs issued through our current operating ICAs. When Roots are included, these ICAs will be re-signed under our Roots, so the current Test certs used will eventually chain to the respective submitted Roots. By taking this approach, Mozilla should be able to verify that the validation infrastructure is on place and operating.

Each submitted Root has the requisite Test sites listed as Demo Sites under the Root in question as listed on their respective repositories:

The UAE Global Roots have test sites linked off: https://ca.darkmatter.ae/UAE/index.html

The DM Global Roots have test sites linked off: https://ca.darkmatter.ae/DM/index.html

Or specifically, here are the links provided:

UAE Global Root CA G3: 
Active: https://valru.ca.darkmatter.ae/
Revoked: https://revru.ca.darkmatter.ae/
Expired: https://expru.ca.darkmatter.ae/

UAE Global Root CA G4
Active: https://valeu.ca.darkmatter.ae/
Revoked: https://reveu.ca.darkmatter.ae/
Expired: https://expeu.ca.darkmatter.ae/

DarkMatter Root CA G3
Active: https://valrd.ca.darkmatter.ae/
Revoked: https://revrd.ca.darkmatter.ae/
Expired: https://exprd.ca.darkmatter.ae/

DarkMatter Root CA G4
Active: https://valed.ca.darkmatter.ae/
Revoked: https://reved.ca.darkmatter.ae/
Expired: https://exped.ca.darkmatter.ae/

NB: even though the above TLS certs do not chain today to the Roots in question, they will in the future using the same infrastructure up to the Issuing CA.


Question: for each Revocation test, certlint test, x509lint test, EV test under each of the Roots, what format is being requested as output from these tests? Is it correct to assume these tests are to be conducted for an end entity cert that chains to the respective Roots?

Comment 12

[Kathleen Wilson]

(In reply to Scott Rea from comment #10)
> 
> [DM Response1]:
> Our last CPS (V1.5) was published in June, prior to the CAA requirement for
> BRs coming into effect. However, DM did update it's Standard Operating
> Procedures (SOPs) in respect to CAA for OV and EV issuance on 14th August,
> 2017 (again in advance of the September date required in BRs). It was these
> SOPs that were reviewed and verified as part of our WebTrust audit
> (completed in October 2017), so these SOPs have been validated under our
> audit.
> Our next version of CPS is due out soon (anticipate June 2018), 


OK. Please update this bug when the new version of your CP/CPS documents are available.

> If a CAA record exists that does not contain darkmatter.ae as an authorized
> CA, DarkMatter will reject the request and not issue the certificate.  

OK

> NOTE2) NEED 3 test websites (valid, revoked, expired) for each root cert --
> the TLS cert in the site must chain up to the root cert for which inclusion
> is requested.
> 
> [DM Response2]:
> DM intends to re-sign the existing public trust ICAs under a couple of the
> submitted Roots. The same infrastructure and profiles for validating the
> currently issued Test TLS certs will be used by future certs chained to the
> submitted Roots. Therefore DM considers the current test certs as
> demonstrative of accomplishing the same purpose whether issued from the DM
> chain or the QV chain. Can Mozilla please clarify which aspect of
> verification is not satisfied by the current approach?


https://cabforum.org/baseline-requirements-documents/

Section 2.2: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."

The provided test websites do not currently meet the requirement.

I don't really care what is on the test web pages. Some CAs put useful information, such as the Root Cert name.

If you are requesting EV treatment, then the SSL certs also need to have the EV policy OID.


> 3) **OV SSL: 42 Months -- This does not meet section 6.3.2 of the Baseline
> Requirements
> 
> [DM Response3]:
> DM has Private Trust Organizationally validated TLS certificates - these are
> not subject to BRs and do not chain to the certs in question, but belong to
> the Research and Education space profiles of our products. Hence the CP
> makes reference to OV but this was not intended to exclusively mean BRs.
> Within the CPS, Section 6.3.2 Certificate Operational Periods and Key Pair
> Usage Periods says "...The maximum validity period for Digital Certificates
> issued within the UAE PKI is 1 to 3 years. The operational periods for keys
> are contained in the corresponding certificate profiles." Our SOPs at the
> time of audit restricted only EV to 2 years, but OV (for BR purposes) was
> allowed to 3 years. Current SOPs were updated in February this year to
> restrict both OV and EV that are Public Trust (in scope for Mozilla) to 2
> years.  


OK. Please update this bug when the new version of your CP/CPS documents are available, that make it clear which validity periods apply to which CA Hierarchies, chaining up to which root certs.


> 
> 4) It is clear in the CP/CPS that the CA may generate/escrow private keys.
> The CP/CPS does not appear to say that this is not allowed for TLS/SSL certs.
> 
> [DM Response4]:
> Please refer to CPS Section 6.2.3.2 Escrow of Subscribers Private Signature
> Key: 
> ----
> The DarkMatter CA is never in possession of Subscribers private signature
> keys. Subscribers may not escrow their private signature keys. DarkMatter
> may provide escrow services for other types of Certificates in order to
> provide key recovery as described in section 4.12.1.
> ----
> TLS/SSL certificates are subscriber Signature keys and therefore not
> eligible for escrow.
> 


Perhaps it's just not clear which document (CP vs CPS) applies to which root and their CA hierarchies.

For example, the paragraph you quoted above from the CPS, seem to contradict the following statement in the CP:
"Subscriber keys may be escrowed to provide key recovery."


> 
> 
> 5) Mozilla can apply constraints at the root cert level. If this root
> inclusion request proceeds, may these roots be constrained to *.ae?
> 
> [DM Response5]:
> DM started with such constraints in the Issuing CAs we provisioned under the
> QV chain, however, these constraints were later removed because NPKI is
> designed to provide trusted certificates for entities within UAE, and many
> of those entities already operate under non .ae TLDs e.g. .com, .org, .net
> etc. So even though the UAE Global Roots are designed for entities
> in-country, there is still a need to provide services to in-country entities
> who operate services not in the .ae TLD. The 2 DM Roots are designed for
> global trust and therefore restricting to the .ae TLD defeats the purpose of
> their instantiation. DM requests that all 4 roots be enable without the
> suggested constraints.

OK

> 
> 
> 6) Make sure that your future audit statements satisfy section 3.1.4 of
> Mozilla's Root Store Policy requirements.
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy#public-audit-information
> In particular: "3. Distinguished Name and SHA256 fingerprint of each root
> and intermediate certificate that was in scope;" 
> 
> [DM Response6]: DM commits to ensuring that SHA256 Fingerprint of Issuers in
> scope of audit will be named. We are somewhat dependent on the WT Audit
> provider for their specific assertions, 

I believe that the current template for WT audit statements requires the auditor to list the SHA256 Fingerprints for all of the root and intermediate certificates that were in scope of the audit.

Comment 13

[Scott Rea]

Attachment: TestResultsMozilla.docx

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 14

[Scott Rea]

Attachment: valed.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 15

[Scott Rea]

Attachment: exped.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 16

[Scott Rea]

Attachment: reved.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 17

[Scott Rea]

Attachment: valeu.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 18

[Scott Rea]

Attachment: reveu.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 19

[Scott Rea]

Attachment: expeu.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 20

[Scott Rea]

Attachment: valrd.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 21

[Scott Rea]

Attachment: revrd.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 22

[Scott Rea]

Attachment: exprd.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 23

[Scott Rea]

Attachment: valru.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 24

[Scott Rea]

Attachment: revrd.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 25

[Scott Rea]

Attachment: revru.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 26

[Scott Rea]

Attachment: expru.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

This is an addendum to the Self Assessment Request in response to Mozilla Verification Report

Comment 27

[Scott Rea]

Comment on attachment 8979559 [details]
revrd.ca.darkmatter.ae (Dark Matter L.L.C.).pdf

Sorry - this was a duplicate

Comment 28

[Kathleen Wilson]

You do not need to attach the output of https://certificate.revocationcheck.com or any of the other tests. We just need your confirmation (via a comment in this bug) that the SSL cert at each test website chains up to the coresponding root cert being considered for inclusion, and that you have resolved all errors. Then we can run the tests ourselves to check.

Comment 29

[Rob Stradling]

I just found 2 certs where the Subject:CN is not also present as a SAN:dNSName, which were (mis)issued by DarkMatter's publicly-trusted Subordinate CA (under a QuoVadis root) yesterday:

https://crt.sh/?id=492681701&opt=cablint,zlint
https://crt.sh/?id=492682805&opt=cablint,zlint

Comment 30

[Stephen Davidson]

(In reply to Rob Stradling from comment #29)

Thanks Rob; we picked these up in our linting last night. DarkMatter has been informed and will revoke the certificates,then report back here.

Comment 31

[Scott Rea]

(in reply to Rob - comment #29, and Stephen - comment #30)

DM mis-issued 2 certificates that were not in compliance with the BRs - specifically the FQDN listed in the CN was not also included in the SAN. The 2 offensive certs have been revoked (some 9.5 hours ago now) and were only existent for approximately 18hrs and at NO TIME were they LIVE on the internet protecting any services. They have since been replaced by properly attributed BR-compliant certificates.

The fault was entirely human error - both the RA submitter and the RA Verifier failed to pic up the error. DM runs a number of checks (not yet the multiple Lints - those are being rolled out in a near future release) to ensure that certificate data is correct and allowed - our current system is not the best for picking up missing info (as was this case).

We have manual Lint checking only currently, and with our auto logging of all TLS into CT, that means certs are issued before we have a chance to run the Lints. The next version of the CA platform actually has auto-lint capabilities which will negate the need to run these manually post issuance. We will be rolling that upgrade out once testing is complete.

Summary: 2 certs were issued with missing data in the SN which is a policy violation, they were discovered and revoked before being used by the private key holder, replacement BR-compliant certs have been issued, incident report was created and added to our audit register and also shared with QV, staff involved have been counseled and subject to mandatory re-training, platform automated processes will eradicate human error in future and will be applied once testing is complete.

Comment 32

[Ryan Sleevi]

Hi Scott,

We should probably open a separate bug, and making sure that https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report has all of the details, including concrete timelines for proposed remediations.

Comment 33

[Scott Rea]

Thanks Ryan - that make sense (replying to Comment #32)

My only question at this point is which category such bugs get filed under, since the link only points to the Mozilla-dev-security group postings. Can someone please point me to the right bug type, or is it expected to just post the relevant details to the dev-security-policy list?

Comment 34

[Rob Stradling]

Scott, https://wiki.mozilla.org/CA has a "Report an Incident to Mozilla" link.  Use that link to begin filing a new Bugzilla bug.

Comment 35

[David E. Ross]

While further analysis of this request might proceed, I think the public review phase should be deferred until the corrective actions indicated in comment #31 have been implemented, documented in the CP or CPS, and verified as actually in force by an outside audit.

Comment 36

[Scott Rea]

What is the expected process for entities requesting anchors being added to trust stores to establish accounts with the various CT logs for the test certs (and any future issuance)? Will CT log operators accept submissions from issuers before they are included in a trust store? As many new anchor operators are going through this process, I am asking if Mozilla has established any recommendations for how to accomplish this step?

Comment 37

[Ryan Sleevi]

(In reply to Scott Rea from comment #36)
> What is the expected process for entities requesting anchors being added to
> trust stores to establish accounts with the various CT logs

Talk to log operators

> for the test certs (and any future issuance)? 

Please define what you mean by "test" certs. There are real certificates you issue for purposes of interoperability testing good, expired, and revoked certificates. But those are fully validated and real. And then there is what the Baseline Requirements define as a "Test Certificate".

Logs are unlikely to accept the latter, and the former don't need to be logged apriori.

> Will CT log operators accept submissions from issuers before they are included in a trust store?

In general, no, and by policy may be prohibited from doing so. Accepting certificates from self-signed roots creates risk of spam and abuse, and in general, Log Operators are likely to wait on the review and approval of at least one trust store that's reviewed the policies of the CA in order to minimize that risk. Alternative, Log Operators may require collateral from such self-signed roots for a period of time, in order to offset the risk that the Log Operator is taking regarding the CA submitting spam or abusive content, and return that collateral on such a time as the CA becomes trusted (that is, replacing the physical collateral with the notion of 'trust' as collateral, as a CA would be at risk of being untrusted).

> As many new anchor operators are going through this process, I am asking if Mozilla has
> established any recommendations for how to accomplish this step?

This is not required by Mozilla policy, so it's unclear why recommendations would be needed. You can discuss all of these questions at [e-mail], as they do not seem related to the inclusion request into Mozilla at all.

Comment 38

[Rob Stradling]

Scott, there are some public logs that are deliberately not subject to browser CT log policies.  One reason they exist is to facilitate CT-related testing.  2 suggestions:

1. Google's testtube log.  See https://www.certificate-transparency.org/known-logs for details.

2. Comodo CA's Dodo log.  See https://github.com/Comodo-CA/CTLogs-AcceptedRoots/tree/master/crt/dodo

Comment 39

[Scott Rea]

(In reply to Ryan comment 37 and Rob comment 38)

This may not be a Mozilla requirement par se, but it is a self imposed requirement for DM per our SOPs, and the Mozilla requirement to provide certs for interoperability testing means our SOPs apply to the issuance of any certs intended for public trust (which the interop certs will eventually be if we ever get through this process). Hence it creates a Chicken and Egg scenario for us.

DM SOPs for issuance of TLS certs intended for public trust, require us to submit to a number of CT logs - this is baked into our configuration of the CA platform i.e. no successful CT log responses, means cert does not get issued. This policy applies for any Issuing CA that is intended for Public Trust TLS. Since Mozilla is requesting the interop certs (valid, expired, revoked) are published from an ICA that chains to the submitted anchors, then this policy applies for them. To meet the Mozilla requirement of producing the interop certs, DM would have to produce them from a system that does not meet our current SOPs, or in other words, we would need to create a special class of SOPs just for these interop certs. It also means that since the submitted anchors and ICAs will produce certs under procedures/configs that are not our current live production SOPs, this creates a scenario where we can no longer assert that every public trust TLS cert issued from these followed the same WT audited SOPs. Sure we can do it, but its just not as clean as we wanted. Am I sufficiently clearly describing my concern here? 

What we had hoped, is that the current set of interop certs, which were issued under our SOPs and production configs, (which require successful CT Log submission prior to issuance), could be used to demonstrate the interoperability needed. They use the same issuance and validation processes, and are issued from ICAs that will eventually be re-signed under one of the submitted anchors. We anticipated that these should be sufficient to demonstrate the necessary CA capabilities to support trust are in place e.g. CRLs, OCSP, AIA chaining etc.

NOTE1: We don't need to test our CT Log process, its already live since last year for our existing TLS issuance and a requirement under our SOPs. However, we do need to create new relationships with log providers for the new anchors.

NOTE2: I didn't mean to throw anyone off kilter by using the term test certificate - this was just referring to the certs we created for Mozilla community to test interoperability - I have referred to these now in this thread as interop certs. The ones we have produced currently are fully trusted "real" certificates as Ryan calls them.

Comment 40

[Ryan Sleevi]

(In reply to Scott Rea from comment #39)
> Sure we can do it, but its just not as clean as we wanted. Am I sufficiently clearly describing my concern here? 

Yes. However, it sounds like you've designed your system in such a way as to not be compatible with CT. It's admirable, but it misses the ecosystem risk from CT Logs supporting you (or, more generally, any party claiming to be a CA like you). RFC 6962 calls this out as part of exploring the risk that log operators face - and, in effect, you're outsourcing that risk to others.

> What we had hoped, is that the current set of interop certs, which were
> issued under our SOPs and production configs, (which require successful CT
> Log submission prior to issuance), could be used to demonstrate the
> interoperability needed.

I'm not sure how that was seen as a viable option, given the requirement for all roots to have such interop certificates issued as a condition of a BR audit. Section 2.2 of the BRs leaves no room for misinterpretation of this requirement.

> They use the same issuance and validation
> processes, and are issued from ICAs that will eventually be re-signed under
> one of the submitted anchors. We anticipated that these should be sufficient
> to demonstrate the necessary CA capabilities to support trust are in place
> e.g. CRLs, OCSP, AIA chaining etc.

It doesn't meet section 2.2 of the BRs.

Comment 41

[Scott Rea]

(In reply to Ryan from comment #40)

Long term we intend to operate our own CT Logs - but we exclusively rely upon the existing log operators in the interim.

Section 2.2 of the BRs has a chicken and egg conundrum for new CAs - the interoperability certificates are only required for Public Trust Roots, but those Roots not yet accepted in any browser are by definition not yet trusted. Once they are accepted, then the interoperability certificate requirement will apply to them.

Until then, the best DM can hope to achieve is to issue interoperability certificates off existing cross-trust chains.

Comment 42

[Ryan Sleevi]

I am sorry, but that is not how the BRs work and that is not a reasonable answer.

You are stating you will not and cannot comply with the BRs, because you wrote a policy that prevents you from complying with the BRs unless someone else does something for you. That is unacceptable no matter the clause in the BRs. There are solutions to your self-imposed problems, but picking and choosing BR compliance is not one. There is no chicken and egg problem. You have simply defined a policy in a way that creates more work for you.

Comment 43

[Scott Rea]

(in reply to Ryan from comment #42)

Ryan, please clarify where in any of the above statements you feel that DM has said we "...will not and cannot comply with the BRs"?? 

We did not make any such assertion, and this is entirely contrary to the whole reason and purpose behind this thread. I am at a loss as to how you could have reached such a conclusion.

DM can (and will in the next 7 days or so) create new interoperability certificates for all Roots submitted to Mozilla. But these are not publicly trusted, and cannot be until after Mozilla accepts those Roots. The BRs are only for Publicly Trusted certificates, and do not apply to otherwise issued certificates. Hence the BRs cannot be the authoritative policy for why these are required by Mozilla - otherwise we have the chicken and egg scenario.

I am therefore interpreting that the interoperability certificates required under the Mozilla Root Policy are not Public Trust since these appear to be required before the Roots are accepted. These we can certainly create, and will complete the process shortly, but as non Public Trust certificates, the BRs do not apply to these.

Comment 44

[Ryan Sleevi]

(In reply to Scott Rea from comment #43) 
> Ryan, please clarify where in any of the above statements you feel that DM
> has said we "...will not and cannot comply with the BRs"?? 

Sure. It's this statement from Comment #41:
> Until then, the best DM can hope to achieve is to issue interoperability certificates off existing cross-trust chains.

> DM can (and will in the next 7 days or so) create new interoperability
> certificates for all Roots submitted to Mozilla. But these are not publicly
> trusted, and cannot be until after Mozilla accepts those Roots. The BRs are
> only for Publicly Trusted certificates, and do not apply to otherwise issued
> certificates. Hence the BRs cannot be the authoritative policy for why these
> are required by Mozilla - otherwise we have the chicken and egg scenario.

This is an incredibly disturbing read of the Baseline Requirements, and suggests a fundamental misunderstanding about the applicability. The suggestion here - that there is a bifurcation in the set of certificates - is exactly the kind of thing that CAs use to hide misissued certificates.

This tortured interpretation of Section 2.2 - that is, the suggestion that either the BRs are not applicable to these roots or that it is not required to create these certificates - calls into serious question as to how these roots and keys are being maintained. This is because such an interpretation is a fairly significant misread not just of Section 2.2, but the entirity of the Baseline Requirements, particularly Section 1.1, by suggesting that until you're included "somewhere" (clearly, at DarkMatter's discretion based on the replies), any requirements on or about publicly trusted certificates are non-applicable.

1.1 makes it clear that the requirements flow down from the root to all certificates in that hierarchy. By applying to be publicly trusted, you're stating that root complies the requirements of being publicly trusted - and that the root complies with all requirements of publicly trusted roots. Clearly, the failure to create these certificates is a demonstration that these roots do not comply with the requirements of publicly trusted roots, and the suggestion "as non Public Trust certificates, the BRs do not apply to these" is flat out inconsistent with the BRs, as well as Mozilla policy, which applies to all those "CA certificates included in, or under consideration for inclusion in, the Mozilla root program."

This is a significant interpretation difference - and while I appreciate it being raised early in the inclusion, is fairly damaging in its implications, because such an interpretation can spread to any and all BR requirements.

Perhaps put simply:
- Do you assert that the DM roots, at present, and since creation, have complied with all requirements of publicly trusted roots, and in a way that all issued certificates have been considered publicly trusted certificates?
  - If not (and it's difficult to assert compliance in the lack of the interoperability certificates), what areas beyond interoperability certificates have there been matters of non-compliance? What certificates have been issued that have been seen as not publicly trusted and therefore exempt from the BRs?

Comment 45

[Scott Rea]

(In reply to Ryan from comment #44)

>  - Do you assert that the DM roots, at present, and since creation, have complied with all requirements of publicly trusted 
> roots, and in a way that all issued certificates have been considered publicly trusted certificates?
>  - If not (and it's difficult to assert compliance in the lack of the interoperability certificates), what areas beyond 
> interoperability certificates have there been matters of non-compliance? What certificates have been issued that have been seen 
> as not publicly trusted and therefore exempt from the BRs?

This is easy - in response to simplified question 1 above: YES
Question 2 does not apply.

DM has Issuing CAs that chain to existing Roots in browsers, these issue Publicly Trusted certificates which are compliant with all current BRs. We actually used these to issue the first raft of interoperability certificates.

All certificates issued from the submitted Roots are INTENDED to be public trust certificates and so follow the same procedures for issuance as our existing cross-signed Issuers - with one exception: we cannot use the same CT Log configuration we use for the cross-signed ICAs.

Tell me Ryan, what is Chrome going to do when it encounters an EV cert that was only submitted to test CT Logs - will it trust it? I don't think so (but happy to be corrected if this is indeed the case - although that opens a whole raft of other concerns for the potential security hole that would be created). So my point is, even though these interoperability certificates can be issued with an INTENTION for public trust, in practice they will not be. First because there is no guarantee that the Root will be accepted, Second because even if the Root gets accepted, then the interoperability certs wont appear in any production CT log and so still wont be trusted for some set of browsers.

Am I missing something here that is obvious to everyone else?

Comment 46

[Ryan Sleevi]

(In reply to Scott Rea from comment #45)
> (In reply to Ryan from comment #44)
> 
> >  - Do you assert that the DM roots, at present, and since creation, have complied with all requirements of publicly trusted 
> > roots, and in a way that all issued certificates have been considered publicly trusted certificates?
> >  - If not (and it's difficult to assert compliance in the lack of the interoperability certificates), what areas beyond 
> > interoperability certificates have there been matters of non-compliance? What certificates have been issued that have been seen 
> > as not publicly trusted and therefore exempt from the BRs?
> 
> This is easy - in response to simplified question 1 above: YES
> Question 2 does not apply.

I do not believe this is an honest or correct answer, based on the previous replies.

Please demonstrate your valid, expired, and revoked certificates from the roots under question, as required by Section 2.2 of the BRs.

> Tell me Ryan, what is Chrome going to do when it encounters an EV cert that
> was only submitted to test CT Logs - will it trust it? I don't think so (but
> happy to be corrected if this is indeed the case - although that opens a
> whole raft of other concerns for the potential security hole that would be
> created). So my point is, even though these interoperability certificates
> can be issued with an INTENTION for public trust, in practice they will not
> be.

Can you please highlight where, in the BRs, you believe it's required for Chrome to trust this certificate for you to need to comply with the BRs? This is clearly not correct, nor relevant.

> Am I missing something here that is obvious to everyone else?

If you issue certificates from your root, they are publicly trusted.
Full stop.
There's no weaseling out of this, no creative interpretation. This has been clear and unambiguous and part of policy for some time, so it's disappointing to hear a CA suggest otherwise.

Comment 47

[Ryan Sleevi]

To expand on this, perhaps it's helpful to explain by substitution.

Imagine your CP/CPS stated that you'll issue certificates with DNS only in the commonName - that is, you won't include the subjectAltName.
You then apply to Mozilla, with that CP/CPS, and it (rightfully) gets flagged as non-compliance, because the BRs explicitly prohibit this.
You then explain that the reason you won't issue in the subjectAltName is that Python 2.1 and OpenSSL 0.9.6 have trouble with the subjectAltName.
If they don't trust the certificate, then it's not publicly trusted. And because it's not publicly trusted, those certificates without subjectAltNames are not required to comply with the Baseline Requirements.

That is, in effect, what's being argued here, except you can substitute the subjectAltName for the issuance of the Section 2.2 certs, and instead of talking about Python, you're talking about Chrome.

What Python does, or what Chrome does, is not relevant to determining whether you are publicly trusted. Every certificate from your root is presumed publicly trusted. The root itself is presumed publicly trusted. From its creation, you MUST have complied with all policies for publicly trusted certificates - there's no exceptions in that hierarchy, such as based on "when" it was issued. It does not matter that your policy says you will be compatible with Python 2.1 - your policy is out of compliance with the BRs and Mozilla.

That there is any confusion about "publicly trusted" is significant, and is deeply troubling. Following the discussions around OISTE WISeKey's recent application on m.d.s.p should have highlighted the importance and significance of compliance from Day 0, in verifiable ways. The CA's policies don't get to trump that requirement.

Nothing in the BRs requires 100% of your issuance be logged. That's intentional and by design. It solves this problem - along with a host of others. You can easily "fix" your policy to say that infrastructure certs as noted by the following profiles are exempt from being logged. Presumably, that already includes your intermediate certificates (... unless you're saying you're including embedded SCTs in a 10+ year intermediate, which is to misunderstand the purpose of those embedded SCTs), and can also apply to other pieces - such as your infrastructure certificates or your 2.2 "valid, expired, revoked" certificates.

Comment 48

[Scott Rea]

(In reply to Ryan's comment #46)

>  I do not believe this is an honest or correct answer, based on the previous replies.

Ryan, please maintain civility in your communications. It is not appropriate to call me dishonest - this is the second time you have done this on a public forum. The first time you did this it was behind my back and I had no opportunity to defend myself. This time it is at least to my face (virtually), but I nonetheless refute your degrading commment and ask you to desist perpetuating such falsehoods. If you misunderstood one of my comments or I have misunderstood one of yours, then lets iterate until there is understanding, but there is no need devolving your responses to name calling or impugning my character - Its entirely inappropriate. 

You cannot create the required interoperability certificates before the Root exists. Therefore, despite what you appear to be asserting above, there will exist some delta of time during which a Root INTENDED for Public Trust, will exist, but no ICA or end entity certificates will exist yet. Therefore even though the Root is intended to comply with BRs - it doesn't at that point, since by your logic, no interoperability certificates exist.

I agree with you however that any and all certs issued from such a Root at any subsequent point from Day 0 are INTENDED for public trust.

For three of the Roots submitted by DM, this is the case i.e. no issuing CA and no end entities had yet been issued from them until just this past week when we created some ICAs. Still at this point, no end entities have been issued - hence the reason why the asked for interoperability certs don't exist - no end entities exist. We are still in that time delta I noted above.

NOTE: One Root did have an Audit CA created beneath it and a number of end entities, but the Audit CA was created only for audit purposes and any end entities it issued were just for audit verification purposes. They still followed the entire SOPs for issuance like our cross-signed CAs only the Audit CA did not have CT Logs configured for its end entities.

> If you issue certificates from your root, they are publicly trusted.
> Full stop.
> There's no weaseling out of this, no creative interpretation. This has been clear and unambiguous and part of policy for some 
> time, so it's disappointing to hear a CA suggest otherwise.

Any certs we issue from these Roots are INTENDED to be publicly trusted - but they are NOT publicly trusted at this time. Full Stop. Is this the real disconnect happening here?? When I say publicly trusted - I mean exactly that, qualifying in every way up to an embedded Root. 

----

(In reply to Ryan's comment #47)

Your substitution example is extremely flawed in comparison to what we have been discussing...

The example you gave has a CA with a policy that clearly does not meet the BRs. My issue is that we wanted all end entities issued from subsequent ICAs (with the exception of the aforementioned Audit CA), to follow our current SOP of requiring a successful CT Log process before issuance. As you have already pointed out - this is not a current requirement of the BRs, so we are not operating with a non-compliant policy as your flawed example seeks to make an analogy to. So your substitution analogy simply does not apply in this case.

I also disagree with you that what Python or Chrome does is not relevant to whether DM is publicly trusted. DM created procedures that we anticipate will allow certificates issued to be trusted in many platforms more than those two. As long as those procedures and policies are compliant with the BRs or more restrictive, this is entirely fine. We have been audited based on these policies and procedures for the purpose of WebTrust BRs, EV & CA compliance. So for us, they do have an impact - because I need to explicitly follow my policies and procedures in order to achieve the public trust status.

> You can easily "fix" your policy to say that infrastructure certs as noted by the following profiles are exempt from being 
> logged.

We are agreed - this is the path to move forward on.

NOTE: SCTs were required by policy for end entities and not for ICAs.

Comment 49

[Ryan Sleevi]

(In reply to Scott Rea from comment #48)
> (In reply to Ryan's comment #46)
> 
> >  I do not believe this is an honest or correct answer, based on the previous replies.
> 
> Ryan, please maintain civility in your communications. It is not appropriate
> to call me dishonest - this is the second time you have done this on a
> public forum.

Scott, it would help if you can correct the record: Can you demonstrate the necessary certificates, as per 2.2 of the Baseline Requirements?

If you cannot, then what you stated in Comment #45, is factually incorrect. It is not a correct answer, and knowing that we're discussing precisely this matter, in the previous comments, it is not an honest answer either.

> For three of the Roots submitted by DM, this is the case i.e. no issuing CA
> and no end entities had yet been issued from them until just this past week
> when we created some ICAs. Still at this point, no end entities have been
> issued - hence the reason why the asked for interoperability certs don't
> exist - no end entities exist. We are still in that time delta I noted above.

Then these roots do not comply with the Baseline Requirements.

> NOTE: One Root did have an Audit CA created beneath it and a number of end
> entities, but the Audit CA was created only for audit purposes and any end
> entities it issued were just for audit verification purposes. 

Then they are publicly trusted certificates, and your statement about the inability to issue publicly trusted certificates is factually incorrect.

> Any certs we issue from these Roots are INTENDED to be publicly trusted -
> but they are NOT publicly trusted at this time. Full Stop. Is this the real
> disconnect happening here?? When I say publicly trusted - I mean exactly
> that, qualifying in every way up to an embedded Root. 

Again, this misunderstands the BRs - and the hopefully simple question I posed. The question of Intent is one that has been discussed amply within the CA/Browser Forum and m.d.s.p. - and more importantly for this conversation, the irrelevance of it. 

> 
> ----
> 
> (In reply to Ryan's comment #47)
> 
> Your substitution example is extremely flawed in comparison to what we have
> been discussing...

You're correct. It demonstrates an even more obvious divergence from the Baseline Requirements, of which the BRs say nothing about "trust in Chrome" or "logged in CT", as you've stated, but do clearly state the expectations under 2.2 of the BRs. You've completed an audit - which itself is questionable, given the situation around 2.2 - without having provided demonstration of BR compliance.

> The example you gave has a CA with a policy that clearly does not meet the
> BRs. My issue is that we wanted all end entities issued from subsequent ICAs
> (with the exception of the aforementioned Audit CA), to follow our current
> SOP of requiring a successful CT Log process before issuance. As you have
> already pointed out - this is not a current requirement of the BRs, so we
> are not operating with a non-compliant policy as your flawed example seeks
> to make an analogy to. So your substitution analogy simply does not apply in
> this case.

Again, please demonstrate your compliance to 2.2 of the BRs.

This is not a controversial or complex issue - the issuance of these certificates is bog-simple for a CA, but the reasons you're providing as to why you cannot issue such certificates are problematic, as are the fact that you have some form of audit without the completion of this. It calls into question about the operation of these roots, and the auditors, because this is not complex or controversial, but the attempts to paint it as such indicate an interpretation that severely undermines trust in these roots, and their operations.

Comment 50

[Ryan Sleevi]

(In reply to Scott Rea from comment #48)
> You cannot create the required interoperability certificates before the Root
> exists. Therefore, despite what you appear to be asserting above, there will
> exist some delta of time during which a Root INTENDED for Public Trust, will
> exist, but no ICA or end entity certificates will exist yet. Therefore even
> though the Root is intended to comply with BRs - it doesn't at that point,
> since by your logic, no interoperability certificates exist.

As to why this argument is incorrect:
DM would conduct a PITRA at the day of creation.
DM would create the necessary interoperability roots.
DM would conduct a POT over the period of 90 days.

There is no issue with the delta of time - it's fully accommodated for within the BRs, and DM has a substantial period of time to comply. The fact that DM has still not created such 2.2 certificates, however, is problematic, as stated, both for DM and their auditors.

Comment 51

[Scott Rea]

(In reply to Ryan's comment #49 and comment #50)

I think we are circling around a single issue here that has to do with your interpretation of the BRs vs my interpretation of the BRs. You are making some assertions about the BRs that are not codified in the document itself, and if that was the intention, then perhaps we should have clarification.

I think for point of reference, I will refer to BRs v1.5.0 (which was the valid version at the time we completed our audits) so that we have the right context in respect to what happened during our audit period. But also note that BR v1.5.9 has not changed these definitions.

BRs in 2.2 say:
> The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates 
> that chain up to each publicly trusted Root Certificate.  At a minimum, the CA SHALL host separate Web pages using Subscriber 
> Certificates that are (i) valid, (ii) revoked, and (iii) expired.  

BRs in 1.6.1 Definitions:
> Root Certificate: The self‐signed Certificate issued by the Root CA to identify itself and to facilitate verification of 
> Certificates issued to its Subordinate CAs. 

...and...
> Publicly‐Trusted Certificate:  A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is 
> distributed as a trust anchor in widely‐available application software.

Ryan I have been going by the BRs own definition regarding what a publicly trusted certificate is and until these Roots we have submitted are embedded somewhere, they do not meet the definition of publicly trusted certificate per the BR's definition. 

Now I agree with you that we should treat any certs issued as INTENDED to be publicly trusted, but there is no where that I can find in the BRs that uses this terminology. 

So the 2.2 requirement stated above for interoperability certificates that your keep referring to, according to my read, does not apply until the Root is embedded somewhere - otherwise it is not a publicly-trusted certificate.

Now we do operate ICAs that are cross-chained to someone else's publicly trusted Root certificate, and for these we do have the interoperability certificates issued - although it is not clear to me from the BR text whether this is a requirement on the Root operator or the ICA operator or both. Certainly one of them. but nonetheless we have these.

Our POT focused primarily on the on-going operations of the existing publicly trusted ICAs. We created the submitted Roots intended for public trust, and a single Audit CA to demonstrate the same policies and procedures (except CT Logging) were being followed for the existing ICAs with the intention of re-signing those ICAs once the Roots were embedded.

Also, you keep saying that we "...cannot issue the interoperability certificates" - I want to correct this concept: we CAN issue the interoperability certificates. My point has simply been that they will not be publicly trusted certificates until their corresponding Root is embedded somewhere. And at that point, the BRs apply. Until then, we can issue certs intended for public trust so that they qualify once their corresponding Root is embedded.

To be clear - we can do what you are asking. My point is - its not what the BRs say. If your interpretation is what the BRs were intended to say, then why not have them say exactly that??

At no point has DM issued any certificates chaining to these Roots that did not follow the BRs. Even the Audit CA for POT also followed BRs, other than this there have been no issuance from these Roots.

Last week we created new ICAs beneath each of the Roots, and this week we will create interoperability certificates (again in accordance with the BRs) that are intended for public trust - but they will not be publicly trusted, unless or until the corresponding Root is embedded as trusted.

Comment 52

[Ryan Sleevi]

(In reply to Scott Rea from comment #51)
> (In reply to Ryan's comment #49 and comment #50)
> 
> I think we are circling around a single issue here that has to do with your
> interpretation of the BRs vs my interpretation of the BRs. You are making
> some assertions about the BRs that are not codified in the document itself,
> and if that was the intention, then perhaps we should have clarification.

And I'm saying that there is no reasonable reason to take the interpretation you're taking - that is, to suggest that somehow, certain requirements only trigger once you're included.

Which raises a very simple concern: A CA that takes a 'creative interpretation' to justify not doing something highlights a CA that is willing to take shortcuts. A CA that doubles down on that creative interpretation is likely a CA that will fail to operate in the public trust.

It should be obvious the necessity to provide these interoperability certificates in order to assess public trust - and for the proper functioning of an audit (through the demonstration of issuance). There's no reasonable interpretation that somehow there's a threshold - at the CA's definition - upon which this requirement triggers. To take such a plainly obviously incorrect read is to similarly say that such certificates are not required until after being distributed by Microsoft, Google, Mozilla, Apple - and then whomever else the CA wants to name, such as saying Oracle, Opera, Python, AppEngine, etc. "We're not required to do this until Java is also distributing it" is a laughable interpretation, but that's the foundation of this argument - which is why, again, I say that the interpretation itself is problematic, and not *just* the failure to demonstrate 2.2 compliance.

If we want to further haggle over such things, then we'd point out that the definition is about "Publicly-trusted", which consistently uses the hyphenated form, but that this requirement is about "publicly trusted", unhyphenated, and thus must be separate terms with separate requirements. And while such an interpretation is laughable, it hopefully highlights exactly the sort of concern there is when a CA doesn't consistently take the maximally-restrictive interpretation, in order to operate beyond reproach.

> Also, you keep saying that we "...cannot issue the interoperability
> certificates" - I want to correct this concept: we CAN issue the
> interoperability certificates.

Thank you for affirmatively stating that, despite Comment #39, this is possible.

> Last week we created new ICAs beneath each of the Roots, and this week we
> will create interoperability certificates (again in accordance with the BRs)
> that are intended for public trust - but they will not be publicly trusted,
> unless or until the corresponding Root is embedded as trusted.

You are correct that these will not function in applications unless and until those applications trust such root certificates. They will be publicly trusted, in as much as if those applications trust those roots, such leaves are transitively trusted, in that they chain to that root.

The interpretative difference is this:
- You're arguing an interpretation that suggests it describes the certificates at a point in time. That is, prior to the root being included in some undefined quorum of stores, it is not publicly trusted, and following that event, it is
- I'm stating that the interpretation it describes potentiality. It is a 'publicly trusted' certificate by being issued underneath/chaining to a root that is operated for the intent (or actuality) of public trust.

The distinction is extremely security relevant, and meaningful, because the recognition of public trust in the root confers trust to everything that was ever issued.

If your interpretation was carried out to its logical extreme, then upon being recognized as publicly trusted, if that CA had issued any certificates previously, it might now be invalidating its state of audits under 8.1. That is, a CA that made the same argument as you could argue as follows:

Day 0: PITRA
Day 0: Create the root
Day 15: Create intermediates
Day 15: Issue a bunch of certificates for random servers.
Day 20: Apply to root stores
Day 200: Accepted in to one
Day 200: Issue 'interoperability' certs

Under the interpretation you're suggesting, the audit requirements of Section 8.1 would only kick in under Day 290 - 90 days after the issuance of those interoperability certs. But that's plainly incorrect, as the 8.1 requirement would have kicked in at Day 105 - 90 days after the issuance of a bunch of certs for random servers, since they now all automatically became publicly trusted, and the CA was expected to have an audit within 90 days of issuing a publicly trusted certificate.

Comment 53

[Scott Rea]

(In reply to Ryan's comment #52)

Thank you Ryan, this has indeed been a most illuminating debate, and I sincerely appreciate your willingness to engage. Your efforts to educate the community and raise potential issues, and engage in discussion/debate with community members are quite frankly amazing - I applaud your effort, and your commitment. (I just wanted to fully express my appreciation for the time and effort you have taken with me - it's been extremely helpful)

I have long considered that the BRs were written by the in-group, for the in-group, and do not adequately call out the expected processes for an outsider wanting to join the in-group. The outsiders sometimes struggle not because they are trying to accomplish anything of wrong intent, but because the step by step path is not as clear as it could be. 

NOTE: I can see that "Publicly-Trusted Certificate" is a formally defined term, and "publicly trusted certificate" is not. But I do not agree with you that I should therefore draw the conclusion that these should mean something completely different in the document. Does not your suggested approach lead to the creative excuse you claim bad acting CAs are looking for? I think my interpretation is more aligned with the definitions in the document itself. But if it is intentional that "publicly trusted certificate" mean something different to "Publicly-Trusted Certificate", then why not just adjust the definition for "Publicly-Trusted Certificate" to include certificates intended for public trust, and we could have avoided this confusion. Certainly it would have helped me...

I have no issues with the need to provide interoperability certificates and we are happy to comply - it was just a matter of when these are needed - and I was letting my understanding of their purpose guide me on that. NOTE: we created fully functional interoperability certs that chain to publicly trusted roots from the CA system that future publicly trusted certificates will be issued from the submitted roots. Therefore the format and profile compliance can be verified by the existing certs and the validation infrastructure that will apply when certs are publicly trusted can also be verified with what we have provided to date. What else is the creation of these interoperability certificates supposed to achieve?

> There's no reasonable interpretation that somehow there's a threshold - at the CA's definition - upon which this requirement 
> triggers. To take such a plainly obviously incorrect read is to similarly say that such certificates are not required until 
> after being distributed by Microsoft, Google, Mozilla, Apple...

Why are you claiming this is at a CA's discretion? It is quite clearly stated in the BRs that they must be available for "publicly trusted Root Certificates", and I refer you to the NOTE above for my understanding of when the BRs state that is. So to use your process flow above, I believed it should look something like this:

Day 0: Issue certs according to BRs from existing ICAs
Day 0: PITRA
Day 0: Create the new Root
Day 0: Create an audit intermediate
Day 1: Issue certs according to BRs from existing ICAs
Day 1: Issue similar certs in parallel according to BRs from audit CA (same CA platform/config/SOPs minus CT)
Day 90: POT on audit CA data 
Day 120: WebTrust Audit report
Day 125: Migrate existing ICAs to WT audited platform
Day 125: Migration Audit report from WebTrust auditors on existing ICAs
Day 130: Apply to root stores
Day 150: Issue interoperability certs from existing ICAs
Day 200: Accepted in to one of the browser stores
Day 200: Resign existing ICAs under the newly included Root
Day 200: Existing Interoperability certs can now chain to new Root.

NOTE2: I don't know what the intention of "Issue a bunch of certificates for random servers" in your previous comment mean?? Any TLS certs we are issuing come from our existing public trust ICAs until one of the Roots is accepted somewhere and the ICA is re-signed under that Root 

As you can see from the timeline of events above, we do NOT run afoul of the audit requirement in 8.1 - any of our public trust certificates are coming from our existing ICAs and not from new hierarchy.

Final note: in comment #39, I was not saying we couldn't issue the requested interoperability certificates, only that to do so required changes and we didn't want to make those unnecessarily. You have convinced me its necessary ;-)

Hopefully this clarifies the misunderstanding. We will be creating interoperability certs this week chaining to the Roots submitted. Existing interoperability certs exist chaining to existing publicly trusted ICAs.

I still think some exercise to clarify the meaning of Publicly-Trusted Certificated should be undertaken in the BRs to add the "intended for public trust" purpose you have been advocating.

Comment 54

[Ryan Sleevi]

(In reply to Scott Rea from comment #53)
> I have long considered that the BRs were written by the in-group, for the
> in-group, and do not adequately call out the expected processes for an
> outsider wanting to join the in-group. 

I don't agree.

> The outsiders sometimes struggle not
> because they are trying to accomplish anything of wrong intent, but because
> the step by step path is not as clear as it could be. 

As an outsider, it's true that you are expected to know how to be a trustworthy CA. The ecosystem is not designed to help you to learn how to be trustworthy - the ecosystem does not improve from having more applicants who lack that knowledge - and so yes, the baseline expectation is that applying CAs are operated beyond reproach.

> NOTE: I can see that "Publicly-Trusted Certificate" is a formally defined
> term, and "publicly trusted certificate" is not. But I do not agree with you
> that I should therefore draw the conclusion that these should mean something
> completely different in the document. Does not your suggested approach lead
> to the creative excuse you claim bad acting CAs are looking for? 

That was exactly the point I was making, so you correctly understood the purpose of that comparison.

> I have no issues with the need to provide interoperability certificates and
> we are happy to comply - it was just a matter of when these are needed - and
> I was letting my understanding of their purpose guide me on that. NOTE: we
> created fully functional interoperability certs that chain to publicly
> trusted roots from the CA system that future publicly trusted certificates
> will be issued from the submitted roots. Therefore the format and profile
> compliance can be verified by the existing certs and the validation
> infrastructure that will apply when certs are publicly trusted can also be
> verified with what we have provided to date. What else is the creation of
> these interoperability certificates supposed to achieve?

I am disappointed that this is not immediately obvious to a CA. The purpose of these roots is to test the correctness of issuance and path building. If they serve no purpose, then there's further no purpose in including the roots that lack them.

> > There's no reasonable interpretation that somehow there's a threshold - at the CA's definition - upon which this requirement 
> > triggers. To take such a plainly obviously incorrect read is to similarly say that such certificates are not required until 
> > after being distributed by Microsoft, Google, Mozilla, Apple...
> 
> Why are you claiming this is at a CA's discretion? It is quite clearly
> stated in the BRs that they must be available for "publicly trusted Root
> Certificates", and I refer you to the NOTE above for my understanding of
> when the BRs state that is. 

This appears to be another area where you're not understanding the point I am making. Using the definition you're arguing from to support your explanation, "widely-available application software" can be read as either singular (a single widely available application) or plural (multiple different products), and widely-available can be argued as a subjective (the latest version of macOS is not widely available because users have not upgraded to it).

As you can see, these "good faith" interpretations, whether or not they are such, are problematic because it leaves it up to the CA to try to argue what is and is not "widely-available application software". This is not an intrinsic flaw of the BRs - it's a flaw of applying the interpretation you are doing (suggesting it's a statement about a point in time, as illustrated in Comment #52)

> NOTE2: I don't know what the intention of "Issue a bunch of certificates for
> random servers" in your previous comment mean?? Any TLS certs we are issuing
> come from our existing public trust ICAs until one of the Roots is accepted
> somewhere and the ICA is re-signed under that Root 

This is because you misunderstood. I was demonstrating how your interpretation is fundamentally flawed, because it creates the situation described. That is, if you apply the definition you've argued for, you can see it doesn't work, because it creates the possibility for a compliant CA to be declared retroactively non-compliant once the trust event threshold has been passed. This should make it clear that it's an illogical read and interpretation.

> I still think some exercise to clarify the meaning of Publicly-Trusted
> Certificated should be undertaken in the BRs to add the "intended for public
> trust" purpose you have been advocating.

Given your interpretation cannot be correct, as demonstrated by Comment #52, it's again reiterating - it's merely labeling the holistic set of certificates underneath the root that is, or intended to be, publicly trusted. It is not about the intent of leaves, but of root.

Comment 55

[Scott Rea]

(In reply to Ryan's comment #54)

> The purpose of these roots is to test the correctness of issuance and path building. If they serve no purpose, then there's 
> further no purpose in including the roots that lack them.

The existing interoperability certificates we provided contain the correctness of issuance evidence. The only lacking piece is complete path building to the submitted Root. An appropriate path is still built, just not containing the submitted Root as the final anchor - this equates to a single AIA in an ICA. What risk is this presenting to Software Application providers? We are using a Root they already trust instead of asking them to import the currently untrusted one?

> This is because you misunderstood. I was demonstrating how your interpretation is fundamentally flawed, because it creates the 
> situation described. That is, if you apply the definition you've argued for, you can see it doesn't work, because it creates 
> the possibility for a compliant CA to be declared retroactively non-compliant once the trust event threshold has been passed. 
> This should make it clear that it's an illogical read and interpretation.

Please re-read the process flow from my comment #53 and tell me where my interpretation breaks down. It does work. No retroactive non-compliance is created at any point by this flow if you consistently apply the interpretation of the defined terms in the BRs as I previously pointed out.

In fact, every audit event is by design meant to create the opportunity to discover any non-compliance - that is core to their very purpose. If non-complaint certs were issued and not corrected, then the audit should illuminate these. Even as good as CT is for helping discover mis-issuance, it is still a discovery of retroactive non-compliance.

Having interoperability certificates issued from a chain to the submitted root still does not rule out mis-issuance or non-compliance - the purpose of the audit is to discover that piece.

Anyhow, I am willing to concede that the intention of the BRs is as you have claimed. We have created ICAs, and are creating the interoperability certificates this week. Just in time for the kick off of our annual WT Audit...

Comment 56

[Ryan Sleevi]

(In reply to Scott Rea from comment #55)
> The existing interoperability certificates we provided contain the
> correctness of issuance evidence.

That is not the purpose of them.

> The only lacking piece is complete path
> building to the submitted Root. 

This is the purpose of them.

> An appropriate path is still built, just not
> containing the submitted Root as the final anchor - this equates to a single
> AIA in an ICA. What risk is this presenting to Software Application
> providers? We are using a Root they already trust instead of asking them to
> import the currently untrusted one?

You mean what is the risk of a CA being non-compliant and arguing about that non-compliance? As m.d.s.p. has shown, rather significant and rather high, as it signals a CA willing to stretch things to an extreme, to the potentiality of hiding misissuance. This is seen consistently through such interpretative dances, so whether or not that is the intent, that is certainly how it appears.

> Please re-read the process flow from my comment #53 and tell me where my
> interpretation breaks down. It does work. No retroactive non-compliance is
> created at any point by this flow if you consistently apply the
> interpretation of the defined terms in the BRs as I previously pointed out.

That's not true. I already showed you how it breaks down. It creates a situation in which a CA can successfully complete multiple period of time audits, but the mere issuance of any certificate (such as an intermediate) can retroactively invalidate those results of audits.

> In fact, every audit event is by design meant to create the opportunity to
> discover any non-compliance - that is core to their very purpose. If
> non-complaint certs were issued and not corrected, then the audit should
> illuminate these. Even as good as CT is for helping discover mis-issuance,
> it is still a discovery of retroactive non-compliance.

You again misunderstand. The interpretation you suggest creates itself non-compliance by the act of being trusted, such that audits that previously (and correctly) assessed compliance can now be demonstrated, after the CA is trusted, as retroactively non-compliant. It makes no sense.

Comment 57

[Scott Rea]

(In reply to Ryan's comment #56)

>> The existing interoperability certificates we provided contain the correctness of issuance evidence.
> That is not the purpose of them.

But in comment #54 you said:
> The purpose of these roots is to test the correctness of issuance and path building.

So is part of the purpose or not to provide correctness of issuance? Because in comment #54 you said it is, but now in comment #56 you say its not...??

> You mean what is the risk of a CA being non-compliant and arguing about that non-compliance?
No, this is not what I mean. The only one stretching hypotheticals here Ryan has been you. As you already know, we haven't had any issuance from the submitted Roots, so that makes it pretty hard to have mis-issuance also.

> I already showed you how it breaks down. It creates a situation in which a CA can successfully complete multiple period of time 
> audits, but the mere issuance of any certificate (such as an intermediate) can retroactively invalidate those results of 
> audits.
No, you have not shown this. Please follow the process flow I laid out in comment #53 and show me at what point retroactive invalidation of audit results occur. You are making a claim that it does but have not provided any evidence or description of how. Please elaborate.

> The interpretation you suggest creates itself non-compliance by the act of being trusted, such that audits that previously (and 
> correctly) assessed compliance can now be demonstrated, after the CA is trusted, as retroactively non-compliant. It makes no 
> sense.
We agree - it makes no sense... I am just not seeing the retroactive non-compliance you are referring to...

Please help me understand this scenario you are describing. How does this retroactive non-compliance occur?

Comment 58

[Ryan Sleevi]

(In reply to Scott Rea from comment #57)
> (In reply to Ryan's comment #56)
> 
> >> The existing interoperability certificates we provided contain the correctness of issuance evidence.
> > That is not the purpose of them.
> 
> But in comment #54 you said:
> > The purpose of these roots is to test the correctness of issuance and path building.
> 
> So is part of the purpose or not to provide correctness of issuance? Because
> in comment #54 you said it is, but now in comment #56 you say its not...??

I'm not sure your objective, but I think the interaction here is proving very difficult, especially as a predictor of future behaviour and interpretation. I would hope that if DM misissues, we don't have to go through 20 bug comments trying to argue about whether it is or is not misissuance - that's generally not conducive to trustworthy behaviour, which is operating without reproach.

As noted, I highlighted two purposes: issuance AND path building. I'm not sure how there's confusion, in that failing to provide demonstration of path building is not providing evidence of issuance and path building. It's not a singular purpose.

> > You mean what is the risk of a CA being non-compliant and arguing about that non-compliance?
> No, this is not what I mean. The only one stretching hypotheticals here Ryan
> has been you. As you already know, we haven't had any issuance from the
> submitted Roots, so that makes it pretty hard to have mis-issuance also.

Again, this misunderstands the point, which is itself problematic. You have not issued the required certificates under 2.2. We've acknowledged that repeatedly. The fact that you're still not acknowledging it is non-compliance is problematic. The pattern of behaviours is problematic.

> > I already showed you how it breaks down. It creates a situation in which a CA can successfully complete multiple period of time 
> > audits, but the mere issuance of any certificate (such as an intermediate) can retroactively invalidate those results of 
> > audits.
> No, you have not shown this. Please follow the process flow I laid out in
> comment #53 and show me at what point retroactive invalidation of audit
> results occur. You are making a claim that it does but have not provided any
> evidence or description of how. Please elaborate.

Please read Comment #52. That shows how your fundamental interpretation breaks down.

I understand in Comment #53 that you made up your own additional categories ("audit certificates"). However, that explanation only works because you're accepting that those "audit certificates" constitute issuing PTCs, as otherwise, you would not need the POT on Day 90 - and if you failed to obtain it, you'd be non-compliant. 

However, to be clear, I don't think this is going to further a productive conversation. 

At this time, I view DM as non-compliant with Section 2.2. As stated, I think it calls into question the operation, not just because of something so "simple" and "small", but the whole exchange in which an easily rectified situation takes a meandering set of explanations about why it'd be difficult or undesirable to correct, and which interpretations are stretched in order to argue non-compliance. I can understand the self-interest in arguing non-compliance, but I think it just serves to undermine trust in the operations.

Comment 59

[Scott Rea]

(in reply to Ryan's comment #58)

Ryan this has indeed been a long thread and I thank you once again for being willing to engage. Your insights have been extremely valuable. 

As an outcome of thoroughly exploring these topics, DM has/is taking the following steps:

1. Create an Issuing CA under each of the submitted Roots (task completed last week)
2. Create the minimal 3 types of interoperability certificates chaining to each of the submitted Roots. (expected completion this week)
3. Update the existing web pages with the new interoperability certificates (expected completion this week)

Thank you again for your input.

Comment 60

[Peter Bowen]

(up front disclaimer and disclosure: I'm only speaking for myself, but I do work for a company affiliated with a trust service provider that has root CAs included in Mozilla trust store)

I think Scott reasonably points out that the BRs are not always clear.  There are also a number of interactions between Mozilla policy and the BRs that are somewhat non-intuitive.

A few key things that I learned submitting root CAs:

1) The application to be included in the Mozilla CA program is per-root CA (defined as the combination of Subject DN, Subject Public Key Information, and Subject Key Identifier).  The owner and operator of the root CA is part of the info required, but operation of one root or issuing CA does not imply the others are accepted.

2) The Mozilla CA program operates very similarly to a PKI bridge authority with the caveat that it does not issue cross-certificates nor does it include policy mapping data in the trust store.  The effective name of the bridge is "publicly trusted" bridge.

3) Root CAs are only accepted that agree to follow the "publicly trusted" CP (also called the CA/Browser Forum Baseline Requirements; "the BRs") from the time they are created.  The Root CA operator is responsible for assuring that any CA that is the subject of a cross-certificate issued by the Root CA follows the BRs and Mozilla policy, including making sure they get the same assurance from any further cross-certified CAs.  Note that in this context, "CA" means the combination of Subject DN, Subject Public Key Information, and Subject Key Identifier; a single trust service provider will almost always operate a number of CAs.

4) "Publicly trusted" is used in the BRs to only clarify that CAs that a Trust Service Provider operates that are never intended to be cross-signed into the "Public Trust PKI" or "WebPKI" are not required to follow the BRs.  For example, a TSP might operate a private CA for a community that is shares HSM with a CA in the WebPKI, but the private community CA may issue certificates that are not compliant with the BRs.  By submitting an application to Mozilla, you are implicitly declaring that the CA is a "publicly trusted" CA.

5) As a result of interaction between different parts of the BRs, each Root CA submitted to Mozilla must cross-sign at least one "issuing" CA which must issue at least three end-entity certificates prior to completing the application to Mozilla.  This is because Root CAs are not allowed to issue end-entity certificates as per BR section 6.1.7.

6) The last paragraph of BR section 2.2 would probably be clearer if it was phrased as:

"The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each Root CA that follows these Requirements. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."

7) There is a chicken-and-egg problem in BR section 8.1 for new CAs, but that does not seem to be at issue here.

I'm sure there are more places that need clarity, but hopefully this is a start.  I hope that the CA/Browser Forum will add clarity to the BRs, but until then you have to read between the lines at times.

Comment 61

[Scott Rea]

(in reply to Peter's comment #60)

Extremely helpful Peter - thank you!

Despite being granted a successful WebTrust Period of Time audit, and having a subsequent migration audit involving two different WebTrust audit firms, it seems that DM was lacking the correctly chained interoperability certificates from 2.2 of the BRs even though we set up the required web pages.

This will be rectified this week. 

Somehow we need to capture Peter's feedback above to provide a decent set of guide posts to the next Mozilla Root Program applicant. If nothing else, it will lower Ryan's blood pressure and cut back on the effort he undertakes to make sure folks are following the intended rules.

Comment 62

[Scott Rea]

Please NOTE: DM has updated the interoperability certificates for all 4 submitted Roots per Ryan's explanation in this past week.

The 2 UAE Global Trust Roots and links to corresponding interoperability certs may be found here:
https://ca.darkmatter.ae/UAE/index.html

The 2 DM Commercial Roots and links to corresponding interoperability certs may be found here:
https://ca.darkmatter.ae/DM/index.html

I believe the final item Mozilla is now waiting for is a copy of our update CPS - a link to this will be posted soon.

Comment 63

[Wayne Thayer]

(In reply to Scott Rea from comment #61)
> (in reply to Peter's comment #60)
> 
> Somehow we need to capture Peter's feedback above to provide a decent set of
> guide posts to the next Mozilla Root Program applicant. If nothing else, it
> will lower Ryan's blood pressure and cut back on the effort he undertakes to
> make sure folks are following the intended rules.

Scott: if you have specific suggestions for improvements to the Mozilla root store policy that would help future applicants, I would appreciate it if you would propose them here: https://github.com/mozilla/pkipolicy/issues (an email to me would also suffice).

Comment 64

[Scott Rea]

(In reply to Wayne's comment #63)

G'day Wayne, my reference was actually to clarifications needed on the interpretation of BR terminology. To the extent that Mozilla relies upon the BRs there is a potential impact, but I think probably the best place to make the clarification is in the BR docs themselves. 

Specifically, as Peter & Ryan have also pointed out in this thread, when the BRs refer to "publicly trusted certificates", this should be interpreted as any certificates intended to be publicly trusted, and perhaps this should be added to the definitions section?? The section in question impacted by this and also relevant to the Mozilla Root Policy was for 2.2. of the BRs in respect to interoperability certificates.

Comment 65

[Scott Rea]

Please note that updated CPS has now been posted to the repository: https://ca.darkmatter.ae/CPS/DM_CPS_V1.6.pdf

I believe this closes the quested updates from DM's end. Please advise if any additional clarifications are needed.

Comment 66

[Kathleen Wilson]

Scott, Please explain what the term "Bridge CA" means in the CP and CPS.

Comment 67

[Kathleen Wilson]

Also, does https://ca.darkmatter.ae/CPS/DM_CPS_V1.6.pdf govern the UAE Global roots as well as the DarkMatter roots? 
The only mention of the UAE Global roots that I find in the CPS is in a table in section 7.5.2, but it's not clear to me which roots this CPS governs.

Comment 68

[Scott Rea]

(In reply to Kathleen's comment #66)

The UAE National PKI originally planned to grant trust to external providers to internal trust communities via use of a Bridge CA, and hence this language was used in the CP & CPS. This approach may still be used internally, however the NPKI is now moving down the path of managing a Trust List instead. A Bridge CA is not a trust anchor, but really a way of mapping the policies of one trust community to those of an orthogonal trust community via use of cross-certificates - a classic example of this is the US Federal Bridge CA.

The UAENPKI does not operate any bridge CAs at this time.


(In reply to Kathleen's comment #67)

DM_CPS_V1.6.pdf covers both UAE Global Roots and the DarkMatter Roots. Section 1 of the CPS, second paragraph starts with:

"This DarkMatter Certification Practice Statement (hereinafter, CPS) applies to all certification services provided by DarkMatter in the context of the UAENRCA and any other PKIs authorized by the DarkMatter PKI Policy Authority (DMPPA)."

Comment 69

[Kathleen Wilson]

(In reply to Scott Rea from comment #68)
> (In reply to Kathleen's comment #66)
> 
> The UAE National PKI originally planned to grant trust to external providers
> to internal trust communities via use of a Bridge CA, and hence this
> language was used in the CP & CPS. This approach may still be used
> internally, however the NPKI is now moving down the path of managing a Trust
> List instead. A Bridge CA is not a trust anchor, but really a way of mapping
> the policies of one trust community to those of an orthogonal trust
> community via use of cross-certificates - a classic example of this is the
> US Federal Bridge CA.

That's what I was worried about. Mozilla never approved/included the US Federal Bridge CA, so if you are planning to do something like that, then I think that will likely be a show stopper.

> 
> The UAENPKI does not operate any bridge CAs at this time.

But the CP and CPS allow for it.

> 
> 
> (In reply to Kathleen's comment #67)
> 
> DM_CPS_V1.6.pdf covers both UAE Global Roots and the DarkMatter Roots.
> Section 1 of the CPS, second paragraph starts with:
> 
> "This DarkMatter Certification Practice Statement (hereinafter, CPS) applies
> to all certification services provided by DarkMatter in the context of the
> UAENRCA and any other PKIs authorized by the DarkMatter PKI Policy Authority
> (DMPPA)."


I'm not sure if that's enough, especially since the CP seems to indicate that there may be more than one CPS document. I think it would be better to have a clear statement about which root certificates this CPS applies to.

Anyways, I'll continue my review of the updated info.

Comment 70

[Scott Rea]

(In reply to Kathleen's comment 69)

A Bridge CA does not function as a trust anchor, so Mozilla or any Trust Store Operator for that matter, should never receive one as a submission. Certainly DarkMatter will not submit any Bridge CAs to Mozilla for inclusion. The current anchors submitted by DM are NOT Bridges, and will never become Bridge CAs. 

The DM CPS covers both Private Trust and Public Trust PKI operations, and therefore the potential capacity to operate a Bridge CA (originally anticipated for the Private PKI space) is included in the CPS to facilitate potential future services if they are needed.

The UAE National CP is a policy designed to govern all PKI operators within the UAE and not just the NPKI. So you are correct in that the CP is written in anticipation of multiple operators, each with their own unique CPS, as DM has provided with DM_CPS_V1.6.pdf.

I think Section 7.5.2 of the DM_CPS_V1.6.pdf is fairly explicit about which roots are in scope: It refers the reader to the repository which clearly enumerates the Publicly Trusted Roots and Issuing CAs, and then the CPS goes on to explicitly detail the names, serials, and hashes of each Publicly Trusted Root and Issuing CA in scope. I am not sure how we would more explicit than this - can you give me an example of what you are looking for here?

Comment 71

[Kathleen Wilson]

(In reply to Scott Rea from comment #70)
> Certainly DarkMatter will not submit any Bridge CAs to Mozilla for
> inclusion. The current anchors submitted by DM are NOT Bridges, and will
> never become Bridge CAs. 

We would need that made clear in the CPS -- that the specified root certs cannot sign Bridge CAs. Another option is to remove references to Bridge CAs from this CPS.

> I think Section 7.5.2 of the DM_CPS_V1.6.pdf is fairly explicit about which
> roots are in scope: 

Section 7.5.2 currently says:
"Note that all DarkMatter CA Certificates and CRLs are available for download from the DarkMatter CA Repository at:
http://ca.darkmatter.ae/
The following table provides Publicly Trusted Root and Issuing CA Certificate information and hashes:"

Section 1.4.1 says: "DarkMatter CAs outside the UAENRCA scope do not have the above restrictions."

So, I'm not seeing the binding between the listed roots and this CPS. Nor am I seeing a clear binding between "DarkMatter CAs" and this CPS.

> I am not sure how we would more
> explicit than this - can you give me an example of what you are looking for
> here?

Here's an example of what this could like like, and could be in Section 1, second paragraph. But I'm not sure if this is correct terminology regarding "DarkMatter CAs".

"This CPS covers all certificates issued and signed by the CAs listed in Section 7.5.2 hereinafter referred to as DarkMatter CAs."

Comment 72

[Kathleen Wilson]

Attachment: 1427262-CA-Information-Sept26-2018.pdf

The attached file shows the CA information that has been verified. Search in the document for the word "NEED" to see where further clarification is requested.

In particular:

1) Update CPS to contain clear binding between the CPS and these root certs and their subCAs.

2) Remove references to Bridge CA from this CPS, or clarify that these root certs cannot sign a Bridge CA.

Comment 73

[Kathleen Wilson]

Please also make sure that your next audit statements fully comply with Mozilla's requirements:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

Comment 74

[Scott Rea]

(In reply to Kathleen's comment #72)

The recommendations for CPS have been applied, new CPS is approved and published to the DM repository - see:
https://ca.darkmatter.ae/CPS/DM_CPS_v1.7.pdf

We believe this addresses all NEED clarifications in the attachment to comment #72


(in reply to Kathleen's comment #73)
The second annual full WT audit report is pending and is expected to be published soon. Auditors were reminded of Mozilla's requirements prior to preparation of the findings and it is anticipated an appropriate report will be produced by KPMG.

Comment 75

[Scott Rea]

This is an advisory on issuance related to this submission.

Please Note that DM has created two new Issuing CAs that respectively chain to two of the Public anchors submitted via this case.  The intention of these issuers is targeted at Client certificates and not TLS. 

DigitalX1 Assured CA G4 - signed by UAE Global Root CA G4
DM X1 Assured CA G4 - signed by DarkMatter Root CA G4


Details of these ICAs are contained below.

DigitalX1 Assured CA G4
Certificate details:
		               Data:
        Version: 3 (0x2)
        Serial Number: 7899033981911195519 (0x6d9f018e408e5f7f)
    Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=AE, O=UAE Government, CN=UAE Global Root CA G4
        Validity
            Not Before: Sep  5 09:42:06 2018 GMT
            Not After : Sep  5 09:42:06 2028 GMT
        Subject: C=AE, O=DarkMatter LLC, CN=DigitalX1 Assured CA G4
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:c7:4d:7c:e5:28:06:9b:d2:16:f2:34:30:c3:49:
                    0b:b4:4c:f7:d8:29:30:51:14:38:b7:39:67:d2:cd:
                    a3:69:fc:73:24:1c:38:fa:e1:cc:b8:75:f1:2f:dd:
                    ff:ce:e7:21:35:53:1c:d1:01:44:9d:ce:80:95:b2:
                    a0:28:5d:2d:c4:74:9a:c9:c1:ef:ad:c4:fb:97:81:
                    72:22:d1:ef:3a:8b:ab:95:5c:37:e8:7b:14:b8:1b:
                    3f:24:ea:d6:01:e3:7d:1f:fa:fc:ec:70:fe:0a:42:
                    1b:a8:cf:65:36:05:75:8b:43:90:70:24:2b:04:cd:
                    a9:21:bd:5f:95:4c:81:6d:de:9e:01:5b:da:e6:47:
                    03:af:81:f5:18:4f:c3:5f:46:72:ac:25:cc:24:07:
                    c2:9d:a5:b7:dd:b3:95:3a:e1:23:4b:ba:bf:92:09:
                    7b:0c:87:e3:d9:c5:b7:08:51:37:77:4f:b2:b8:09:
                    99:91:2f:7f:12:21:f4:c4:88:b6:f9:8d:f0:6a:76:
                    c0:4d:4d:77:30:71:6c:a4:fe:f0:f7:90:7a:57:a7:
                    e1:b8:4b:70:5e:94:58:61:56:d7:74:e4:2b:f0:0e:
                    b0:d1:69:79:4f:8d:7a:b9:5d:10:2c:52:ab:8a:90:
                    2c:f5:db:18:26:0d:1c:bd:73:9e:46:8d:31:87:fe:
                    32:cc:40:85:d1:27:71:98:1b:b1:b2:f4:b0:4e:5a:
                    6f:35:a9:6a:0e:c6:61:25:15:58:c6:03:57:76:c0:
                    fd:df:bd:71:2d:9a:c2:08:1f:4b:7c:ce:b7:9c:9e:
                    64:c2:a9:e8:bb:c6:70:ea:cc:15:fd:99:dd:f0:e2:
                    d0:4a:67:23:f8:44:ff:4c:4b:fe:4f:7c:62:51:0c:
                    3a:a4:da:1c:51:f1:18:34:e2:ce:b8:d1:51:2f:df:
                    8f:30:50:52:52:f7:d0:89:90:de:47:a4:04:e2:ba:
                    8a:70:f5:b0:d3:1d:ec:f1:a2:8b:0e:41:ec:91:4d:
                    73:06:53:9a:09:85:4b:97:bc:24:41:ad:70:4f:3e:
                    dc:b2:e1:01:f5:41:61:4c:a9:02:3d:60:a1:a7:da:
                    60:3d:d6:8a:c0:98:47:64:2e:3a:f0:c5:ed:f8:7b:
                    56:57:a0:3f:5a:9d:f6:da:36:3b:d2:08:86:08:fa:
                    b4:94:19:5b:b5:04:14:9b:b4:8b:5d:bf:d5:80:51:
                    7e:9d:a9:80:ab:aa:df:31:24:30:0b:87:e2:4b:5b:
                    eb:2c:00:f0:cf:6e:a9:23:df:d1:5b:ae:e8:65:6b:
                    bb:9e:b1:1f:45:58:c9:38:b7:84:2e:b0:55:ae:cf:
                    1c:a3:2b:b3:16:76:a6:19:08:fa:3c:73:60:7d:6c:
                    3d:8b:0d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:http://cacerts.darkmatter.ae/UAEGlobalRootCAG4.crt
                OCSP - URI:http://ocsp.darkmatter.ae
 
            X509v3 Subject Key Identifier: 
                A6:74:8B:D4:25:F6:2F:F6:1F:D0:95:AB:B3:2A:E1:F2:5E:35:F4:8A
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Authority Key Identifier: 
                keyid:D5:2F:9A:E9:E8:17:00:D9:57:52:D0:3F:07:2B:4F:66:08:EB:F5:54
 
            X509v3 Certificate Policies: 
                Policy: 2.16.784.1.1.7.35.2.2.2
                  CPS: https://ca.darkmatter.ae/CPS
                Policy: 2.16.784.1.1.7.35.2.2.2.7
 
            X509v3 CRL Distribution Points: 
 
                Full Name:
                  URI:http://crl1.darkmatter.ae/UAEGlobalRootCAG4.crl
 
                Full Name:
                  URI:http://crl2.darkmatter.ae/UAEGlobalRootCAG4.crl
 
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection, 1.3.6.1.4.1.311.10.3.12, OCSP Signing
    Signature Algorithm: sha384WithRSAEncryption
         13:99:fe:e0:02:ec:15:4f:ac:9c:cf:a2:5f:5c:87:b3:ea:a9:
         2a:29:78:08:7d:91:d2:ff:1c:95:a6:14:b8:11:0e:61:75:a4:
         00:5b:c9:00:25:86:58:25:29:62:a8:a8:9d:6a:10:1c:06:6c:
         e5:26:5a:71:98:2e:df:92:c5:a6:b8:36:2d:5a:a1:f6:72:37:
         7d:f9:33:0e:c7:0d:76:81:0a:52:c7:4d:9c:fb:ec:4b:8d:29:
         eb:8c:8d:87:3e:4b:70:21:f7:83:3b:19:9b:2a:0b:e0:7e:ee:
         f9:14:1b:36:65:9d:4a:ee:fb:74:33:fc:ab:91:1f:9b:f2:16:
         58:9b:3c:c4:8b:a1:01:29:42:06:2d:47:01:c0:04:ab:fa:cf:
         cf:68:52:a7:23:5b:9c:ce:a3:76:f5:81:6d:2f:08:2e:ab:67:
         e1:c7:e3:41:85:55:ac:3b:78:5e:99:79:fe:78:77:22:0c:18:
         a5:64:35:a0:04:17:dd:4f:1a:1b:52:04:d0:b4:ec:15:17:f6:
         57:33:b5:16:62:5b:82:a7:67:38:62:c7:aa:2d:a1:44:7b:b6:
         b1:4b:94:67:61:f2:59:61:6f:49:4f:d3:76:3c:ac:05:f7:5e:
         29:32:bc:3b:ce:d9:96:0d:18:54:c8:c0:b6:18:1c:1a:1a:4d:
         91:a8:96:58:43:90:f2:39:b1:5c:84:8a:65:ae:77:b4:11:16:
         12:c3:a1:5a:14:d9:32:b3:82:ee:fa:a1:53:75:1f:4a:b2:87:
         b6:13:2e:a9:a3:34:df:99:d7:fa:07:96:57:35:61:90:75:cf:
         df:1d:46:6a:35:9b:04:92:74:5c:47:71:e8:fb:44:1b:d1:04:
         d4:6c:bf:a7:5c:7e:0c:01:42:21:7e:da:ac:16:3d:cd:f3:77:
         fc:3e:da:e7:c2:76:bc:f2:4d:9c:82:ec:6b:d7:cd:4f:42:29:
         9f:b9:2b:ab:a3:73:04:e3:5c:7d:ab:2e:88:2c:18:a9:41:34:
         1b:50:ba:96:de:1f:fb:f7:da:95:10:3f:4d:71:d0:e0:14:98:
         20:9e:b7:b2:4d:a1:ae:85:e6:6d:24:c1:25:89:9b:a0:3d:06:
         94:3e:0a:8f:70:3f:8f:98:c3:5a:ba:37:0a:49:1b:33:3c:8a:
         f5:e9:ba:28:2e:24:88:12:72:ec:8d:cb:b4:a3:fb:94:9e:06:
         58:a5:65:30:4c:38:5a:66:e7:b2:d7:f4:17:63:ab:8d:a9:b6:
         99:ac:ca:57:ea:02:2e:ac:3c:5b:65:b9:42:83:9e:ec:77:4e:
         31:73:da:f7:08:7b:41:a2:fb:d0:6a:17:91:c4:7d:55:8a:56:
         16:33:64:6d:2d:65:11:a5
-----BEGIN CERTIFICATE-----
MIIG8zCCBNugAwIBAgIIbZ8BjkCOX38wDQYJKoZIhvcNAQEMBQAwRjELMAkGA1UE
BhMCQUUxFzAVBgNVBAoMDlVBRSBHb3Zlcm5tZW50MR4wHAYDVQQDDBVVQUUgR2xv
YmFsIFJvb3QgQ0EgRzQwHhcNMTgwOTA1MDk0MjA2WhcNMjgwOTA1MDk0MjA2WjBI
MQswCQYDVQQGEwJBRTEXMBUGA1UECgwORGFya01hdHRlciBMTEMxIDAeBgNVBAMM
F0RpZ2l0YWxYMSBBc3N1cmVkIENBIEc0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAx0185SgGm9IW8jQww0kLtEz32CkwURQ4tzln0s2jafxzJBw4+uHM
uHXxL93/zuchNVMc0QFEnc6AlbKgKF0txHSaycHvrcT7l4FyItHvOourlVw36HsU
uBs/JOrWAeN9H/r87HD+CkIbqM9lNgV1i0OQcCQrBM2pIb1flUyBbd6eAVva5kcD
r4H1GE/DX0ZyrCXMJAfCnaW33bOVOuEjS7q/kgl7DIfj2cW3CFE3d0+yuAmZkS9/
EiH0xIi2+Y3wanbATU13MHFspP7w95B6V6fhuEtwXpRYYVbXdOQr8A6w0Wl5T416
uV0QLFKripAs9dsYJg0cvXOeRo0xh/4yzECF0SdxmBuxsvSwTlpvNalqDsZhJRVY
xgNXdsD9371xLZrCCB9LfM63nJ5kwqnou8Zw6swV/Znd8OLQSmcj+ET/TEv+T3xi
UQw6pNocUfEYNOLOuNFRL9+PMFBSUvfQiZDeR6QE4rqKcPWw0x3s8aKLDkHskU1z
BlOaCYVLl7wkQa1wTz7csuEB9UFhTKkCPWChp9pgPdaKwJhHZC468MXt+HtWV6A/
Wp322jY70giGCPq0lBlbtQQUm7SLXb/VgFF+namAq6rfMSQwC4fiS1vrLADwz26p
I9/RW67oZWu7nrEfRVjJOLeELrBVrs8coyuzFnamGQj6PHNgfWw9iw0CAwEAAaOC
AeEwggHdMHUGCCsGAQUFBwEBBGkwZzA+BggrBgEFBQcwAoYyaHR0cDovL2NhY2Vy
dHMuZGFya21hdHRlci5hZS9VQUVHbG9iYWxSb290Q0FHNC5jcnQwJQYIKwYBBQUH
MAGGGWh0dHA6Ly9vY3NwLmRhcmttYXR0ZXIuYWUwHQYDVR0OBBYEFKZ0i9Ql9i/2
H9CVq7Mq4fJeNfSKMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAU1S+a
6egXANlXUtA/BytPZgjr9VQwUgYDVR0gBEswSTA4BgpghhABAQcjAgICMCowKAYI
KwYBBQUHAgEWHGh0dHBzOi8vY2EuZGFya21hdHRlci5hZS9DUFMwDQYLYIYQAQEH
IwICAgcwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NybDEuZGFya21hdHRlci5h
ZS9VQUVHbG9iYWxSb290Q0FHNC5jcmwwNaAzoDGGL2h0dHA6Ly9jcmwyLmRhcmtt
YXR0ZXIuYWUvVUFFR2xvYmFsUm9vdENBRzQuY3JsMA4GA1UdDwEB/wQEAwIBhjAz
BgNVHSUELDAqBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUF
BwMJMA0GCSqGSIb3DQEBDAUAA4ICAQATmf7gAuwVT6ycz6JfXIez6qkqKXgIfZHS
/xyVphS4EQ5hdaQAW8kAJYZYJSliqKidahAcBmzlJlpxmC7fksWmuDYtWqH2cjd9
+TMOxw12gQpSx02c++xLjSnrjI2HPktwIfeDOxmbKgvgfu75FBs2ZZ1K7vt0M/yr
kR+b8hZYmzzEi6EBKUIGLUcBwASr+s/PaFKnI1uczqN29YFtLwguq2fhx+NBhVWs
O3hemXn+eHciDBilZDWgBBfdTxobUgTQtOwVF/ZXM7UWYluCp2c4YseqLaFEe7ax
S5RnYfJZYW9JT9N2PKwF914pMrw7ztmWDRhUyMC2GBwaGk2RqJZYQ5DyObFchIpl
rne0ERYSw6FaFNkys4Lu+qFTdR9Ksoe2Ey6pozTfmdf6B5ZXNWGQdc/fHUZqNZsE
knRcR3Ho+0Qb0QTUbL+nXH4MAUIhftqsFj3N83f8Ptrnwna88k2cguxr181PQimf
uSuro3ME41x9qy6ILBipQTQbULqW3h/799qVED9NcdDgFJggnreyTaGuheZtJMEl
iZugPQaUPgqPcD+PmMNaujcKSRszPIr16booLiSIEnLsjcu0o/uUngZYpWUwTDha
Zuey1/QXY6uNqbaZrMpX6gIurDxbZblCg57sd04xc9r3CHtBovvQaheRxH1VilYW
M2RtLWURpQ==
-----END CERTIFICATE-----
 


DM X1 Assured CA G4
Certificate details:
			     Data:
        Version: 3 (0x2)
        Serial Number: 8186458804101661867 (0x719c24e89ad944ab)
    Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=AE, O=DarkMatter LLC, CN=DarkMatter Root CA G4
        Validity
            Not Before: Sep  5 10:58:32 2018 GMT
            Not After : Sep  5 10:58:32 2028 GMT
        Subject: C=AE, O=DarkMatter LLC, CN=DM X1 Assured CA G4
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:b7:ac:e3:8a:6f:7a:83:ee:15:68:54:f9:47:60:
                    58:99:03:16:76:61:0b:9c:9f:1d:62:3d:c0:a3:ec:
                    c3:2f:9d:26:5c:30:1a:07:31:ae:e2:fc:31:9a:db:
                    bc:b4:d3:3c:77:84:ad:61:32:b1:5d:c9:3e:19:30:
                    6b:15:95:6f:05:e9:f3:6e:ba:a3:7a:90:c7:23:0e:
                    9a:0b:47:8f:97:5f:2e:ad:90:7a:63:89:3e:7d:05:
                    59:1e:3e:14:da:4f:93:38:07:f2:bc:67:e8:f8:2d:
                    f7:b9:de:66:19:5b:f2:83:31:8f:65:d3:f9:7a:de:
                    7f:05:b0:3c:cb:9b:58:1c:ad:a3:07:c8:0d:53:f9:
                    05:5e:38:09:1a:f7:c9:1a:25:50:bb:90:4f:52:da:
                    a9:6f:d2:4a:55:60:1c:01:e6:1f:4a:c2:58:60:8e:
                    13:a8:bf:06:fe:83:38:3e:bf:a5:39:9c:4b:a8:fb:
                    24:06:e1:39:45:fe:4e:3a:cc:12:fc:e5:9e:ec:1d:
                    85:30:f3:43:1f:00:36:d3:2d:ef:23:5f:d2:35:b3:
                    a9:06:15:6c:bd:19:76:3e:f1:75:a0:e4:d9:a4:12:
                    53:17:50:a4:a1:07:e6:b2:88:db:cf:7d:8e:fe:91:
                    cf:1f:cf:92:c8:1f:b0:7b:8c:97:22:74:5e:c9:9e:
                    08:08:50:e4:d8:6a:27:6e:24:16:c9:34:9c:90:e6:
                    33:8a:6f:e0:54:24:1f:39:2e:d7:5a:4f:42:f8:a7:
                    71:f7:b1:df:5b:0f:a4:b9:28:80:74:c6:98:24:e3:
                    a5:95:84:99:9f:4d:c5:18:17:3a:45:de:cb:65:f1:
                    11:67:bb:b2:c9:d9:26:a4:02:42:a3:42:41:7a:0e:
                    ee:3a:08:fe:3a:0f:85:a1:27:6f:76:88:13:7b:04:
                    a5:b9:be:fa:99:2b:c6:90:09:55:63:10:f0:53:3a:
                    7c:71:67:9a:ee:4b:73:ef:40:77:57:1c:b3:c6:a4:
                    93:f4:1a:5b:ca:53:8d:90:1f:c4:61:09:67:19:53:
                    65:85:09:de:d3:a7:0d:4c:bc:9e:1b:b3:f1:da:f3:
                    87:62:1e:e7:5b:33:98:03:9d:b3:01:b5:60:0b:cb:
                    9d:4d:56:71:74:ee:4d:42:d6:f8:ed:ce:31:cb:db:
                    06:1a:4a:08:c4:77:0c:5c:e9:6d:4b:f8:2c:f7:37:
                    ba:45:84:c1:8d:1c:24:d0:4a:d4:bf:39:71:e7:dd:
                    c2:80:78:df:cb:68:1b:6f:a9:4c:2f:7b:dc:6c:3c:
                    1a:f7:7e:30:cc:08:90:b0:55:06:8b:6d:4f:66:ea:
                    b6:d3:c6:6c:de:fb:50:a1:35:d7:14:2c:cb:d7:43:
                    63:69:e5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access: 
                CA Issuers - URI:http://cacerts.darkmatter.ae/DarkMatterRootCAG4.crt
                OCSP - URI:http://ocsp.darkmatter.ae
 
            X509v3 Subject Key Identifier: 
                3A:D4:91:DE:3D:4A:92:7D:A5:10:E3:6C:2D:D6:51:88:F1:EF:03:94
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Authority Key Identifier: 
                keyid:89:01:3B:CC:49:BA:96:2C:6D:C7:84:84:99:13:4F:32:F1:B1:25:F4
 
            X509v3 Certificate Policies: 
                Policy: 2.16.784.2.2.40.2.2.2
                  CPS: https://ca.darkmatter.ae/CPS
                Policy: 2.16.784.2.2.40.2.2.2.7
 
            X509v3 CRL Distribution Points: 
 
                Full Name:
                  URI:http://crl1.darkmatter.ae/DarkMatterRootCAG4.crl
 
                Full Name:
                  URI:http://crl2.darkmatter.ae/DarkMatterRootCAG4.crl
 
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection, 1.3.6.1.4.1.311.10.3.12, OCSP Signing
    Signature Algorithm: sha384WithRSAEncryption
         8b:bb:f1:78:8a:87:10:88:7d:2b:9f:48:2a:31:83:7c:8e:e5:
         ac:95:79:c6:e9:01:68:1e:2d:e2:2d:c5:fd:89:e1:0d:c9:63:
         8e:06:3e:23:6c:11:67:02:aa:3c:2c:79:77:4e:98:d7:a5:c0:
         4b:c8:83:32:d9:00:22:1c:59:ce:0a:b5:68:9e:9b:8c:46:28:
         dc:91:84:1c:20:12:12:53:0c:d8:99:86:00:8b:d2:89:8f:e4:
         e2:ce:7a:04:32:a3:13:18:75:79:93:fc:74:87:74:ff:00:f7:
         8e:e8:96:ca:c2:2d:54:c4:2d:dc:0e:bf:b5:14:9d:b9:ed:95:
         dc:7b:39:3f:3d:6c:ef:b3:59:37:65:0a:29:18:e7:96:36:12:
         dc:de:c1:e6:f2:99:9c:16:e6:b5:e8:31:ac:aa:30:90:a8:4b:
         0e:95:25:da:97:14:55:fa:70:7d:e0:be:a1:af:3a:cd:cc:e3:
         f6:6c:fd:1c:e3:98:c0:59:97:08:a7:0a:89:d1:b6:50:2f:87:
         77:9a:eb:15:85:96:c8:6f:78:93:f8:d7:70:f8:11:25:5a:1e:
         c1:48:06:46:56:af:ce:c8:20:bb:03:99:fe:61:5d:2f:dd:6b:
         aa:86:8c:b1:04:90:6c:fd:f9:2a:1f:b9:1e:99:95:2c:d9:2f:
         b9:34:49:55:e8:df:80:fe:40:89:88:53:c0:60:4b:20:09:ef:
         ed:ea:05:99:95:66:4e:f5:dd:b4:4a:86:2d:ea:d6:b0:0c:e7:
         bd:cf:c3:0f:43:06:f9:f1:6b:93:83:01:0d:c3:77:43:03:36:
         40:89:dd:af:4d:0c:7a:2f:4a:fe:ec:46:40:7f:b7:02:07:6e:
         b2:61:94:88:2e:8c:d7:7d:69:20:1e:32:e9:5c:34:75:e5:f6:
         4e:02:90:49:6e:b6:cf:7a:16:f3:d3:7d:89:6b:70:88:b1:b4:
         a1:ef:e3:63:3a:aa:61:e6:53:d4:52:1a:d3:7e:e3:5c:5f:62:
         7c:21:f4:4d:96:5b:d3:76:bb:da:c0:8b:70:ab:44:5c:f2:96:
         2d:0e:8d:df:7a:98:2f:58:b4:76:cb:df:8d:51:1e:3c:b0:eb:
         2c:87:8a:10:5c:3c:bd:39:7f:fd:f2:70:f6:1a:2a:61:1f:c4:
         a5:f5:c6:1b:a1:e6:4c:6a:58:c2:aa:ad:02:40:52:81:23:b1:
         d8:94:53:d5:41:c1:f8:8b:a1:55:cb:22:49:40:7d:9e:00:40:
         a6:9b:92:05:55:7b:bc:78:38:02:fe:d9:ff:e1:26:bd:c4:86:
         53:06:19:4d:22:01:ea:9a:0a:b8:6f:ef:4d:b7:23:6a:ad:be:
         a4:c5:97:28:2c:97:26:04
-----BEGIN CERTIFICATE-----
MIIG8DCCBNigAwIBAgIIcZwk6JrZRKswDQYJKoZIhvcNAQEMBQAwRjELMAkGA1UE
BhMCQUUxFzAVBgNVBAoMDkRhcmtNYXR0ZXIgTExDMR4wHAYDVQQDDBVEYXJrTWF0
dGVyIFJvb3QgQ0EgRzQwHhcNMTgwOTA1MTA1ODMyWhcNMjgwOTA1MTA1ODMyWjBE
MQswCQYDVQQGEwJBRTEXMBUGA1UECgwORGFya01hdHRlciBMTEMxHDAaBgNVBAMM
E0RNIFgxIEFzc3VyZWQgQ0EgRzQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC3rOOKb3qD7hVoVPlHYFiZAxZ2YQucnx1iPcCj7MMvnSZcMBoHMa7i/DGa
27y00zx3hK1hMrFdyT4ZMGsVlW8F6fNuuqN6kMcjDpoLR4+XXy6tkHpjiT59BVke
PhTaT5M4B/K8Z+j4Lfe53mYZW/KDMY9l0/l63n8FsDzLm1gcraMHyA1T+QVeOAka
98kaJVC7kE9S2qlv0kpVYBwB5h9KwlhgjhOovwb+gzg+v6U5nEuo+yQG4TlF/k46
zBL85Z7sHYUw80MfADbTLe8jX9I1s6kGFWy9GXY+8XWg5NmkElMXUKShB+ayiNvP
fY7+kc8fz5LIH7B7jJcidF7JnggIUOTYaiduJBbJNJyQ5jOKb+BUJB85LtdaT0L4
p3H3sd9bD6S5KIB0xpgk46WVhJmfTcUYFzpF3stl8RFnu7LJ2SakAkKjQkF6Du46
CP46D4WhJ292iBN7BKW5vvqZK8aQCVVjEPBTOnxxZ5ruS3PvQHdXHLPGpJP0GlvK
U42QH8RhCWcZU2WFCd7Tpw1MvJ4bs/Ha84diHudbM5gDnbMBtWALy51NVnF07k1C
1vjtzjHL2wYaSgjEdwxc6W1L+Cz3N7pFhMGNHCTQStS/OXHn3cKAeN/LaBtvqUwv
e9xsPBr3fjDMCJCwVQaLbU9m6rbTxmze+1ChNdcULMvXQ2Np5QIDAQABo4IB4jCC
Ad4wdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY2FjZXJ0cy5k
YXJrbWF0dGVyLmFlL0RhcmtNYXR0ZXJSb290Q0FHNC5jcnQwJQYIKwYBBQUHMAGG
GWh0dHA6Ly9vY3NwLmRhcmttYXR0ZXIuYWUwHQYDVR0OBBYEFDrUkd49SpJ9pRDj
bC3WUYjx7wOUMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUiQE7zEm6
lixtx4SEmRNPMvGxJfQwUAYDVR0gBEkwRzA3BglghhACAigCAgIwKjAoBggrBgEF
BQcCARYcaHR0cHM6Ly9jYS5kYXJrbWF0dGVyLmFlL0NQUzAMBgpghhACAigCAgIH
MHkGA1UdHwRyMHAwNqA0oDKGMGh0dHA6Ly9jcmwxLmRhcmttYXR0ZXIuYWUvRGFy
a01hdHRlclJvb3RDQUc0LmNybDA2oDSgMoYwaHR0cDovL2NybDIuZGFya21hdHRl
ci5hZS9EYXJrTWF0dGVyUm9vdENBRzQuY3JsMA4GA1UdDwEB/wQEAwIBhjAzBgNV
HSUELDAqBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMJ
MA0GCSqGSIb3DQEBDAUAA4ICAQCLu/F4iocQiH0rn0gqMYN8juWslXnG6QFoHi3i
LcX9ieENyWOOBj4jbBFnAqo8LHl3TpjXpcBLyIMy2QAiHFnOCrVonpuMRijckYQc
IBISUwzYmYYAi9KJj+TiznoEMqMTGHV5k/x0h3T/APeO6JbKwi1UxC3cDr+1FJ25
7ZXcezk/PWzvs1k3ZQopGOeWNhLc3sHm8pmcFua16DGsqjCQqEsOlSXalxRV+nB9
4L6hrzrNzOP2bP0c45jAWZcIpwqJ0bZQL4d3musVhZbIb3iT+Ndw+BElWh7BSAZG
Vq/OyCC7A5n+YV0v3WuqhoyxBJBs/fkqH7kemZUs2S+5NElV6N+A/kCJiFPAYEsg
Ce/t6gWZlWZO9d20SoYt6tawDOe9z8MPQwb58WuTgwENw3dDAzZAid2vTQx6L0r+
7EZAf7cCB26yYZSILozXfWkgHjLpXDR15fZOApBJbrbPehbz032Ja3CIsbSh7+Nj
Oqph5lPUUhrTfuNcX2J8IfRNllvTdrvawItwq0Rc8pYtDo3fepgvWLR2y9+NUR48
sOssh4oQXDy9OX/98nD2GiphH8Sl9cYboeZMaljCqq0CQFKBI7HYlFPVQcH4i6FV
yyJJQH2eAECmm5IFVXu8eDgC/tn/4Sa9xIZTBhlNIgHqmgq4b+9NtyNqrb6kxZco
LJcmBA==
-----END CERTIFICATE-----

These certificates have been updated in our CPS and the new version of the CPS is now live on the Repository:
https://ca.darkmatter.ae/CPS/DM_CPS_V1.8.pdf

Comment 76

[Scott Rea]

This is an advisory on issuance related to this submission.

DarkMatter has successfully completed its second annual WebTrust audit for CA, BR, EV - the resulting report will shortly be updated at: https://cert.webtrust.org/ViewSeal?id=2340 

A copy of the WT report and a graphic of DM's current hierarchy are also being added to the thread.

Comment 77

[Scott Rea]

Attachment: WebTrustAuditFiles2018.pdf

2018 WT Audit report & management Assertions for CA, BR, EV

Comment 78

[Scott Rea]

Attachment: DarkMatter CA Hierarchy 2018.pdf

Current DM CA heirarchy

Comment 79

[Scott Rea]

Intermediate CAs now updated in CCADB under CA Owner DarkMatter LLC No.A005612

Comment 80

[Kathleen Wilson]

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=00000251

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 81

[Wayne Thayer]

I've completed a preliminary CP/CPS review and have the following questions / concerns. Would DarkMatter like to address any of these prior to the start of the public discussion?

==Meh==

• Gap from May 18 root signing to June 8 start of first audit period. Can you share the RKGC audit report?
• It’s not clear to me why we should accept both the UAE Global Root CA G4 in this request and the UAE Global Root CA G4 E2 that is requested for inclusion [1] by the UAE goverment. Can you explain the difference?
• CPS section 1.2 states “incorporates the UAENRCA CPS”. I am unable to locate that document. Should this refer to the CP and not the CPS?
• CP section 3.2.5 - there is no section 11.2.3 of the Baseline Requirements
• CP and CPS section 4.12.1 permits key escrow. The BR Self-Assessment states “DM does not provide key generation, escrow, recovery or backup facilities for TLS certificates.” and even if they did, it is not strictly against Mozilla policy.
• CPS section 7.1.2 may be missing a reference to "[UAE Digital Certificate Interoperability Guidelines]"?
• CPS section 7.3.1 typo: “RFC 6960s”
• CPS section 3.4 says that certificates may be suspended, even though section 4.9.13-16 say that suspension isn’t used.

==Bad==

• The CP was last updated on 3-January 2018, in violation of the section 3.3 requirement for annual updates.
• CP section 3.3.1 states that OV SSL certificate subscribers may re-key without re-verification for up to 39 months.
• CP section 6.3.2 lists OV certificate maximum validity period as 42 months
• CP section 3.4 appears to allow anyone in possession of a certificate’s PUBLIC key to revoke it: “Requests to revoke a certificate may be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.” Perhaps this means that DarkMatter uses the public key to authenticate revocation requests, but it’s not clear.
• It’s not clear to me that CP and CPS section 4.9.1 cover all the BR-required revocation reasons, such as “The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.”
• The domain validations described in CPS section 3.2.2 are insufficiently specified to meet the requirements of Mozilla policy section 2.2. Specifically, the statement “or other DNS record information” and #4 (“A similar procedure”) do not provide enough information for a relying party to understand how domain validation is performed.
• Section 1.3.6.2 of the CPS uses the undefined term “Accreditation Authority” to describe entities that accredit DarkMatter. It seems reasonable to include Mozilla in this category, and the licensing terms described in this section violate Mozilla policy section 3.3.
• CPS section 1.3.2 is unclear on the topic of external RAs. The last paragraph of CPS section 3.2.2 implies that they are permitted and appears to allow DarkMatter to perform domain validations for certificates verified by delegated RAs using “…or by using other reliable means, such as performing a DNS lookup to determine whether there is a matching DNS record that points to the Delegated Third Party’s IP address or domain namespace.” This is underspecified and appears to violate the BRs.
• I do not believe that CPS section 9.8’s liability limitations comply with either BR section 9.8 or EVGL section 18.
• CPS section 3.2.2 does not clearly specify how email addresses are validated as required by Mozilla policy section 2.2(2).
• CPS section 3.2.3 describes methods used to verify an Applicant’s control of an email address, but the methods described do not appear to actually validate control of an email address.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1474556

Comment 82

[Scott Rea]

(in reply to Wayne's comment #81)

==Meh==

[WT] Gap from May 18 root signing to June 8 start of first audit period. Can you share the RKGC audit report?

[SR] KPMG (our WT Auditors) were present for the Key Ceremonies which were performed during WT PiT pre-audit activities, however we did not request a separate RKGC audit report for just that activity alone. If Mozilla is satisfied to receive confirmation from the Principal Auditors involved in reviewing and witnessing that ceremony, they are happy to do that and I will provide the relevant contact details.

[WT]It’s not clear to me why we should accept both the UAE Global Root CA G4 in this request and the UAE Global Root CA G4 E2 that is requested for inclusion [1] by the UAE government. Can you explain the difference?

[SR] The UAE is adopting an EU-like Trust List approach for national trust. As part of the UAE deployment of a national authentication and digital signing platform, which was integrated by DarkMatter but deployed at SmartDubai Government, there were two Trust Anchors approved for issuance under the program - the National Root operated by DM which is valid for any entity participating (certificates issued come through the Federal Authority for Identity & Citizenship [ICA] subCAs), and another Root operated by Dubai for any participating Dubai Emirate entity. The desire was to give the impression that either Root should be treated as equally trusted within the system, hence when Dubai was preparing their Root Key Ceremony, they were requested to choose a name closely matching the original UAE national Root which had already been created at DM. You can see that the name differs just by the E2 designation at the end of commonName for the Dubai Root to indicate the Emirate scope for that anchor. So in short, the UAE Government recognizes both and is seeking global recognition for the same to facilitate visitors and international businesses to transact on the UAE Pass system. Any entity that has an association with specifically Emirate of Dubai, will be eligible to be provisioned by the E2 chain. But globally speaking, any entity within the UAE or internationally can be provisioned through the ICA subs that chain to the UAE Root submitted by DM.

[WT]CPS section 1.2 states “incorporates the UAENRCA CPS”. I am unable to locate that document. Should this refer to the CP and not the CPS?

[SR] This may be a language interpretation issue - the intention was to convey that there is no separate CPS for the UAENRCA but that this CPS is one and the same with the DM CPS.

[WT]CP section 3.2.5 - there is no section 11.2.3 of the Baseline Requirements

[SR] This is an incorrect reference in our CP and we will fix that - it should have referred to section 3.2.2.1 of the BRs. The CPS is clear about the processes we actually follow.

[WT]CP and CPS section 4.12.1 permits key escrow. The BR Self-Assessment states “DM does not provide key generation, escrow, recovery or backup facilities for TLS certificates.” and even if they did, it is not strictly against Mozilla policy.

[SR] DM and UAE Roots permit non-TLS certificates e.g. SMIME client encryption certificates chained to them to be escrowed as an option.

[WT]CPS section 7.1.2 may be missing a reference to "[UAE Digital Certificate Interoperability Guidelines]"?

[SR] The UAE Digital Certificate Interoperability Guidelines are a Work-In-Progress aimed more for cross-signed trust communities. The DM and UAE Roots submitted for inclusion are not cross-signed.

[WT]CPS section 7.3.1 typo: “RFC 6960s”

[SR] Typo: we will fix that - it should have the trailing "s" removed.

[WT]CPS section 3.4 says that certificates may be suspended, even though section 4.9.13-16 say that suspension isn’t used.

[SR] This may be a language interpretation issue - the intention was to convey that suspension for some classes of certs e.g. private trust certificates is permitted in future, but today, is not used by any DM operated CA.

==Bad==

[WT]The CP was last updated on 3-January 2018, in violation of the section 3.3 requirement for annual updates.

[SR] 3.3 of Mozilla Root Policy says : "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." Our understanding is that annual review of both the CP and CPS is the minimum requirement, and is the practice followed by DM as indicated in 9.12.1 of CP and CPS. But either document is only required to be "updated as necessary", so if there are no updates required in a given 12 month period, a review will be performed, but it may not produce a new document.

[WT]CP section 3.3.1 states that OV SSL certificate subscribers may re-key without re-verification for up to 39 months.

[SR] In the CP, OV TLS could refer to private trust organizationally validated certificates, or the standard OV public trust certificates. We have not restricted the private trust OV certs we issue under other Roots covered by this CP (not submitted to Mozilla) in the same way that BRs require for public trust OV and hence the CP reads this way. However, our SOPs related to public trust issuance of OV TLS were updated 6 Aug 2017 to honor freshness of Identity data and the 825 day limits. Final paragraph of CP 1.0 says "The UAE National PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (“Baseline Requirements”) and the Guidelines for Extended Validation Certificates (“EV Guidelines”) both of which are published at https://www.cabforum.org. With regard to SSL/TLS Server Certificates or Code Signing Certificates, if any inconsistency exists between this CP and the Baseline Requirements or the EV Guidelines, then the EV Guidelines take precedence for EV Certificates and the Baseline Requirements take precedence for publicly trusted SSL certificates."

[WT]CP section 6.3.2 lists OV certificate maximum validity period as 42 months

[SR] Same response as for CP 3.3.1 directly above

[WT]CP section 3.4 appears to allow anyone in possession of a certificate’s PUBLIC key to revoke it: “Requests to revoke a certificate may be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.” Perhaps this means that DarkMatter uses the public key to authenticate revocation requests, but it’s not clear.

[SR] This may be a language interpretation issue - the intention was to convey that CA or RA may authenticate a signed revocation request with the corresponding public key.

[WT]It’s not clear to me that CP and CPS section 4.9.1 cover all the BR-required revocation reasons, such as “The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.”

[SR] 4th bullet point says: "The certificate was not issued in accordance with the CP, CPS, or applicable industry standards." All public trust certificates are issued in accordance with BRs and/or EV. In our SOPs we mention the relevant sections used to validate Domains and we note the method used for every validation in our checklists as validated by our WT Audit.

[WT]The domain validations described in CPS section 3.2.2 are insufficiently specified to meet the requirements of Mozilla policy section 2.2. Specifically, the statement “or other DNS record information” and #4 (“A similar procedure”) do not provide enough information for a relying party to understand how domain validation is performed.

[SR] Per BR requirements our SOPs require us to specify which method was used for each validation and this is recorded in the validation checklist data. To date the following methods have been used by DM : 3.2.2.4.7 (this is our almost exclusively the method used), 3.2.2.4.9 (a couple of domains); however these additional methods are also permitted: 3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.4, 3.2.2.8. DM does NOT allow use of 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address). For clarity, DM can update next version of CPS with the definitive list. NOTE: Long time ago we have also used 3.2.2.4.5 Domain Authorization Document. But those validations are no longer valid. They have either been re-validated or no more in use, and that method is obviously no longer used.

[WT]Section 1.3.6.2 of the CPS uses the undefined term “Accreditation Authority” to describe entities that accredit DarkMatter. It seems reasonable to include Mozilla in this category, and the licensing terms described in this section violate Mozilla policy section 3.3.

[SR] 1.3.6.2 is titled "IGTF" which is the Interoperable Global Trust Federation that governs accreditation of CAs issuing credentials trusted within the supercomputing and research and education industries where DM is currently accredited. Language used in this section are designed for distribution in that community. DM's application for inclusion in Mozilla is associated instead with section 1.3.6.1 CA and Browser Forum where no specific licensing is mentioned which we understand is entirely acceptable under Mozilla policy section 3.3.

[WT]CPS section 1.3.2 is unclear on the topic of external RAs. The last paragraph of CPS section 3.2.2 implies that they are permitted and appears to allow DarkMatter to perform domain validations for certificates verified by delegated RAs using “…or by using other reliable means, such as performing a DNS lookup to determine whether there is a matching DNS record that points to the Delegated Third Party’s IP address or domain namespace.” This is underspecified and appears to violate the BRs.

[SR] DM does not currently have any external RAs and has only used our own RA services to issue certificates. External RAs are permitted in future, but only after they are audited as meeting the necessary controls by our Web Trust Auditors.

[WT]I do not believe that CPS section 9.8’s liability limitations comply with either BR section 9.8 or EVGL section 18.

[SR] We believe our statements are in compliance with BRs which is also the requirements in the EVGs except with an amount qualification. I have submitted this to our Legal and Risk teams to evaluate and advise - thank you for bringing this to our attention

[WT]CPS section 3.2.2 does not clearly specify how email addresses are validated as required by Mozilla policy section 2.2(2).

[SR] We agree, none of the methods described are specific for the email validation process, but rather refer to Identity validation which can include verification of control of a claimed email address. We do however define this in our SOPs where we specify a suitably random value challenge is sent to the email address which must be received in the responding confirmation. We can provide more transparency in the next version of our CPS by describing this process there, rather than only detailing it in our SOPs.

[WT]CPS section 3.2.3 describes methods used to verify an Applicant’s control of an email address, but the methods described do not appear to actually validate control of an email address.

[SR] Same response for 3.2.2 directly above.

Comment 83

[Ryan Sleevi]

Note, Bugzilla supports markdown, if it makes it easier. Prefixing a line with > is sufficient to indicate it's a reply (e.g. as done by this)

But globally speaking, any entity within the UAE or internationally can be provisioned through the ICA subs that chain to the UAE Root submitted by DM.

To confirm: Those ICA subs are also operated by DM?

I ask because of this policy regarding Super-CAs: https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

[WT]CP and CPS section 4.12.1 permits key escrow. The BR Self-Assessment states “DM does not provide key generation, escrow, recovery or backup facilities for TLS certificates.” and even if they did, it is not strictly against Mozilla policy.

[SR] DM and UAE Roots permit non-TLS certificates e.g. SMIME client encryption certificates chained to them to be escrowed as an option.

One way to resolve this concern is to make it explicit within the CP/CPS, both in the context of subscriber certificates and the issuing CA certificates that are not technically constrained.

[WT]CPS section 3.4 says that certificates may be suspended, even though section 4.9.13-16 say that suspension isn’t used.

[SR] This may be a language interpretation issue - the intention was to convey that suspension for some classes of certs e.g. private trust certificates is permitted in future, but today, is not used by any DM operated CA.

I'm not sure how to interpret this reply. Is the expectation that privately trusted roots would use the same CPS as publicly trusted roots?

One way to resolve this is to ensure your CPSes are separate for the functional hierarchies and trust communities they will participate in; i.e. ensure that your publicly trusted CPS does not state any actions that may be taken by privately trusted (see also, above)

==Bad==

[WT]The CP was last updated on 3-January 2018, in violation of the section 3.3 requirement for annual updates.

[SR] 3.3 of Mozilla Root Policy says : "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." Our understanding is that annual review of both the CP and CPS is the minimum requirement, and is the practice followed by DM as indicated in 9.12.1 of CP and CPS. But either document is only required to be "updated as necessary", so if there are no updates required in a given 12 month period, a review will be performed, but it may not produce a new document.

https://wiki.mozilla.org/CA/BR_Self-Assessment captures this, but more importantly https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#33-cps-and-cpses (Section 3.3 of Mozilla policy; alt link ) clearly states, in the sentence immediately following what you quoted,

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

[WT]CP section 3.3.1 states that OV SSL certificate subscribers may re-key without re-verification for up to 39 months.

[SR] In the CP, OV TLS could refer to private trust organizationally validated certificates, or the standard OV public trust certificates. We have not restricted the private trust OV certs we issue under other Roots covered by this CP (not submitted to Mozilla) in the same way that BRs require for public trust OV and hence the CP reads this way. However, our SOPs related to public trust issuance of OV TLS were updated 6 Aug 2017 to honor freshness of Identity data and the 825 day limits. Final paragraph of CP 1.0 says "The UAE National PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (“Baseline Requirements”) and the Guidelines for Extended Validation Certificates (“EV Guidelines”) both of which are published at https://www.cabforum.org. With regard to SSL/TLS Server Certificates or Code Signing Certificates, if any inconsistency exists between this CP and the Baseline Requirements or the EV Guidelines, then the EV Guidelines take precedence for EV Certificates and the Baseline Requirements take precedence for publicly trusted SSL certificates."

As noted elsewhere, given that the inclusion of private trust operations prevent the community and relying parties from being able to distinguish the separation of responsibility and activities - quoted text notwithstanding - splitting them out is strongly advised.

The reasons for this were discussed during the Mozilla policy discussion about changelogs on CP/CPSes, and are similar to why the Mozilla peers perform detailed review of CP/CPSes, rather than relying on broad statements about "complying with the BRs".

[WT]CP section 3.4 appears to allow anyone in possession of a certificate’s PUBLIC key to revoke it: “Requests to revoke a certificate may be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.” Perhaps this means that DarkMatter uses the public key to authenticate revocation requests, but it’s not clear.

[SR] This may be a language interpretation issue - the intention was to convey that CA or RA may authenticate a signed revocation request with the corresponding public key.

Are there plans to update and/or resolve this?

[WT]It’s not clear to me that CP and CPS section 4.9.1 cover all the BR-required revocation reasons, such as “The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.”

[SR] 4th bullet point says: "The certificate was not issued in accordance with the CP, CPS, or applicable industry standards." All public trust certificates are issued in accordance with BRs and/or EV. In our SOPs we mention the relevant sections used to validate Domains and we note the method used for every validation in our checklists as validated by our WT Audit.

Are there plans to update the language to resolve this?

[WT]The domain validations described in CPS section 3.2.2 are insufficiently specified to meet the requirements of Mozilla policy section 2.2. Specifically, the statement “or other DNS record information” and #4 (“A similar procedure”) do not provide enough information for a relying party to understand how domain validation is performed.

[SR] Per BR requirements our SOPs require us to specify which method was used for each validation and this is recorded in the validation checklist data. To date the following methods have been used by DM : 3.2.2.4.7 (this is our almost exclusively the method used), 3.2.2.4.9 (a couple of domains); however these additional methods are also permitted: 3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.4, 3.2.2.8. DM does NOT allow use of 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address). For clarity, DM can update next version of CPS with the definitive list. NOTE: Long time ago we have also used 3.2.2.4.5 Domain Authorization Document. But those validations are no longer valid. They have either been re-validated or no more in use, and that method is obviously no longer used.

Can you provide a timeline for updating to resolve this?

[WT]CPS section 1.3.2 is unclear on the topic of external RAs. The last paragraph of CPS section 3.2.2 implies that they are permitted and appears to allow DarkMatter to perform domain validations for certificates verified by delegated RAs using “…or by using other reliable means, such as performing a DNS lookup to determine whether there is a matching DNS record that points to the Delegated Third Party’s IP address or domain namespace.” This is underspecified and appears to violate the BRs.

[SR] DM does not currently have any external RAs and has only used our own RA services to issue certificates. External RAs are permitted in future, but only after they are audited as meeting the necessary controls by our Web Trust Auditors.

What audit criteria has DM determined to be sufficient evidence of meeting the necessary controls, and where is this documented? Given that CAs have been distrusted over issues regarding their supervision of RAs, will your CP/CPS also detail in sufficient detail the process for reviewing and approving RAs and determining that they comply with the applicable policies?

[WT]CPS section 3.2.2 does not clearly specify how email addresses are validated as required by Mozilla policy section 2.2(2).

[SR] We agree, none of the methods described are specific for the email validation process, but rather refer to Identity validation which can include verification of control of a claimed email address. We do however define this in our SOPs where we specify a suitably random value challenge is sent to the email address which must be received in the responding confirmation. We can provide more transparency in the next version of our CPS by describing this process there, rather than only detailing it in our SOPs.

When will an update be provided? Similar to the note in the BR self assessment

"5) If you intend to submit your self-assessment with statements such as "will add/update in our next version of CP/CPS", indicate when you plan to provide the updated documents."

Comment 84

[Scott Rea]

(In reply to Ryan Sleevi from comment #83)

Note, Bugzilla supports markdown, if it makes it easier. Prefixing a line with > is sufficient to indicate it's a reply (e.g. as done by this)

But globally speaking, any entity within the UAE or internationally can be provisioned through the ICA subs that chain to the UAE Root submitted by DM.

To confirm: Those ICA subs are also operated by DM?

[SR] Yes, this is correct Ryan, those subs are operated by DM

I ask because of this policy regarding Super-CAs: https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

[WT]CP and CPS section 4.12.1 permits key escrow. The BR Self-Assessment states “DM does not provide key generation, escrow, recovery or backup facilities for TLS certificates.” and even if they did, it is not strictly against Mozilla policy.

[SR] DM and UAE Roots permit non-TLS certificates e.g. SMIME client encryption certificates chained to them to be escrowed as an option.

One way to resolve this concern is to make it explicit within the CP/CPS, both in the context of subscriber certificates and the issuing CA certificates that are not technically constrained.

[SR] This is a good suggestion Ryan, we will Update CPS with appropriate language

[WT]CPS section 3.4 says that certificates may be suspended, even though section 4.9.13-16 say that suspension isn’t used.

[SR] This may be a language interpretation issue - the intention was to convey that suspension for some classes of certs e.g. private trust certificates is permitted in future, but today, is not used by any DM operated CA.

I'm not sure how to interpret this reply. Is the expectation that privately trusted roots would use the same CPS as publicly trusted roots?

One way to resolve this is to ensure your CPSes are separate for the functional hierarchies and trust communities they will participate in; i.e. ensure that your publicly trusted CPS does not state any actions that may be taken by privately trusted (see also, above)

[SR] This is also a good recommendation, but of course to split out the CPS into Private Trust version and Public Trust version will take us some time. Initially we will update the existing CPS with the changes we have outlined, and we will seek to do that and publish it within the next month. Subsequently, splitting the CPS into separate versions will be a longer exercise.

To answer you first question related to the above, yes, the same CPS is used. DM has issued far more private trust certificates into enterprise scenarios than the public trust, and that is where we focused first.

==Bad==

[WT]The CP was last updated on 3-January 2018, in violation of the section 3.3 requirement for annual updates.

[SR] 3.3 of Mozilla Root Policy says : "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." Our understanding is that annual review of both the CP and CPS is the minimum requirement, and is the practice followed by DM as indicated in 9.12.1 of CP and CPS. But either document is only required to be "updated as necessary", so if there are no updates required in a given 12 month period, a review will be performed, but it may not produce a new document.

https://wiki.mozilla.org/CA/BR_Self-Assessment captures this, but more importantly https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#33-cps-and-cpses (Section 3.3 of Mozilla policy; alt link ) clearly states, in the sentence immediately following what you quoted,

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

[WT]CP section 3.3.1 states that OV SSL certificate subscribers may re-key without re-verification for up to 39 months.

[SR] In the CP, OV TLS could refer to private trust organizationally validated certificates, or the standard OV public trust certificates. We have not restricted the private trust OV certs we issue under other Roots covered by this CP (not submitted to Mozilla) in the same way that BRs require for public trust OV and hence the CP reads this way. However, our SOPs related to public trust issuance of OV TLS were updated 6 Aug 2017 to honor freshness of Identity data and the 825 day limits. Final paragraph of CP 1.0 says "The UAE National PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (“Baseline Requirements”) and the Guidelines for Extended Validation Certificates (“EV Guidelines”) both of which are published at https://www.cabforum.org. With regard to SSL/TLS Server Certificates or Code Signing Certificates, if any inconsistency exists between this CP and the Baseline Requirements or the EV Guidelines, then the EV Guidelines take precedence for EV Certificates and the Baseline Requirements take precedence for publicly trusted SSL certificates."

As noted elsewhere, given that the inclusion of private trust operations prevent the community and relying parties from being able to distinguish the separation of responsibility and activities - quoted text notwithstanding - splitting them out is strongly advised.

The reasons for this were discussed during the Mozilla policy discussion about changelogs on CP/CPSes, and are similar to why the Mozilla peers perform detailed review of CP/CPSes, rather than relying on broad statements about "complying with the BRs".

[SR] This is a sound recommendation and we will begin that work after we first publish an update to the existing CPS to clarify the requested items

[WT]CP section 3.4 appears to allow anyone in possession of a certificate’s PUBLIC key to revoke it: “Requests to revoke a certificate may be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.” Perhaps this means that DarkMatter uses the public key to authenticate revocation requests, but it’s not clear.

[SR] This may be a language interpretation issue - the intention was to convey that CA or RA may authenticate a signed revocation request with the corresponding public key.

Are there plans to update and/or resolve this?

[SR] We will seek to address this in an updated CPS which we will publish within the next month

[WT]It’s not clear to me that CP and CPS section 4.9.1 cover all the BR-required revocation reasons, such as “The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.”

[SR] 4th bullet point says: "The certificate was not issued in accordance with the CP, CPS, or applicable industry standards." All public trust certificates are issued in accordance with BRs and/or EV. In our SOPs we mention the relevant sections used to validate Domains and we note the method used for every validation in our checklists as validated by our WT Audit.

Are there plans to update the language to resolve this?

[SR] We will seek to address this in an updated CPS which we will publish within the next month

[WT]The domain validations described in CPS section 3.2.2 are insufficiently specified to meet the requirements of Mozilla policy section 2.2. Specifically, the statement “or other DNS record information” and #4 (“A similar procedure”) do not provide enough information for a relying party to understand how domain validation is performed.

[SR] Per BR requirements our SOPs require us to specify which method was used for each validation and this is recorded in the validation checklist data. To date the following methods have been used by DM : 3.2.2.4.7 (this is our almost exclusively the method used), 3.2.2.4.9 (a couple of domains); however these additional methods are also permitted: 3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.4, 3.2.2.8. DM does NOT allow use of 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address). For clarity, DM can update next version of CPS with the definitive list. NOTE: Long time ago we have also used 3.2.2.4.5 Domain Authorization Document. But those validations are no longer valid. They have either been re-validated or no more in use, and that method is obviously no longer used.

Can you provide a timeline for updating to resolve this?

[SR] We will seek to address this in an updated CPS which we will publish within the next month

[WT]CPS section 1.3.2 is unclear on the topic of external RAs. The last paragraph of CPS section 3.2.2 implies that they are permitted and appears to allow DarkMatter to perform domain validations for certificates verified by delegated RAs using “…or by using other reliable means, such as performing a DNS lookup to determine whether there is a matching DNS record that points to the Delegated Third Party’s IP address or domain namespace.” This is underspecified and appears to violate the BRs.

[SR] DM does not currently have any external RAs and has only used our own RA services to issue certificates. External RAs are permitted in future, but only after they are audited as meeting the necessary controls by our Web Trust Auditors.

What audit criteria has DM determined to be sufficient evidence of meeting the necessary controls, and where is this documented? Given that CAs have been distrusted over issues regarding their supervision of RAs, will your CP/CPS also detail in sufficient detail the process for reviewing and approving RAs and determining that they comply with the applicable policies?

[SR] Part of the reason for wanting to participate in CABF WGs is to seek guidance on this very topic. Current plans are that future external RAs will need to produce a compliant RPS, and then demonstrate to either our WT Auditors, or another of their choosing, that the RPS maps to our CPS, and they have sufficient controls to implement what their RPS defines.

[WT]CPS section 3.2.2 does not clearly specify how email addresses are validated as required by Mozilla policy section 2.2(2).

[SR] We agree, none of the methods described are specific for the email validation process, but rather refer to Identity validation which can include verification of control of a claimed email address. We do however define this in our SOPs where we specify a suitably random value challenge is sent to the email address which must be received in the responding confirmation. We can provide more transparency in the next version of our CPS by describing this process there, rather than only detailing it in our SOPs.

When will an update be provided? Similar to the note in the BR self assessment

[SR] We will seek to address this in an updated CPS which we will publish within the next month

"5) If you intend to submit your self-assessment with statements such as "will add/update in our next version of CP/CPS", indicate when you plan to provide the updated documents."

Comment 85

[Claudio Guarnieri]

I believe it is important to bring to the attention of Mozilla's reviewers the recent disclosures from Reuters journalists regarding very serious and troubling allegations of the involvement of the company in question into illegitimate hacking operations.

https://www.reuters.com/investigates/special-report/usa-spying-raven/

To quote:

Stroud had been recruited by a Maryland cybersecurity contractor to help the Emiratis launch hacking operations, and for three years, she thrived in the job. But in 2016, the Emiratis moved Project Raven to a UAE cybersecurity firm named DarkMatter. Before long, Stroud and other Americans involved in the effort say they saw the mission cross a red line: targeting fellow Americans for surveillance.

The story of Project Raven reveals how former U.S. government hackers have employed state-of-the-art cyber-espionage tools on behalf of a foreign intelligence service that spies on human rights activists, journalists and political rivals."

Under DarkMatter, Project Raven continued to operate in Abu Dhabi from the Villa, but pressure escalated for the program to become more aggressive.

Considering these revelations as well as previous allegations (such as https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/), I believe that, similarly to bug 1232689, it is important for the reviewers to evaluate the information available and consider potential risks of abuse.

Comment 86

[Micah Lee]

I also believe that including DarkMatter's root CA carries a large risk of abuse, and would reduce the security of Firefox. I would be surprised if DarkMatter didn't use their CA to sign malicious certificates to aid their illegitimate hacking operations, including against local UAE dissidents.

Comment 87

[Jonathan Rudenberg]

Claudio and Micah: This bug is being used by Mozilla representatives to collect and verify information about the CA's practices and discuss the CP/CPS and audits (see step #3 in https://wiki.mozilla.org/CA/Application_Process#Process_Overview). There will be ample time for discussing all other issues related to the CA on the mozilla.dev.security.policy mailing list during the public discussion phase (step #4), which hasn't started yet. Please hold further comments until the public discussion opens so that the focus can stay on the current step of the process.

Comment 88

[rugk]

BTW EFF is criticizing this inclusion request:

The concern in this case is that DarkMatter has made its business spying on internet communications, hacking dissidents’ iPhones, and other cyber-mercenary work. DarkMatter’s business objectives directly depend on intercepting end-user traffic on behalf of snooping governments. Giving DarkMatter a trusted root certificate would be like letting the proverbial fox guard the henhouse.

(the claims there are backed by links/more resources)

https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else

Comment 89

[Scott Rea]

DarkMatter CEO has provided an official response to Mozilla on the recent media article about the UAE that referenced security and intelligence matters. Wayne has invited DM to share this on the mozilla.dev.security.policy mailing list, which we have done, but due to the size (scanned PDF) it may not make it past moderation. So I am also adding a copy of that letter here in case it is easier for folks to access.

Comment 90

[Scott Rea]

Attachment: DarkMatter-Letter-MozillaRootStore-2019-02-25.pdf

DM CEO letter to Mozilla

Comment 91

[Scott Rea]

Attachment: DarkMatter Certification Practice Statement - v1.9.pdf

CPS updates have been completed, copy is added to submission. new CPS will be live at https://ca.darkmatter.ae/CPS/index.html in next 48 hours.

Comment 92

[Nadim Kobeissi]

DarkMatter has a clear and documented history of defensive work in cybersecurity.

However, granting DarkMatter broader certificate authority status would allow DarkMatter, in theory, to critically assist with the mass interception of Internet traffic on behalf of, for example, Internet service providers. This latter type of entity is one that DarkMatter is known to have close relationship with, for example in the United Arab Emirates.

DarkMatter claims to have no interest in exhibiting the behavior described above. However:

A Reuters investigative report published last month claims that DarkMatter is a main component of a "clandestine team that included more than a dozen former U.S. intelligence operatives recruited to help the United Arab Emirates engage in surveillance of other governments, militants and human rights activists critical of the monarchy."

According to this same Reuters article, this clandestine team "employed state-of-the-art cyber-espionage tools on behalf of a foreign intelligence service that spies on human rights activists, journalists and political rivals."

A second Reuters investigative report claims that DarkMatter helped the United Arab Emirates to "[hack] into the iPhones of activists, diplomats and rival foreign leaders with the help of a sophisticated spying tool called Karma [...] The cyber tool allowed the small Gulf country to monitor hundreds of targets beginning in 2016, from the Emir of Qatar and a senior Turkish official to a Nobel Peace laureate human-rights activist in Yemen, according to five former operatives and program documents reviewed by Reuters. The sources interviewed by Reuters were not Emirati citizens."

The behavior attributed to DarkMatter in the two Reuters investigative reports quoted above falls strictly in line with the sort of thing that can be accomplished via the abuse of certificate authority powers, should they be more broadly attributed to DarkMatter by Mozilla.

Furthermore, the problem of authenticating encrypted web traffic via certificate authorities has long been recognized as onerous, and has previously been exploited by state authorities on more than one occasion.

The facts are clear: until DarkMatter specifically, concretely and convincingly addresses these and other such claims, and until their communicated position is followed by a prolonged period of time where no further dubious reports appear, granting them a broader certificate authority role in Mozilla software should be posited only as unthinkable.

Comment 93

[Ryan Sleevi]

Please see Comment #87. There is an appropriate venue to continue that discussion, and it's not on this bug, but in mozilla.dev.security.policy.

I've gone ahead and removed the comment, to ensure this bug does not become cluttered. Please feel free to repost on the discussion at https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ

Comment 94

[Kathleen Wilson]

The CA has generated new versions of their root certificates, and is updating this root inclusion case in the CCADB.

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

Comment 95

[Wayne Thayer]

I recommend that this inclusion request be denied based on the discussion at https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/TseYqDzaDAAJ , which was concluded as follows:

I would like to thank everyone for their constructive input on this
difficult issue. I would also like to thank DarkMatter representatives for
participating in the open, public discussion. I feel that the discussion
has now, after more than 4 months, run its course.

The question that I originally presented [1] to this community was about
distrusting DarkMatter’s current intermediate CA certificates (6 total)
based on credible evidence of spying activities by the company. While a
decision to revoke trust in these intermediates would likely result in a
denial of DarkMatter’s root inclusion request [2], the public discussion
for that request has not yet begun. A decision not to revoke these
intermediates does not necessarily mean that the inclusion request will be
approved.

Some of this discussion has revolved around compliance issues, the most
prominent one being the serial number entropy violations discovered by
Corey Bonnell. While these issues would certainly be a consideration when
evaluating a root inclusion request, they are not sufficient to have
triggered an investigation aimed at revoking trust in the DarkMatter
intermediates or QuoVadis roots. Therefore, they are not relevant to the
question at hand.

Much of the discussion has been about the desire for inclusion and distrust
decisions to be made based on objective criteria that must be satisfied.
However, if we rigidly applied our existing criteria, we would deny most
inclusion requests. As I stated earlier in this thread, every distrust
decision has a substantial element of subjectivity. One can argue that
we’re discussing a different kind of subjectivity here, but it still
amounts to a decision being made based on a collective assessment of all
the information at hand rather than a checklist.

Some, including DarkMatter representatives [3], have declared the need to
examine and consider the benefits of having DarkMatter as a trusted CA.
However, last year we changed our policy to replace the weighing of
benefits and risks with “based on the risks of such inclusion to typical
users of our products.” [4]

Perhaps the most controversial element in this discussion has been the
consideration of “credible evidence”. The first component is the inherent
uncertainty over what is “credible”, especially in this day and age. While
it has been pointed out that respected news organizations are not beyond
reproach [5], having four independent articles [6][7][8][9] from reputable
sources published years apart does provide some indication that the
allegations are credible. These articles are also extensively sourced.

If we assume for a second that these allegations are true, then there is
still a sincere debate over what role they should play in our decision to
trust DarkMatter as a CA. The argument for considering these allegations is
akin to the saying “where there’s smoke there’s fire”, while the argument
against can be described as “innocent until proven guilty”.

DarkMatter has argued [3] that their CA business has always been operated
independently and as a separate legal entity from their security business.
Furthermore, DarkMatter states that once a rebranding effort is completed,
“the DarkMatter CA subsidiary will be completely and wholly separate from
the DarkMatter Group of companies in their entirety.” However, in the same
message, DarkMatter states that “Al Bannai is the sole beneficial
shareholder of the DarkMatter Group.” and leaves us to assume that Mr. Al
Bannai would remain the sole owner of the CA business. More recently,
DarkMatter announced that they are transitioning all aspects of the
business to DigitalTrust and confirmed that Al Bannai controls this entity.
This ownership structure does not assure me that these companies have the
ability to operate independently, regardless of their names and legal
structure.

Mozilla’s principles should be at the heart of this decision. “The Mozilla
Manifesto [10] states:

Individuals’ security and privacy on the internet are fundamental and must
not be treated as optional.”

And our Root Store policy states: “We will determine which CA certificates
are included in Mozilla's root program based on the risks of such inclusion
to typical users of our products.”

In other words, our foremost responsibility is to protect individuals who
rely on Mozilla products. I believe this framing strongly supports a
decision to revoke trust in DarkMatter’s intermediate certificates. While
there are solid arguments on both sides of this decision, it is reasonable
to conclude that continuing to place trust in DarkMatter is a significant
risk to our users. I will be opening a bug requesting the distrust of
DarkMatter’s subordinate CAs pending Kathleen’s concurrence. I will also
recommend denial of the pending inclusion request, and any new requests
from DigitalTrust.

In the past, we’ve seen CAs attempt to make an end run around adverse trust
decisions - through an acquisition, a shell company, etc. We will treat any
such attempt as a violation of this decision and act accordingly. Mozilla
does welcome DigitalTrust as a “managed” subordinate CA under the oversight
of an existing trusted CA that retains control of domain validation and the
private keys.

This discussion has highlighted an opportunity to improve our review of new
externally-operated subordinate CAs [11]. This issue [12] is part of the
current policy update discussions.

Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/mJ0EV2eoCgAJ
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/58F6FgeGOz8/Zzb-r76wBQAJ
[5]
https://www.washingtonpost.com/blogs/erik-wemple/wp/2018/11/27/bloomberg-is-still-reporting-on-challenged-story-regarding-china-hardware-hack/
[6]
https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
[7] https://www.reuters.com/investigates/special-report/usa-spying-raven/
[8]
https://www.nytimes.com/2019/03/21/us/politics/government-hackers-nso-darkmatter.html
[9] https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/
[10] https://www.mozilla.org/en-US/about/manifesto/
[11]
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits
[12] https://github.com/mozilla/pkipolicy/issues/169

Comment 97

[Kathleen Wilson]

I concur with Wayne's recommendation to deny this root inclusion request.

Reference:
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/JIBk4fECDwAJ

Comment 98

[Scott Rea]

Attachment: DigitalTrust - Mozilla Appeal - 2019-07-17.pdf

DigitalTrust's appeal to Mozilla's decision