On Fri, April 24, 2015 4:58 pm, kwil...@mozilla.com wrote: > Other than the concerns that have been raised about CRL and OCSP, are > there any further questions or comments about this request from LuxTrust > to include the "LuxTrust Global Root" root certificate, turn on the > Websites and Code Signing trust bits, and enable EV treatment?
Hi Kathleen, I've completed a review of the LuxTrust Global Root CA certificate profile [1], the Global Root CA CPS [2], and the LuxTrust SSL CA CPS [3]. Similar with Certinomis, I found nothing of serious concern, but do want to higlight several issues that may be worth discussion or consideration. I do think that the inclusion request should not proceed until the modifications to the revocation system have been completed. It is also somewhat concerning that this was not raised during audit, since it is incorporated into the appropriate ETSI requirements that LuxTrust was audited to. I have not examined the technical content of any of the certificates to ensure compliance with these policies. === Certificate Profile === ===== Copyright ===== Similar to the issues highlighted with Certinomis, LuxTrust prohibits duplication or redistribution of the CA's CP or CPS documents. This is not strictly required for inclusion, however, as noted in Section 10 of [4], "All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part." ===== basicConstraints ===== Rather than highlight an issue, I'd like to commend LuxTrust for ensuring that all of their subordinate CA certificate have a basicConstraint with a pathLen of 0 (as shown on Page 29, Section 3.2). This helps ensure that even in the event of software failure, no subscriber certificates capable of issuing certificates can be issued. ===== Names in non-SSL certificates ===== While the majority of the certificate profiles indicate a combination of names with a space character, several non-SSL types do not provide this proviso. Because these certificate profiles also lack an extendedKeyUsage X.509v3 extension, and because they have the necessary keyUsage bits, it may be possible to use these certificates as part of TLS servers with Mozilla applications. Mitigation for this is to ensure that no "domain-shaped" name can be issued for these types, and to specify this explicitly in the policies. For example, ensuring a space character is used as a joiner, as some of the profiles explicitly call out, is one way to do this. This applies to Page 73, Section 3.3.15, Page 76, Section 3.3.16, Page 78, Section 3.3.17, and Page 81, Section 3.3.18. Similarly, Page 83, Section 3.3.19 does not prohibit the commonName from being "domain shaped", as a result, may be used for TLS. ===== Names in SSL certificates ===== It's unclear why the significant duplication in Page 87, Section 3.3.20 for the dNSName subjectAltNames. It would seem sufficient to dictate the policies for validating the dNSName, however many instances occur. ===== Typos ===== Both Page 93, Section 3.3.21 and Page 99, Section 3.3.22 contain a typo of "streedAddress" rather than "streetAddress" === Global Root CA CPS === ===== Copyright ===== Similar to the above issues, Page 7 contains a somewhat restrictive copyright clause. ===== Cross-signing ===== Page 11 makes it clear that LuxTrust reserves the right to cross-sign other CAs. LuxTrust should be aware of Sections 8, 9, and 10 of [4]. Elsewhere in the policy, it seems clear they understand the obligation to disclose, but it's worth re-emphasizing that if LuxTrust does engage in a cross-signing engagement, they will ultimately be held responsible. ===== Trademarks ===== It looks like there's some confusion with respect to Page 28, Section 3.1.4 as to what this section is meant to contain. I would refer LuxTrust to the Certinomis discussion for an example section, as well as the issues that may arise. ===== Revocation Requests ===== Similar to Certinomis, Page 34, Section 4.9.2 contains some issues with respect to who can request revocation. The SSL CP seems to do better at addressing the needs for relying parties to be able to request revocation for certificates that fail to comply with LuxTrust's stated policies, and there may be area to improve this section. === SSL CA CPS === ===== Copyright ===== Already said this one twice :) ===== ETSI status ===== Page 19 notes an ongoing expectation of compliance with appropriate ETSI criteria, with an expected completion of March 2014. I believe this section needs to be updated, since that's quite some time ago? :) ===== Publication of Certificates / Certificate Transparency ===== Page 20, Section 2.3.1, Page 32, Section 4.4.2, and Page 32, Section 4.4.3 all list various claims that the issuance of certificates will not be publicized. However, as LuxTrust operates an EV-capable CA, if they wish to be recognized as such in browsers such as Google Chrome, they will need to be publicizing their certificates in an appropriate Certificate Transparency Log. This creates a potential issue for policy non-compliance, so I raise it now as a potential issue for LuxTrust to examine when examining their policies as a result of this discussion. ===== Trademarks ===== It appears that Page 22, Section 3.1.6 suffers from the same confusion with respect to trademarks in the names of certificates. ===== Revocation Requirements ===== To begin, I'd like to applaud LuxTrust for making it clear the process for requesting revocation in Page 35, Section 4.9.2. In particular, providing appropriate URLs and contact information for parties to request revocation. That said, it appears this section is incomplete with respect to non-EV certificates and the ability of relying parties to notify LuxTrust of potential non-conformance to the Baseline Requirements or to LuxTrust's CPS. It appears this section needs further work to describe the process and provide appropriate information for such parties. [1] https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1.20.pdf [2] https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_08.pdf [3] https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.2.pdf [4] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
