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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
