Eddy Nigg (StartCom Ltd.) wrote: > I suggest the following at this stage: > > Adding an entry at the bug that > - requests officially a statement and answering of the issues which have > been raised [3];
As far as I can tell, here are the most recent questions you've raised (first four in a message dated March 16, the last one in a message dated March 18): 1. Questions re a) location(s) of Comodo operations, b) corporate relationship of LiteSSL to Comodo, b) corporate relationship of AddTrust AB to Comodo. 2. Question re wildcard SSL certificates issued when only domain validation is done. 3. Question re what happens for certificates with long lifetimes when the certificate holder goes out of business, changes name, etc. 4. Question to me re the scope of the review of the application to upgrade existing Comodo roots for EV. 5. Question re verification procedures for code signing certificates (section 4.2.1 and 4.2.8, as referenced by section 2.4.3 of the 3.0 Comodo CPS). > - request to actively address the issues which are deemed to be a risk > for Mozilla and its users after receiving their answers and after > evaluating them; Robin Alden has already responded to questions 1.a, 1.b, and 1.c. I don't see any outstanding issues relating to these questions. Question 2 (wildcard SSL DV certs) I comment on below. I'm not exactly sure how question 3 (relating to long-lived certs) is relevant. Presumably the concern is either a) that someone else (i.e., other than the original cert holder) could (re)use certs and domains abandoned by their owners, or b) for renamed businesses, any organizational info in the cert is no longer true, or c) just a general concern that it's bad practice to have valid certs for no longer valid businesses and/or domains. From my point of view, renaming of a business, termination of a business, having a domain name expire, are all things that could happen whether the cert lifetime is one year or longer. Our policy doesn't contain any prohibition against cert lifetimes longer than a year, so the only way our policy is relevant to this question is if we want to judge longer-lived certs as a security risk in general. But as a security risk this seems to be addressed already by subscribers' obligation (under subscriber agreements) to protect their own private keys, and CAs' ability to revoke certs if they become aware of any problems. Question 4 was a question to me, not Comodo, and I've already answered it. Question 5 (code signing verification) is outstanding. I haven't yet had a chance to review the CPS language in detail, so I won't comment on it further here. Now back to question 2 (wildcard DV certs): As I've previously noted, our policy is silent on the subject of wildcard certs (DV or otherwise), so any application of our policy to the question has to fall back on general concerns about security. For these general security concerns to be relevant, I think the security risks associated with wildcard DV certs have to be great enough to outweigh the impact on legitimate uses of any proposed ban on wildcard DV certs (i.e., requiring subscribers to prove identity before getting a wildcard cert). (This basically replicates the previous discussions on whether to allow DV certs or not; in the end we decided that legitimate uses of DV certs outweighed the potential risks.) I don't think this case has been made. Certainly there are legitimate uses for wildcard DV certs: Just as regular DV certs can be used to secure non-ecommerce transactions for personal or small group sites (e.g., www.hecker.org), wildcard DV certs could be used for cases where individuals or small groups want to SSL-enable multiple subdomains under their domains (e.g., smtp.hecker.org, imap.hecker.org) without having to pay for individual certs for each subdomain. There are even legitimate uses for SSL-enabled subdomains that reference names of other businesses, for example paypal-tips.hecker.org or paypal-team.hecker.org; the former might be a third-party help site maintained as a wiki with SSL-protected authentication, the latter a collaboration site for a small business that's a vendor to PayPal. If we mandate that CAs issuing wildcard SSL certs must verify the identity of cert holders (beyond just verifying domain ownership/control), then in essence we're imposing a financial burden on all such legitimate uses of wildcard certs; IV/OV/EV certs are significantly more expensive than DV certs, and buying individual DV certs for each subdoman is significantly more expensive than buying a wildcard cert for the whole domain. And to the extent that imposing such burden causes people not to SSL-enable their subdomain sites at all, such a mandate also raises security risks; for example, people using such sites over public wifi networks will have increased risks of others sniffing passwords and other sensitive data. Is this negative impact on legitimate uses justified by the actual security threat of wildcard DV certs? To my knowledge nobody in this discussion has thus far presented any actual evidence that issuance of wildcard DV certs has led to significant levels of fraud or other security problems. For that matter, I'm not aware of any evidence that issuance of DV certs in general has led to significant levels of fraud or other problems; so from my point of view regular DV certs and wildcard DV certs are roughly equivalent in this regard. In the absence of any such evidence we're left with hypothetical scenarios that such and such bad things might happen (e.g., setting up phishing sites at paypal.foo.com, ebay.foo.com, etc.), and calls for CAs to take pre-emptive actions to prevent such hypothetical bad things. Based on the arguments presented thus far, I just don't believe that the security risk of wildcard DV certs justifies the impact on legitimate uses of banning wildcard DV certs entirely (or, more correctly, not including roots for CAs that issue them). To the extent that problems do occur, there are existing procedures like cert revocation that can help address them. To echo Bruce Scheier, we don't want to focus over much on prevention when detection and response may be adequate to address the actual risk. I understand the desire to see CAs take more proactive actions, like doing automated checks on domain names submitted for DV cert applications. And if such checks have a minimal impact on legitimate uses I have no problem at all with CAs doing them. However I do have a problem with mandating CA checks (including identity checks) and other actions that have a non-trivial impact just because they're claimed to be "good practice". DV certs (wildcard or otherwise) are what they are; their purpose is not to facilitate ecommerce or inspire trust in end users. If we want to promote ecommerce and help end users then we already have a vehicle by which to do that, namely EV certs and their associated browser UI (a UI that's deliberately different than tradition UI used for DV/IV/OV certs). I don't see a compelling need to introduce elements of identity verification into the DV cert arena, for wildcard certs or otherwise. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
