[cabfpub] Ballot 144 -.onion domains

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Fri Feb 13 02:33:12 UTC 2015


Gerv, you made an interesting point below in response to my message:



[Kirk] If Facebook can reverse engineer to get that .onion domain, couldn’t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain?



[Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure".



However, generating a second one which exactly matched the name Facebook picked is a much harder process.



Fair enough.  But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are “facebook”, I’m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft).  After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done.



Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts.  I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name – gervmarkham1 for example).



Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field:


The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2.



Of course, the OU field is not very important because it’s almost never visible to users.



In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion.  Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified?  Or better yet, not allow .onion domains to be meaningful (require them to be random only)?

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150213/92052f29/attachment-0003.html>


More information about the Public mailing list