Hacker News new | past | comments | ask | show | jobs | submit login

You should be allowed to register a public suffix - github.io is a public suffix, but the *.github.io wildcard is a perfectly legitimate certificate. And conversely facebook.com is not a public suffix, so that rule wouldn't have helped Facebook.

I agree a public suffix should trigger more aggressive validation (as should, perhaps, the first request for a TLD that the CA has never issued for before), but I don't think a computerized rule blocking registration of public suffixes is appropriate.




The Baseline Requirements forbid issuing for Public Suffixes in what the PSL calls the "ICANN DOMAINS" section (or wildcards immediately under those suffixes). That section includes in-addr.arpa but not github.io

Now, the BRs don't specifically tell you not to validate in-addr.arpa and then issue more specific certificates, but my patience wears very thin on how much needs to be spelled out letter by letter to have CAs stop doing things that are obviously a terrible idea.

I can see how the juxtaposition was confusing. Facebook wasn't concerned about public suffix problems, they were worried by (a historically common) pattern where bad guys find that if they're able to persuade a CA to issue them with some-machine.example.com the same CA will then issue www.example.com to them because hey, they're from example.com... It so happened in the case that worried them that couldn't have happened, but they were not to know that.


Oh, I forgot about the two classes of public suffix - and yes, if the BRs categorically forbid it and it's on an intentionally-machine-parseable list, then I agree there's no excuse for allowing issuance before a software upgrade to explicitly carve out an exception.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: