Andrew. Thank you for the review, comments and questions on TrustCor's policy documents.
We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list. Have a great weekend, Neil Dunbar, TrustCor CA Administrator > On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
