Nelson B Bolyard: >> This particular part DOES bother you, because wild card certificates >> aren't controllable in the same way as regular ones. A seemingly >> innocent domain name can become a tool for phishing. For example >> *.domain.com matches paypal.domain.com and paypal-objects.domain.com, >> something a CA can not control in these circumstances (you can't assume >> that a CA can adequately control wild card certificates as you mention >> above). >> > > You say a CA can control this, but what can or should a CA do, and with > what authority? > The CAs should prevent issuance of certificates which are suspected to be used for phishing attempts and other fraud. This includes cases like real domain names (mic0s0ft.com, paypa1.com) and sub domain names (paypal.nelson.com). The CA can do this with the same authority it can refuse issuance of certificates for other reasons and/or according to their policies.
Additionally CAs can visit suspected sites before and after issuance of a certificate. They can do background research and request additional documents (Yes, also for DV certs if needed). There are many more options and tools CAs can implement and use. Obviously this can't be done with wild card certificates (in cases of sub domain names). Hence they should be higher validated. > What would you propose? That CAs disallow the issuance of certs for hosts > (or sub-domains) whose host name matches the name found in any TLD in the > .com domain? > Huuuu? Can you explain that? > Would you have all CAs refuse me a cert for nelson.bolyard.com because > there exists a nelson.com domain? > No, did I say that? I can't see this domain above as a phishing target nor is it a wild card certificate... > Would you have all CAs refuse a cert for bugzilla.mozilla.org, because > there exists a bugzilla.com? > No, I never said that. > What if the subdomain/host name existed, with a certificate first > (as is likely the case for bugzilla.com, I think)? > Would you have CAs refuse to issue certs for bugzilla.com because a CA > had already issued a cert to bugzilla.mozilla.org? > How about domain registrars? Would you have them refuse to register the > domain bugzilla.com because a cert existed for bugzilla.mozilla.org? > Three times no. > The only restriction of which I'm aware on domain names that domain > registrars should register or CAs should issue has to do with international > character sets, and the ability to produce a string in another character > set that LOOKS like, but is not identical to, some already registered > .com domain name. But that only applies to registering names that visually > appear to be EXACT duplicates of other extant domains. > No, but also m0zilla.com would be such a case I guess. As would be other similar looking names. > If you would not propose to prohibit the issuance of certs for hosts whose > host names match .com TLD names, then on what other basis would you propose > to create such a prohibition? Would you have CAs refuse to issue a cert > to paypal.mozilla.org (say) on the grounds that: > > - Paypal is a big company worth lots of $$$? (What's the $$ threshold?) > - Paypal's web site gives users accounts that are password protected? > - Paypal is known to be a phishing target? (What's the metric?) > - or something else? (please elaborate). > Three times yes. There are known phishing targets such as online services as paypal, banks and other institutions. There are other tools available to CAs (and I don't have to elaborate) which help differentiate and find such cases. And I guess that many CAs implement them and on a best effort basis effectively prevent issuance of such certificates. It's the controls the CA implements for this type of certification. > Test your answer by switching the names as follows: Would you have CAs > refuse to issue a cert to bugzilla.com because bugzilla.mozilla.org is > any of the things listed above? > No. > Note that even the EV "guidelines" do not prohibit EV CAs from issuing > certs on any of the grounds suggested above.. > > I'm not sure, if I remember right EV does have a provision for above cases (like obscuring domain names.) But this is beyond the point since EV certificates ARE validated, we are talking about DV certs which aren't and issuance is performed mainly automatically. >> We reserve the right to not include a particular CA certificate in >> our software products, to discontinue including a particular CA >> certificate in our products......including cases where we >> believe.... would *cause undue risks to users security*, for >> example, with CAs that >> >> * knowingly issue certificates without the knowledge of the >> entities whose information is referenced in the certificates; /or/ >> * knowingly issue certificates that appear to be intended for >> fraudulent use. >> > > Again, what is your test for "appear to be intended for fraudulent use?" > A wild card certificate can be potentionally used for fraudulent use such a phishing. Knowingly issuing them to completely unknown identities (anonymous) is a risk CAs shouldn't take. Nor should Mozilla sign up to such a risk. But of course my interpretation is from my point of view, yours might be different. > >> Wild card certificates which are not at least identity validated may be >> intended for fraudulent use. Section 4 explicitly states also that the >> list above is not limited! Domain name validated wild card certificates >> can be a risk to users security. >> > > Certificates bind a key to a name. Period, Full stop. EV certs may say > something about the owner's right to use a name, but not even EV certs > say anything about the intent or righteousness or karma of the named > party or the named domain or host. > Correct. But they are validated. You know the name, organization, address etc which stands behind this certificate. Fraud would have a short way to court. > My point is that it is pointless to attempt to prohibit issuance of > subdomain wildcard certs on the basis of DV until you establish some > clear criteria upon which CAs can (and collectively will) rightfully > deny certs for host names to well identified subscribers (cert subjects). I did that already I think. Additionally the criteria should be that wild card certificates MUST be ID validated at least. Because this is a wild card, card blanche, joker.....it's extra power for the subscriber and extra risk for the CA and RP. Mozilla is an RP in that respect. I'd say DV validated wild card certificates are an undue risk to the users of Mozilla software (as stated in the policy). It's my argument, it's my knowledge I'm offering you, it's my experience I share with you - judge for yourself... -- 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
