Greetings,

I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
following notes:

*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
TrustCor CA makes no authoritative statement, will have either the text “No
stipulation” or “Not Applicable”." but these sections are just blank.

3.3.1
"Level 2 Client certificates - demonstration of a pre-shared key and OTP
validation as described in Section 3.2.3 is sufficient to allow re- key."
however section 3.2.3 makes no mention of pre-shared key and OTP validation.

4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement.

6.1.5
"OCSP responses may respond using the SHA-1 hash if the request used
SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
(section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
TrustCor does not, and never has, used SHA-1 as a component of any
signature algorithm on a certificate.

6.1.6
This section references version 1.3.0 of the BRs, which date from 2015.

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

1.4.1
The maximum validity of the different certificate types, while within
what's allowed by the BRs, aren't consistent with the limits specified in
section 6.3.2 of the CP (e.g. 12 months vs 398 days).

2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving.

2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)

3.2.2.4.7
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers"

3.2.2.8
Fail shut CAA - good

3.2.6
While it's good that TrustCor will publish cross-signed certificates it
issues to other CAs, my understanding of section 3.2.6 of the BRs is that
it requires cross certifications that a CA obtains from other CAs (i.e.
where it is the Subject of the cert) to be published.

4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 4.9.1.1 does not list a subscriber request as a
reason for revocation.

4.9.1.2
I would like to hope that there are technical, not just business, controls
in place to limit the actions an "insufficiently aware staff member" could
perform.

7.1.2.2
Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
MUST be present and SHOULD NOT be marked critical." for Subordinate CA
Certificates, however this section implies that certificatePolicies is only
specified for Enterprise Subordinate CAs.

7.1.2.3
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?

7.1.2.4
It seems odd that this section references itself and 7.1.2.5.  Where these
meant to be 7.1.2.2 and 7.1.2.3?

The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS.

7.1.6.3
This seems at odds with 7.1.2.2 of the BRs.

Those comments aside, I found both documents clear, well written, and they
provided sufficient detail to assess the policies in place.

Many thanks,

Andrew
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to