TrustCor root inclusion request

[Aaron Wu]

This request from TrustCor is to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits.

TrustCor, located in Canada, is a commercial organization that develops privacy protection services and issues certificates to its customers in support of such services.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1231853

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8860163

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8868831

* Root Certificate Download URL:
http://www.trustcor.ca/certs/root/ca1.pem
http://www.trustcor.ca/certs/root/ca2.pem
http://www.trustcor.ca/certs/root/eca1.pem

* All documents are in English.
Document Repository: https://www.trustcorsystems.com/resources/
CP: http://www.trustcor.ca/resources/cp.pdf
CPS: http://www.trustcor.ca/resources/cps.pdf

* CA Hierarchy:
The “TrustCor RootCert CA-1” and “TrustCor RootCert CA-2” root certificates issue internally-operated intermediate certificates that sign SSL and S/MIME certificates. These root certs will not have any externally-operated subCAs.
The Enterprise Root Certificate, “TrustCor ECA-1”, is the only root allowed to issue externally-operated subCAs.

* This request is to turn on the Websites and Email trust bit. EV treatment is not requested.

** CP 3.2.5 Validation of authority
TrustCor CA, or any authorized external RA, must verify the evidence accompanying a certificate request according to the following certificate types:
- DV SSL Certificates - the domain name registrar must list the applicant as part of the WHOIS record; or effective control of the domain shall be demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be obtained.
- OV SSL Certificates - In addition to the communications as per DV SSL Certificates, the CA/RA must also be satisfied that such assurances as per BR 3.2.2.2 and BR 3.2.2.3 have been completed. Specifically, reliable data sources such as government registries of incorporation shall be consulted to verify that the organizational identity can be reasonably asserted in the certificate subject.
- S/MIME Certificates - the requestor must demonstrate control over receiving and sending messages from the specified email address.
- Level 2 Individual-Organizational Certificates - the CA must possess communication delivered using a reliable method that the individual has an ongoing association with the organization; and that this communication must be sourced from someone in the organization 29 with the ability to speak authoritatively for its associations (e.g. an HR representative, the signatory to a contract of employment, etc.)

* EV Policy OID: Not Requesting EV treatment

* Test Websites
RootCert CA-1 valid: https://catest1.trustcor.ca/
RootCert CA-1 revoked: https://catest1-revoked.trustcor.ca/
RootCert CA-1 expired: https://catest1-expired.trustcor.ca/

RootCert CA-2 valid: https://catest2.trustcor.ca/
RootCert CA-2 revoked: https://catest2-revoked.trustcor.ca/
RootCert CA-2 expired: https://catest2-expired.trustcor.ca/

ECA1-External valid: https://valid.epki.external.trustcor.ca/
ECA1-External revoked: https://revoked.epki.external.trustcor.ca/
ECA1-External expired: https://expired.epki.external.trustcor.ca/

* CRL URLs:
CA1 - http://crl.trustcor.ca/root/ca1.crl
CA1 - http://crl.trustcor.ca/root/ca2.crl
ECA1 - http://crl.trustcor.ca/root/eca1.crl

* OCSP URLs:
CA1 - http://ocsp.trustcor.ca/root/ca1
CA2 - http://ocsp.trustcor.ca/root/ca2
ECA1 - http://ocsp.trustcor.ca/root/eca1
Maximum expiration time of OCSP responses: 4 days

* Audit: Annual audits are performed by Princeton Audit Group (PAG) according to the WebTrust for CA and BR audit criteria.
https://cert.webtrust.org/SealFile?seal=2169&file=pdf
https://cert.webtrust.org/SealFile?seal=2163&file=pdf

