On Wed, July 29, 2015 1:34 pm, Kathleen Wilson wrote: > SSC has applied to include three root certificates as follows: enable > the email trust bit for the âSSC GDL CA VS Rootâ certificate; enable > the > code signing and email trust bits for the âSSC GDL CA Root Aâ > certificate; and enable all three trust bits for the âSSC GDL CA Root > Bâ > certificate. EV treatment is also requested for the âSSC GDL CA Root > Bâ > certificate. <SNIP> > This begins the discussion of the request from SSC to include three root > certificates as follows: enable the email trust bit for the âSSC GDL CA > VS Rootâ certificate; enable the code signing and email trust bits for > the âSSC GDL CA Root Aâ certificate; and enable all three trust bits > for > the âSSC GDL CA Root Bâ certificate. EV treatment is also requested > for > the âSSC GDL CA Root Bâ certificate. > > At the conclusion of this discussion I will provide a summary of issues > noted and action items. If there are outstanding issues, then an > additional discussion may be needed as follow-up. If there are no > outstanding issues, then I will recommend approval of this request in > the bug. > > Kathleen >
Kathleen, I've completed a thorough review of the relevant CP and CPS for SSC. First, on a practical and procedural note, should Mozilla continue accept certificates without the "Websites" trust bit? Considering that there are not clear guidelines for how to process either code signing or email, and considering their relevance (or lack thereof) to Mozilla, it would seem wise to carefully consider both whether to accept new applications and what to do with existing applications. My own personal suggestion is to not accept new certificates, and to purge the existing ones. I have not examined the CP or CPS for issues related to these two, and only focused on the Website Trust bits - thus, relevant to the SSC GDL CA Root B hierarchy. I conducted my primary review against the (draft) 4.10 version of their policy. Though it indicates there were versions 4.8 and 4.9, 4.7 is the current (audited) policy, it would appear. The URL for this document is https://bug379152.bmoattachments.org/attachment.cgi?id=8613560 == Good == * Section 4.1 clearly states the Subscriber Agreement includes a requirement to consent to publish the certificate (for example, via Certificate Transparency) * Section 4.2.3 indicates that the maximum window between RA verification of information and issuance is only five days. * Section 4.4.3 provides a suitable carveout to allow SSC to publish certificates via Certificate Transparency. * Section 4.7 clearly identifies that other elements of a certificate, beyond the Subject, may change during a renewal or rekey * Section 4.9.3 clearly recognizes third-parties may request revocation / provide information that may lead to revocation. == Meh == * Section 3.1 implies that SSC will issue certificates with names encoded using the TeletexString, BMPString, or UniversalString encodings. These are all STRONGLY discouraged in RFC 5280, Section 4.1.2.4, except for legacy interoperability cases. Based on the stated CP and CPS, it does not seem necessary or wise to support these types. * Section 3.1.1 uses a somewhat ad-hoc stringified form to represent names, leaving it ambiguous as to the actual structure. While the footnotes clearly indicate the relevant OIDs, perhaps the tabular form employed by other CPSes (such as the recently completed WISeKey review) may provide greater clarity to Relying Parties. == Bad == * Section 3.2.2 leaves it ambiguous and underspecified how domain name authorization is performed. * Section 3.2.4 leaves it ambiguous about how email addresses are validated. * Section 3.3.1 allows for rekey using previously validated information, for a period greater than allowed by the EV guidelines (36 months in the CPS, 13 months in the EVG) * Section 4.1 includes a subscriber obligation to "install the ... certificate only on the server accessible at a Domain Name indicated in the certificate." This obligation is ambiguous (technically, any server is accessible via any domain name, with the right configuration) and likely unenforceable. Plus it's just weird :) * Section 4.9 implies that DVCP/OVCP certificates may take 48 hours to revoke, rather than the 24 hours required by the Baseline Requirements. * Section 4.9.1 has a number of revocation reasons stated only for EVCP/EVCP+, even though they are applicable to DVCP/OVCP. * Section 4.9.9 omits OCSP for DVCP/OVCP. * Section 6.1.6 lacks a robust definition of the key sizes and algorithm parameters. * Section 6.1.7 omits the keyEncipherment bit, potentially prohibiting forward-secure key exchanges with RSA keys. * Section 7.1 neither documents nor does the repository provide copies of the Certificate Profiles. Section 7.1 of the CP appears to expressly require this, so it would seem as if the CPS is not adhering to the CA's CP. * Section 7.2 links to a URL that does not provide the CRL profile, despite being required by the CP. * Section 7.3 does not include an OCSP profile, despite being required by the CP. == Questions == - From interpreting Section 3.1.1, it would appear that a TLS server certificate (e.g. DVCP, OVCP, EVCP, EVCP+) will never have a commonName field appear within the subject, as the commonName is expressly identified as containing a legal person's identity. Is this correct? - Section 3.1.2 suggests the formulation of the commonName is "firstname lastname". Names come in many forms (e.g. Seal, Madonna, Sting), and in many cultures, may not follow such a construct. If a Lithuanian citizen legally changed their name to "google.com", would SSC issue such a certificate? - Section 3.1.5 indicates that names are unique, but the name form of Section 3.1.1 does not provide enough disambiguators to guarantee this for the case of non-qualified certificates. How does SSC handle this? - I could not find any documentation within the CP or CPS regarding the practices, procedures, and controls for the issuance of third-party subordinate CAs. The information gathering document suggests this is supported, but the absence of documentation is concerning. I also briefly reviewed the CP, version 4.4 ( https://gdl.repository.ssc.lt/en/repository/documents/certificate-policy-ssc-gdl-ca-v4.4.pdf ), which largely defers to/sets stipulations for the CPS. Within this, I found one area particularly concerning (i.e. "bad"), which is that Section 4.9.13 indicates Certificate Suspension may be supported. >From the documents and repository, I was unable to locate suitable test sites complying with Section 2.2 of the Baseline Requirements (v1.3.0). Indeed, of the test sites provided ( https://gdl.repository.ssc.lt/en/repository/test-certificates/ ), two were improperly configured (OV SSL Personal, OV SSL Legal Entity). The revoked certificates were merely hosted as certificates, not as separate Web pages using Subscriber certificates, as required by the BRs. Perhaps most concerning of all in this application is that the CPS indicates the issuance of DVCP/OVCP certificates, except no such audit has been performed according to Tuvit. The ambiguity regarding much of the TLS issuance practices, and in particular, the request for the "Website" trust bits without a corresponding audit for the issuance practices related to website trust bits (DVCP/OVCP, equivalent conceptually to the "Webtrust for CAs - SSL Baseline Requirements v2.0" documentation), give me strong concern. Remediation of this would be a significant undertaking to update the CP and CPS to provide appropriate guidance and statements as to the adherence to the BRs and Mozilla Policy. In many cases, it simply incorporates by reference, which concerns me that SSC may not have properly implemented controls to actually follow the BRs. I would encourage SSC to review the past several CA inclusion requests, including the most recent of WISeKey, and the areas of concern flagged there, many of which are applicable here. Similarly, examining the CP and CPS in the context of the CA/Browser Forum's Baseline Requirements, v1.3.0 will provide ample guidance as to the expected assertions, many of which were absent or incorporated by reference, which give significant concern. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
