Let me repeat my other argument: Users don't use domain names in trust assessments.

I strongly disagree with this and other arguments that it's just "bad PR". I think we're off in theory-land. There are 2 critical requirements on the end-user side that make SSL work. Whether we like it or not, both require some level of intelligence: 1) Users can't ignore browser certificate warnings (i.e. look for the padlock) 2) Users have to eyeball the URL to ensure they're at the official web company site. 2a) Users have to know what the official company URL is in the first place. You may not like the existence of the above 2 rules, and we can argue about how often people pay attention to them, how feasible they are, but they are nonetheless a reality. Even the savviest of IT people can only click on the padlock, verify the cert is signed by a root authority (which it would be), check that the domain matches (it would), and hope it's secure -- this isn't just a "dumb user" issue. None of "us" could tell the difference if homographs were in place (unless you expect every application/developer to be as smart as Mozilla is). So, if you allow homographs, you have to add another rule to the chain: 3) All URLs for trusted sites must be hand-typed in the browser. All links to SSL sites are never to be trusted. You can make the case that this should be done, is acceptable, you don't mind it, etc., but it's clearly an additional link in the security architecture that wasn't previously necessary and, therefore, not just a bunch of random PR. Users are already the weak link; counting on them for yet another thing just doesn't ring true as a good idea. Bottom line: This is a real issue that reduces the *practical* security of SSL, which is why there's an IAB group dedicated to it. Counterpoints: - "But users might think 'ebay.com' and 'ebay-security.com' are the same thing." That's unrelated; it's a given that you have to know what the company URL is in the first place. There's no avoiding that existing requirement (see 2a above). - "There are lots of other browser hacks out there." So what? That doesn't justify approving a new global DNS standard that permits yet another security hole in SSL/PKI. We should be working to avoid security risks, not approving them in RFCs. - "Only the TLDs are protected." That's already the case with the way cert's are issued (e.g. you can go register "ebay.stealyourcreditcard.cx" and get a cert) ... old news. Todd Vierling's page is a great example: http://www.duh.org/homographs.cgi ... and I'm going to go join the IAB-IDN mailing list: http://lists.paf.se/cgi/listinfo/iab-idn -Jason -- Jason Sloderbeck Positive Networks jason@positivenetworks.net