* Forbidden or Problematic Practices (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices)
** Delegation of Domain / Email Validation to Third Parties
** Allowing External Entities to Operate Subordinate CAs
*** CPS section 1.3.1: The Enterprise Root Certificate (ECA-1) - used as the ultimate root for enterprise PKIs issuing credentials to their principals in restricted namespaces. ...
TrustCor CA undertakes to ensure that all operations conducted using these certificates, including registration of entities, validation of same, issuance and revocation of certificates are performed in accordance with the strictures of this document, the governing CP. Note that Enterprise Subordinate CA certificates are still TrustCor CA certificates, and TrustCor CA is responsible for their issuance, insofar as the enterprise subscriber agreements is obeyed. TrustCor CA is responsible for revoking an enterprise subordinate CA should it discover substantive violations of its enterprise agreements.
*** CPS section 1.3.2: External RAs are present where external Enterprise CAs have been licensed to issue name restricted TrustCor CA certificates; such RAs must adhere to the terms of registration, validation and publication as noted in this document as well as the Enterprise Subscriber Agreement between TrustCor CA and the subscribing organization. External RAs are not entitled to perform general domain or organizational validation; they are strictly limited to registration for credentials to domains and principals assigned to their specific organization.
*** CPS section 3.2.6: TrustCor CA may cross-certify other CA certificates, subject to a specific agreement between TrustCor CA and another party.
The cross-signed certificates will be made available under the same terms as TrustCor CA’s own CA certificates on the repository specified in Section 2.1.
*** CPS section 4.2: For Enterprise Subordinate CAs, the processing is done by the RA belonging to the enterprise subscriber, and issuance is done under the technically restricted CA software under the enterprise subscriber’s control.
*** CPS section 7.1.2.2: For Enterprise Subordinate CAs, there will also be a NameConstraints extension, which represents the following information:
- permittedSubtree:
-- dNSName: (repeated for each domain owned by the subscriber's enterprise)
-- dirName: C=, ST=, L=, O=
- excludedSubTree:
-- IP: 0.0.0.0/0.0.0.0
-- IP: 0:0:0:0:0:0:0/0:0:0:0:0:0:0

This begins the discussion of the request from TrustCor to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits.

Aaron

[Nick Lamb]

On Thursday, 18 May 2017 04:23:17 UTC+1, Aaron Wu wrote:
> - DV SSL Certificates - the domain name registrar must list the applicant as part of the WHOIS record; or effective control of the domain shall be demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be obtained.

Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong here? Judging from self-assessment document, TrustCor's actual practices are all intended to be 3.2.2.4 compliant (I will examine in more detail later) but the language here suggests it might be possible for applicants to successfully validate for DV by some other means not listed in 3.2.2.4, which (again unless I'm mistaken) Mozilla considers always to be mis-issuance.

[Gervase Markham]

On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it might be
> possible for applicants to successfully validate for DV by some other
> means not listed in 3.2.2.4, which (again unless I'm mistaken)
> Mozilla considers always to be mis-issuance.

As of 21st July 2017, yes :-) The language should be clear that only
3.2.2.4-conforming methods are allowed, and each documented method
should say which subsection of 3.2.2.4 it is complying with.

Gerv

[Neil Dunbar]

> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On 18/05/17 23:40, Nick Lamb wrote:

>> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
>> here? Judging from self-assessment document, TrustCor's actual
>> practices are all intended to be 3.2.2.4 compliant (I will examine in
>> more detail later) but the language here suggests it might be
>> possible for applicants to successfully validate for DV by some other
>> means not listed in 3.2.2.4, which (again unless I'm mistaken)
>> Mozilla considers always to be mis-issuance.
>

> As of 21st July 2017, yes :-) The language should be clear that only
> 3.2.2.4-conforming methods are allowed, and each documented method
> should say which subsection of 3.2.2.4 it is complying with.

The BR self assessment document (as well as the CPS) does indeed stipulate which of the 3.2.2.4 subsections are allowed in validation of a DV certificate. No methods outside of 3.2.2.4 are permitted. The WHOIS method mentioned here is allowed via BR 3.2.2.4.1. Note that not all of the allowed methods from the 3.2.2.4 subsections are actually used by TrustCor. It is possible that the self-assessment summary might lead to the (incorrect) conclusion that methods other than 3.2.2.4 could be successful, but the TrustCor documents make clear that only 3.2.2.4 methods are allowed

With respect to the particular clause referring to WHOIS, from the current CPS:

"3.2.2.4.1 Validating the Applicant as a Domain Contact
TrustCor will use the WHOIS or RDAP protocols to gain the Domain
Registration document for the domain(s) being requested for certification.
The email address, name, physical address present in the WHOIS record
must match those details submitted as part of the application."

Regards,

Neil Dunbar
CA Administrator,
TrustCor Systems, S. de R.L.