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've read these once, should read them again.
(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 :-)
Whatever's simplest would get my vote (if we were voting :) I know CRLs are quite contraversial, and as they seem quite new in terms of full implementation, a wait and see attitude might be sensible.
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.
With email, people generally deal person to person, and they introduce over the phone, etc. It is plausible that an attacker could take over an email account, and then request a cert, but in this case, the damage has already been done, as this is in fact an MITM attack; the notion of the system is to protect against MITMs before hand.
I've never heard of anyone falling to such an attack in the OpenPGP world, and their "standards" are arguably as open.
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 :-)
There has been a lot of mail....
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
