Andrew, Many thanks for reading and commenting on the policy documents. In order to clarify and correct the issues which you highlight, new versions (at version 1.3.2) of both CP and CPS have been published.
A summary of our actions follows. Paragraphs introduced with the text "<TC>" indicate our response to the issues raised. "*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." <TC> The References and Conventions sections in both the CP and CPS documents have had the blank space replaced with "No Stipulation". 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. <TC>Section 3.2.3 has been updated to explicitly mention the multi factor authentication steps as mentioned in 3.3.1. "4.4.2 Publication of the certificate by the CA Note that is at odds with any future CT requirement." <TC>This section of the CP has been replaced with one which explicitly allows for publication to CT logs. "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." <TC>It is our reading of the BRs that the use of SHA-1 as a _certificate_ signature is forbidden (including for OCSP Responder certificates); not that such hashes are forbidden within the context of OCSP Request/Response structure. Please note that our responder _certificates_ do not use SHA-1, and never have. The text here only mentions that signed OCSP responses (which have an maximum lifetime of 8 hours) may use SHA-1. The text of this section has been revised to make completely clear that the SHA-1 signature does NOT apply to responder certificates. It is worth noting that section 4.3 of RFC 6960 states that OCSP clients SHOULD be able to process such response signatures, indicating that such support is to be reasonably expected. Note that TrustCor is capable of removing SHA-1 as a signature hash on OCSP responses, if the community determines it presents risk to the relying parties. However, this does raise the risk to some clients that would fail to understand the signature on the response. We should prefer to service as many clients as faithfully as we can while remaining true to the security principles of this community. "6.1.6 This section references version 1.3.0 of the BRs, which date from 2015." <TC> This oversight has been corrected, and refers to the controlling version of the BRs stipulated in the document overview section (1.1). *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)." <TC>The CP has been corrected to refer to number of days, so as to be consistent across all documents. "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." <TC> The CPS has been updated to use the correct URIs, namely: https://catest1-revoke.trustcor.ca/ https://catest1-expire.trustcor.ca/ https://catest2-revoke.trustcor.ca/ https://catest2-expire.trustcor.ca/ Note that the Self-Assessment documents contained these (correct) URIs - this was an oversight stemming from a DNS change which should have been reflected in the CPS. "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)" <TC>The URI now resolves to the correct (albeit unpopulated) incident page. "3.2.2.4.7 Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor will *query* the authoritative DNS servers"" <TC>This has been corrected to include that word. "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." <TC>Section 3.2.6 has been updated to make clear that bilateral publication is honoured. That is, if a TrustCor certificate is cross-signed by another CA, then TrustCor will make such publication known, in its normal certificate repository. "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." <TC>The text has been clarified to include subscriber request as a valid 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." <TC>There are indeed technical controls, detailed in the security policy (which forms part of the audit documentation) that restrict actions of staff members. These include explicit ACLs, sudo restrictions, mandatory access controls and so on, which all place barriers to malicious or mistaken actions. The text in the section has been amended to explicitly refer to those controls. "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." <TC>The text has been updated to make clear that the certificatePolicies applies to all Subordinate CA certificates, not just 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?" <TC>The text has been changed to reflect that rfc822Name is the subjectAlternativeName tag, and that the email address is its content. "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?" <TC>The text has been updated. Indeed the references were supposed to be 7.1.2.2 and 7.1.2.3 - those were dangling references to a different document structure, now corrected. "The CP requires the subject key identifier and authority key identifier extensions, but these are not specified in the cert profiles in the CPS." <TC>This is an omission. The SKI and AKI have always been published. The text is now updated in the CPS to be consistent with the language of the CP. "7.1.6.3 This seems at odds with 7.1.2.2 of the BRs.” <TC>This was an omission. Policy identifiers are present in all Subordinate CA certificates. This text was originally meant to refer to Name Constraints and extendedKeyUsage identifiers, and not to certificate policy identifiers (e.g. CPS OIDs and URIs). It has been corrected to apply to all Subordinate CA certificates. Best regards, 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
