<snip>A year and 10 days ago, I posted bug https://bugzilla.mozilla.org/show_bug.cgi?id=233458 as a test case for mozilla's new (not then developed) CA policy.
I'm not sure that the present draft passes that test.
<snip>Today's policy draft includes multiple sets of criteria against which a CA may choose to have itself measured. Some of those sets do incorporate minimum "standards generally advocated for CAs", but others seem to allow the CA to define its own practices, and attest to nothing more than what (little) the CA said it would do.
Is that good enough for mozilla?
I've responded to a similar concern of yours before, and I hope you'll forgive me for quoting liberally from that response. The current draft essentially codifies the existing practices that I've been following in approving CAs, just with some added flexibility in terms of how CAs are evaluated. The alternative is to try to set some level of standards, in essence mandating the types of certificate policies (and corresponding CPS, etc.) that a CA needs to be operating against.
So, first let me repeat my questions from last time you asked something like this; I never got a response from you or anyone else (except from Gerv, who wrote in essence that we didn't have to worry about question 4, which was mainly motivated by the question about differential treatment of JavaScript for http and https pages). (But... don't feel you have to answer the questions below just yet; keep on reading!)
<quote>
For the record, I would be willing to consider revising the draft CA certificate policy to incorporate requirements on minimum assurance levels for particular purposes. However...
1. I'd like more information on whether you and others want this simply as a "good thing", or whether we have real evidence that this will address a real problem, based on past evidence and future plausibility. If this is mainly just a "good thing" then while I might agree that it's a "good thing" as well, I don't necessarily want to enshrine it in policy, at least right now.
2. I need proposed language for a future policy draft, and a consensus behind that language; this by implication also means consensus on what the minimum requirements should be for each type. If there is no such consensus then I will postpone this issue to a future version of the policy.
3. I would like to see some investigative work done to determine how this policy would affect "incumbent" CAs (i.e., CAs already in the list prior to my taking on approving new ones) and "newly-approved" CAs (i.e., CAs I've approved myself). Since part of the policy involves the possibility of going back and re-considering CAs already on the list, I'd like to know how this proposed change is going to affect things. (For example, will we have to face a decision on kicking out a lot of CAs, or at least restricting the "trust bits" we set for them?)
</quote>
Now, just to show you that my mind is open on this issue, I'm going to lay out a possible way to address the concern you have, and in the course of doing that I'll answer question number 2 above (see, I'm making life easier for you already :-).
Right now the policy draft specifies four reference documents: X9.79, ETSI TS 101 456 and 102 042, and WebTrust. It seems to me that your concern thus far is mainly with WebTrust, based on the idea that a CA could potentially pass a WebTrust audit based on compliance to a CPS that was extremely loose. (I think in practice that's unlikely, at least to the extent that you take it in bug 233458, but for the sake of argument we'll assume that you're correct.)
I think X9.79 would allay some of your concerns, because it mandates lots of stuff that WebTrust leaves as "illustrative controls", but there's still "wiggle room" even in X9.79; for example (exercising my fair use rights again), section B.3.1 of X9.79 on identification and authentication requires only that
The CA verifies or requires that the external RA verify the identity of the entity requesting a certificate in accordance with the CA's CPS and the applicable Certificate Policy.
and similar statements; in particular, it doesn't mandate any particular form or manner of required identification of entities.
Now let's turn to ETSI TS 101 456 and 102 042. As it happens, these standards do specify certain minimum requirements, in the form of the specified certificate policies described in the standards (in increasing order of rigor):
* the Lightweight Certificate Policy (LCP) of 102 042
* the Normalized Certificate Policy (NCP) of 102 042 and Qualified Certificate Policy (Public) (QCP public) of 101 456
* the extended Normalized Certificate Policy (NCP+) of 102 042 and Qualified Certificate Policy (Public + SSCD) (QCP public + SSCD) of 101 456
So one approach would be to say that the requirements of the LCP are a "floor" for the certificate policies of any CA to be included, in the sense that the requirements associated with the CA's policies would have to be equal to or greater than the LCP requirements.
But I'm willing to consider going further: Since people have expressed concern about the rigor involved in vetting applicants for SSL server and code signing certs, we could use the LCP as a floor for email certs, and the NCP as a floor for SSL and code signing certs. This likely corresponds to typical CA practice today: the LCP permits the equivalent of class 1 email certs not requiring much user authentication, while the NCP requires presentation of appropriate identity documents (in person or otherwise).
Assuming we take this latter course, here's some possible language: I would first change clause 6 to add an additional requirement:
6. We require that all CAs whose certificates are distributed
with our software products: ... * have Certificate Policies that we deem acceptable for the stated
purpose(s) of the certificates issued by the CAs; ...and then I'd add a new clause (probably numbered 8) as follows:
?. We consider Certificate Policies to be acceptable if their
associated requirements equal or exceed the following
requirements: * for certificates to be used for digitally signing and/or
encrypting email messages, the requirements associated with
the Lightweight Certificate Policy (LCP) described in
ETSI TS 102 042 V1.1.1 (2002-04); * for certificates to be used for SSL-enabled servers, the
requirements associated with the Normalized Certificate Policy
(NCP) described in ETSI TS 102 042 V1.1.1 (2002-04); and * for certificates to be used for digitally signing code objects,
the requirements associated with the Normalized Certificate
Policy (NCP) described in ETSI TS 102 042 V1.1.1 (2002-04);We reserve the right to accept other requirements in the future.
(Note that I didn't reference ETSI TS 101 456 because it doesn't really add anything; it doesn't have an equivalent policy to the LCP, and the QCP public policy is simply a mirror of the NCP.)
So, for Nelson and others, here's your homework assignment: Go get a copy of ETSI TS 102 042 and determine for yourselves the answers to the following questions:
1. Are the requirements of the LCP and NCP consistent with your idea of what's appropriate for issuing email certs and SSL and code signing certs respectively?
2. Are the requirements of the LCP and NCP consistent with your knowledge of the practices of the CAs already included in Mozilla, with respect to issuance of email certs and SSL/code signing certs respectively?
3. Are the requirements of the LCP and NCP consistent with your knowledge of the practices of CAs like CAcert and others that might apply for inclusion under our future policy, with respect to issuance of email certs and SSL/code signing certs respectively?
If the answer to all three questions is "yes" then in the absence of any objections I'll go ahead and add my proposed new language to the next draft. Otherwise we can discuss this some more to see how else we might want to approach this issue.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
