I've posted a new version of the "policy details" section of the CA certificate that discusses CA-related risks/threats and the evaluation criteria for CAs intended to address those risks/threats. The new material is confined to the following two questions:

http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#risks
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#criteria

I'm in danger of falling asleep so I have not completed the criteria section; however I wanted to go ahead and post what I've done thus far.

Note in that regard that I have some open questions in particular about CA evaluation criteria relating to notification of certificate revocation (i.e., via CRLs or OCSP). I haven't time to look into this deeply, so I'm somewhat unclear on whether CRL checking and/or OCSP validation is or will be enabled by default. If CRLs and OSCP are not used by default then (to play devil's advocate) I claim that there is no point in having CA evaluation criteria relating to CRLs or OCSP, since this policy is intended for typical users (per the meta-policy) and typical users will never end up using CRLs and OCSP. (This follows from my stated assumption that typical users don't change the default security settings, or at least they don't change them so as to increase the level of security checking.)

(Note that I'm mainly joking here about omitting criteria relating to cert revocation. But IMO we do need a clear direction on default use of CRLs and OCSP; otherwise I might decide I'm not really joking :-)

There's another criteria-related issue that I sort of skated over by the language I've chosen, namely the issue of what level of verification a CA really should be doing at the time of certificate issuance. For example, with certs used for S/MIME email, is it "OK" if the CA simply checks to see if the certificate requester controls the specific email address (in the sense of being able to receive mail at that address), or should the CA in addition attempt to verify that the requester is really the authorized user of the account (e.g., by asking the requester to provide additional identifying information)?

On the one hand, the person requesting the cert could be an attacker who has gained control of the authorized user's system and email account, so the simple check is arguably not sufficient. On the other hand, there are arguably benefits to offering a CA service that does just the simple check, and in fact to my knowledge various public CAs have in fact offered just such a service.

To make my personal position clear, I tend to agree with the latter position (OK to do the simple check) but I'm willing to entertain other views. However if you do advocate more stringent checks then you need to justify the risk/benefit tradeoff here, including explaining what we should do with regard to the existing CAs I mentioned above.

Frank

P.S. As a final note, I have not had time to read and digest all the various posts touching on risks/threats/criteria, so I've probably missed some good points in doing my draft. My apologies for that -- but I'm sure you all will correct me if you think I'm missing something obvious :-)

--
Frank Hecker
[EMAIL PROTECTED]
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to