Re: What we want [was: Audit requirements for government CAs]
Eddy Nigg (StartCom Ltd.) wrote: Currently the ratio of EV certs is below 1% of overall SSL secured web sites. If EV doesn't get a significant market share, your priorities might have been wrong and we should have addressed other issues as well. I don't really have the bandwidth to dive into this discussion, and Frank seems to be doing a good job, but I will comment on this point: the % of _sites_ using EV is pretty much irrelevant. What you need to know is the % of _transactions_ using EV, or even more specifically, the % of value transactions (those where money changes hands). I care much more if Paypal uses EV than if a thousand sites like www.freds-bait-shop.com does. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What we want [was: Audit requirements for government CAs]
Kyle Hamilton wrote: Please tell me how to completely disable all Mozilla Foundation included CAs without having to individually change the trust settings on all of them? I can't trust Mozilla's certificate policy to protect my interests -- I can't trust Mozilla's policy to ensure that strictures that I originally relied on in the certificate issuance policies haven't been relaxed, thus compromising my own ability to trust the certificate issuers involved. How would a policy which _ensures_ this be written? Alternatively, please tell me how I can auto-accept any presented root certificate in Firefox? Write an extension. How can I, as a user, determine if a certificate is DV versus IV or OV or EV without having to fight the user interface to find the information? The EV distinction is clear. And EV exists precisely because the line between DV and IV/OV is fuzzy, and it would have been very difficult to correctly discern the difference programmatically. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What we want [was: Audit requirements for government CAs]
Eddy Nigg (StartCom Ltd.) wrote: Yes, this is a good argument in favor of EV and EV is exactly intended for that. Just a pity the rest of the public PKI is left broken, no matter what the reasons are (by design, lack of interest, commercial interests, etc), because there is more to protect than Paypal, Ebay and few banks. EV however might be an overkill for others. Ah, but isn't EV really returning the public PKI to the ideal of what CAs are supposed to be doing in theory, namely binding a (strongly) verified identity to a public key? So in theory any site supporting high-value transactions (financial or otherwise) should migrate to EV certs. This certainly should include major sites like Bank of America, E*Trade, etc., Amazon, etc., as well as any ecommerce site for which the annual EV cert fee is a small fraction of overall operating expenses. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Audit requirements for government CAs
Gervase Markham wrote: Frank Hecker wrote: It's a reasonable proposal, and we did look into doing this. Unfortunately there are .com domains and perhaps other non-.kr domains with certs issued by CAs in the KISA-rooted hierarchy. This is not unique to KISA and Korea either AFAIK. I personally think that, if all the other technical capabilities in place, our response to that could reasonably be Tough. Sorry.. Note that if we implemented a general enough facility then we wouldn't necessarily have to exclude support of all domains outside the country's TLD. For example, we could have a constraint permitting use of *.kr (or whatever) domains, as well as a selected set of *.com or other domains. This would be unwieldy or downright unpractical in cases where a government wants to establish lots of .com domains, but might work OK for cases where a government has just a few non-country-TLD domains. In the current state of affairs I don't think we have any general way to restrict government CAs or other country-specific CAs to issuing certs under their particular national TLDs; we'd need to have additional code in NSS or PSM to enforce custom restrictions. (Or just not include the roots at all.) As Nelson says, this is a capability we don't have. I personally think we should. My checkbook is open :-) However note that before doing this I think we should make sure we have a full up-to-spec implementation of existing standards around CA name constraints. Then we can think about extending the constraints to include Mozilla-specific requirements. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What we want [was: Audit requirements for government CAs]
Frank Hecker: Gervase Markham wrote: The EV distinction is clear. And EV exists precisely because the line between DV and IV/OV is fuzzy, and it would have been very difficult to correctly discern the difference programmatically. This is a key point worth emphasizing. We use the terms IV and OV, but they don't really mean anything in objective terms; they just mean that a CA claims to verify identity in some manner, with the exact means varying from CA to CA. Correct. In order to implement a strong UI distinction between traditional IV/OV certs and DV certs we would have to determine exactly what each CA is doing, have some sort of objective standard against which we could compare each CA's practices, and enforce such a standard. Define, agree, enforceand conquer. I could make this work without too much investment, but with a little help of Mozilla, a will to do do it, which includes specially yourself. I could give you a clear plan and approach which would within one year have most CAs willingly sub-ordinated into this scheme and the UI could differentiate. This would have been a very onerous task No As I wrote before, EV certs are really what CAs were/are supposed to be doing according to traditional ideas of (X.509) PKI, and I would be happy to see the CA market divide into EV certs and non-EV certs, with the former used for all high-value transactions and the latter relegated to low-value transactions, personal and small group sites, etc. Reality will show you that this assessment is most likely wrong! The danger will be that there will be inroads and a lowering of the EV requirementsjust wait and see. This had already started between the latest drafts and the final version. In the previous mail I explained why other higher validations make sense. Again, Mozilla can decide if it wants to be an active player and if it has something more to offer also in respect to PKI. It can remain passive and continue to follow... -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What we want [was: Audit requirements for government CAs]
Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: (As a side note, based on my experience with and reading about industry dynamics, I think that advances in PKI-related technologies are much more likely to occur in new protocols and new products than in mainstream cases like browsing SSL web sites. A good example is Skype's implementation of an internal PKI infrastructure for securing VOIP traffic.) Outshhh, I don't like to even get into this one :-) Except that they are using some kind of PKI and I'm not sure what's so exceptional or new with it. I don't want to go off on a tangent, but I think the Skype model is more significant than you think. I don't agree with Ian Grigg on everything, but I do think his proposed rule that there is only one mode, and it is secure is worthwhile: http://iang.org/ssl/h3_there_is_only_one_mode_and_it_is_secure.html As I understand it, out of the box Skype achieves encryption of users' VOIP calls and strong identification of a particular user's node (not tied to IP address), with no action needed on the part of the user. It doesn't tie a verified legal identity to the Skype instance (and so doesn't fit the classic X.509 model), but arguably this is not important for typical Skype use cases. I also think that with the advent of EV and the Firefox 3 UI that the world of certs will divide into EV and everything else (OV/IV/DV). Maybe I'm missing something, but I can't see any discernible difference between the UI for https://www.bankofamerica.com/ (OV cert) and the UI for https://www.hecker.org/ (DV cert). Which I personally view as a mistake, because I believe DV and IV/OV certificates should be separated. See my separate comments on this point. If EV doesn't become mainstream and will replace IV/OV certs, than Mozilla (and the industry) will have to come up with some better answers and address this particularly. If EV doesn't become mainstream, then IMO that will signal the utter irrelevance of the traditional PKI/CA model in terms of protecting user security for high-value transactions. After all, the EV model is the very embodiment of traditional thinking about how PKIs can protect user security: have a trusted third party do strong verification of legal identity and bind that identity to a public key, and have users then rely on that authenticated identity before entering into high-value transactions. If web site operators don't care to participate in the EV scheme, and web site users don't care if they don't see a strongly validated identity in the browser UI, then the only significant function of SSL in practice is to provide over-the-wire encryption and some minimal protection against MITM attacks. When in the software world an exploit is detected, the software is usually patched. When an exploit is detected in NSS, it's going to be patched. If however an exploit is detected by a CAs procedure you propose we do nothing until you are convinced that actually somebody is exploiting it and than you propose to adjust the thinking about the proposed threat. Really Frank? If there is a significant cost to protecting against a hypothetical exploit, and there are alternate means of dealing with the exploit in question (particularly more general measures that address more than just the exploit in question), then I suggest that we think carefully before investing time in implementing protection measures designed to deal specifically with such a hypothetical exploit. Take your idea of requiring identity verification for wildcard DV certs, which is designed to address the hypothetical threat of people setting up SSL-enabled phishing sites under their top-level domains (e.g., paypal.example.com). There's are multiple cost to implementing such an idea: a cost to CAs (who may have to change their procedures and product offerings), a cost to cert subscribers (who may have to pay more for certs), a cost to us (who have to figure out all the CAs doing wildcard DV certs, and then try to persuade them to change what they're doing), and potentially a cost to end users (e.g., if they can no longer access sites because we decide to punish CAs by removing their roots or disabling validation of certain wildcard certs). At the same time there are measures already in place to protect users against the general phishing threat, most notably the Firefox phishing protection features; these measures work against phishing sites using the hypothetical wildcard DV cert exploit, and against other phishing sites as well. There is also a general measure available to provide more assurance and accountability for web sites doing high-value SSL-enabled transactions, namely EV certs. So the specific question for me is as follows: Should I devote Mozilla Foundation resources (including my own time) to trying to combat the hypothetical threat posed by wildcard DV certs, a threat for which other protection
Re: What we want [was: Audit requirements for government CAs]
Frank Hecker: I don't want to go off on a tangent, but I think the Skype model is more significant than you think. There is a problem that nobody knows what encryption this is and which keys are involved and who has access to these keys etc. Skype is fine for me, but I wouldn't exchange anything critical with it, that's all. There is nothing wrong with it, but security isn't the main reason I'd use Skype for. Take your idea of requiring identity verification for wildcard DV certs, which is designed to address the hypothetical threat of people setting up SSL-enabled phishing sites under their top-level domains (e.g., paypal.example.com). There's are multiple cost to implementing such an idea: a cost to CAs (who may have to change their procedures and product offerings), Well, they do charge more for them anyway usually, not sure how much this would impact them. a cost to cert subscribers (who may have to pay more for certs), See above. a cost to us (who have to figure out all the CAs doing wildcard DV certs, and then try to persuade them to change what they're doing), and potentially a cost to end users (e.g., if they can no longer access sites because we decide to punish CAs by removing their roots or disabling validation of certain wildcard certs). I don't believe that we'd have to go that far. As Comod indicated, they would go for it if this would be applied across the band. So far I've found only two, Comodo and GoDaddy (the later isn't confirmed, only suspected). So the specific question for me is as follows: Should I devote Mozilla Foundation resources (including my own time) to trying to combat the hypothetical Most threats are hypothetical if you will. They may exist in some for or the other. Correct is however that SSL certificates are hardly used for phishing attacks to start with, because or despite various protections CAs put in place for issuing them in first place. threat posed by wildcard DV certs, a threat for which other protection measures already exist and would appear to be effective, or should I devote those resources to other tasks that arguably offer a greater return on investment in terms of increased security, like say getting more EV-qualified CAs approved to have their EV certs recognized in Firefox? That's a pretty easy question for me to answer. I think one thing isn't connected to the other. If it's this OR that, that would be a bad thing in any case. But I think we can agree that we disagree on both subjects of wild card and long-living certificates which are domain validated. As far as me concerns we had the (intensive) discussion (which is a good thing to have) and this subject can be put aside. I made the arguments and you made the decision and you take responsibility (what Mozilla concerns). -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo request for EV root inclusion (COMODO Certification Authority)
Frank Hecker wrote: Comodo has applied to (among other things) add a new EV root CA certificate for the COMODO Certification Authority to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=401587 snip I have evaluated this request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve the request after a public comment period. The public comment period ended last week, but we had some additional discussions around various Comodo-related issues, most notably the wildcard DV cert issue and the long-lived DV cert issue. Although I acknowledge that there were/are valid concerns associated with those issues, in the end I made a judgment call that they didn't rise to a level that would justify my rejecting Comodo's request or delaying approval. I've therefore given my final approval to this request and filed bugs 426568 and 426572 against NSS and PSM respectively: https://bugzilla.mozilla.org/show_bug.cgi?id=426568 https://bugzilla.mozilla.org/show_bug.cgi?id=426572 Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo request for EV-enabling 3 existing roots
Eddy Nigg (StartCom Ltd.) wrote: Even though the Comodo request has been approved, I wonder about two additional points which you haven't addressed at all: The first is about having CA roots with wrong details in NSS, like companies which effectively don't exist anymore (AddTrust AB, UTN), location (Sweden, Utah) and other information irrelevant and incorrect. To the extent that this information is in the certificates themselves, we can't change it. I guess we could look at changing the friendly names which NSS uses to refer to the certs, but that might be confusing for people who actually look at the root list in the various versions of Firefox. I think there's also an issue with how the certs get displayed in the Firefox certificate manager display window, based on what the cert contents are; I recall a comment from Kai (I think) about this in a bug I looked at recently, but can't recall the bug number or what the exact issue was. The second is about the audit statements which refer to a specific part and location of the CA business, like New Jersey. I didn't think this was a material issue with respect to Comodo's overall compliance with the EV guidelines, and so left it out of my considerations. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
