I've been trying to think of a ways to raise the bar for security using practical approaches. Apologies for the long soapbox :)
And I apologize for not responding to your post before now; it's certainly relevant to our discussion of the proposed CA certificate policy.
What do you think about requiring that for each root or CA to be included (new or legacy!) require that the CA respond to:
Before I get into the actual suggestions themselves, one overall issue is what (if anything) we are going to do with this information. Is this simply information we could make available to interested users, e.g., as I've done with my CA cert page?
http://www.hecker.org/mozilla/ca-certificate-list
If this is the case, then more information is good, but it's not clear how "typical" end users (the target for the policy) would be expected to make use of the information.
Or is your proposal to enforce minimum requirements for CAs? If this is the case, the more important question IMO is, what should the minimum requirements be? It seems that in essence we'd be (again) trying to invent our own set of criteria to supplement or replace the external criteria referenced in the draft CA certificate policy. See also my comments regarding Nelson's suggestion to require minimum assurance levels for particular types of certificates (e.g., don't allow email-based verification for SSL server certs).
For now I'm going to assume that the main point of your suggestions is to provide additional information for interested users, as well as information we could use in evaluating our own potential policies. (For example, if we discover that there are strong commonalities in how CAs do things, we could use that in support of the various proposals for having standard cert "classes" and reflecting those in the UI.)
a What authentication do you do? Be as brief and specific as possible.
("for this root we do 2 email roundtrips at least 2 days apart but
within a week - each roundtrip contains a 64 bit PIN that must be
entered into a webform within 24 hours. We do not authenticate [and
therefor do not include in the certificate] the identity of the
enrollee") ("For this root we use 3 non-Internet methods to confirm
that the enrolee is entitled to use the legal identity specified for
the subject of the certificate as well as the right to use any domain
names specified for the subject of the certificate")
I suspect the above topic would be covered in the CA's Certification Practice Statement. However there's an important point here, one that applies to several of your other items as well: A number of CAs do not publish their CPS and related documents in English, so they're not necessarily widely usable by interested users (or by us, for that matter).
I've been able to sidestep this issue thus far since (as Nelson pointed out) currently we don't evaluate the CPS per se, we evaluate the CA's compliance to the CPS (e.g., as determined by a WebTrust audit). If we were to change that then we'll need to either get the CPS translated (a major task considering the typical length of a CPS) or separately ask the CA to provide the requested information in English.
b What kind of assurances to you provide around "a"? Do you have a cash warranty program? For how much?
AFAIK this should be covered in the CA's Certificate Policy and Relying Party Agreement.
c What kind of freshness service do you provide in case you have to revoke a certificate for bad issuance or in case of a policy violation by the subscriber? For CRL or OCSP do you always include a pointer in the subscriber certificate (so that software can easily check the revocation status)? If so how reguarly is the CRL or OCSP information updated (monthly? weekely? hourly? real-time?).
This should be covered in the CPS.
d What kind of usage policy do you have? Please answer the Yes No questions, please add extra policies information you feel is relevant. d1 For certificates you want enabled for SSL Server identitification - would you revoke the certificate if you learned it was being used for phishing? d2 For certificates you want enabled for Secure Email - would you revoke the certificate if you learned it was being used for UCE? d3 For certificates you want enabled for Software Signing - would you revoke the certificate if you learned it was being used to sign software that did not up front and clearly disclose it's behavior?
The above information would likely not be included in the CPS or in any other relevant document, at least based on my readings of the ones I've come across. However I agree that this could be useful information, assuming that we could get the CAs to be forthcoming on this.
e Do you include an issuerLogo in every certificate? This helps enablee consumers and relying parties to identify you and builds a reputation of trust in your brand.
Well, yes, but only if we and other browser/email vendors actually do something with the issuerLogo :-)
e What kind of software development, operational quality, and security standards to you conform to, check all that apply: e1 ISO 9000 e2 FIPS 140-1 e3 FIPS 140-2
AFAIK the use (or non-use) of FIPS 140-1/140-2 validated cryptographic modules would normally be covered in the CPS. I think some CAs claim ISO 9000 conformance as well, but I can't remember if I've seen this in CPS documents or just as a claim on the CA's web site.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
