Frank Hecker: > > 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. > Your list is correct and Robin Alden has addressed all issues which were raised. I intend to reply to each in a summarized form. > 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. Pardon me? > 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. > We require that certificates are at least domain validated, meaning that a check is performed to guaranty to a reasonable extend, that only the owner (or from the owner assigned person) can request a certificate for a specific domain name. This in order to prevent a MITM attack and eavesdropping. Mozilla requires that, in order to let users of its software securely rely on it for the intended purpose. One could describe this to be the mission of the Mozilla CA policy and the work we are doing here.
Back to our issue about very-long-lived certificates: One can purchase a popular or less popular domain name, request a certificate for N years, let the domain name expire after one year, wait to have it picked up by somebody else. Now, this site can be spoofed at will and a MITM is possible (the very same thing Mozilla tries to prevent in first place). But let me give you a real-world example, first hand... Please visit http://toolbar.netcraft.com/site_report?url=http://www.startssl.com and find that this domain name belonged to somebody in Korea some four years ago or less. Just the thought about somebody in Korea having a certificate still valid for one of our major domain names makes me shiver. This person could effectively spoof our web site. This is NOT funny! This is a risk to a big number of users trusting us and Mozilla! > 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. It is reasonable to assume that domain names have a period after expiration when they aren't sold, but held up for the original owner to be extended. It is also reasonable to believe, that even should a certificate have been issued at some time, it will expire within a reasonable amount of time. One can reasonable assume, that after the passing of some time, no legitimate certificates does exist in the wrong hands. > 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. Absolutely. This is exactly the case! > 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. > First of all, the first part of this sentence is completely irrelevant, because the current domain name owner and eventual visitors to that site are at risk and not the person which previously held that domain name (and also still holds a certificate). Second, should the CA become aware of it (which I highly doubt in our case), that would be faaaar tooo late. Under certain circumstances, this could go on undetected for a long time, if at all! Now I suggest you evaluate this situation once again! I'm not saying one year is the limit (so it should be the suggested best practice), but because domain validated certificates are already the lowest possible validation level and with it are bearing the highest risk in every respect, we shouldn't allow anything beyond two years or so. Certainly nothing higher than 3 years. > > 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. Agreed. > 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). I think this to be reasonable and responsible in every respect. Considering that wild card certificates are most of the time also sold for a much higher fee compared to regular certificates, this is a service CAs should perform. Generally I'm against having the "money" argument involved at all when considering a criteria for the issuance of certificates, but I suppose that the CAs in question really can afford to perform a higher validation and also provide some value for their certificate. Hey, we'll be helping them to have a better product - and obviously this would have to be applied evenly onto all CAs. > (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.) > And I'm completely in agreement with this what regular DV certs concerns! > 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. > I agree with the later part, but I request from you once again to try to see the difference between having issued a legitimate domain validated certificate to paypal-tips.hecker.org (and this after the CA has made some extra checks with Mr. Hecker, because this is the responsibility the CA has taken upon itself by issuing this type of certificates, even with the risk of loosing its profit on this specific certificate, because the security of the relying parties is simply more important, something a CA should be interested foremost in first place) and a domain validated wild card certificate which can be used for paypal.hecker.org, in which case the CA doesn't know for which sub domain name the certificate will be used. How different however if the CA validated Mr. Hecker before issuing his wild card certificate. We all will sleep much better because of that. > 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; Frank, now I'm having crocodile-sized tears rolling down my cheeks :'( First of all, they are sold usually anyway for a much higher amount, second this argument is completely irrelevant to the users security which is at risk here. > 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. It depends! Find a CA which issues them cheaper then...Wild card certificates are usually more expensive then IV validated certificates, but this is not the point here at all...find the best deal for the value the CA gives you, simple as that. Mozilla doesn't have any financial responsibilities neither with CAs not with subscribers. It has a responsibility for its users. > 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; > Yes? But certificates valid for ten years are not? Unrelated to that, the next release of Firefox does counter this behavior effectively, which in itself is Mozilla's share of lowering that risk. Incidentally I feel in this discussion, that this team is effectively undermining the efforts others are making in improving security in relation to certificates. What a joke, to make it almost impossible for users to circumvent any type of SSL errors (which includes invalid sub domains, etc) and allowing domain validated wild card certificates with a validity of up to ten years issued by one of the major CAs. Common! The two simply don't go together! This is completely counterproductive and apparently we haven't seen the wind of change yet.... > 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). Of course, updating the Mozilla CA policy is a tool in our hand, should we agree this to be useful, not including a CA could be another. But we could help them address this and other issues in a joint effort. > > 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. Why should you? You should encourage it... > 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. > Because you and I believe that domain validated certificates do have a legitimate place in this landscape, we should also take care, that they remain effective as possible. The negative impact of misuse of this type of certification will be the end of DV certificates altogether. This is what I care about the same as I care about the relying parties. DV certs are very useful for the intended purpose. Wild card certificates however shouldn't be part of it. Neither should certificates with a validity of ten years and this includes ANY type of certificate (DV/IV/OV/EV)! Specially the later would be a serious blow to Mozilla's standing on security and its responsibilities for its users! -- 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
