Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Depending on the certificate, this could be quite a lot of data, the certificate is delivered on every new connection, right now they're commonly a kilobyte or so of data.

For a typical DV certificate, maybe the CA has done 3.2.2.4.6, so they have a log showing the DNS look-up they did from first principles (so it's the whole thing from the root, not just a cached single entry), then the HTTP transaction, with the Request Token inside it, and they've matched the Request Token against the expected value. That could easily be several kilobytes. The CA is required to store this, but burning it into the certificate is extra data all so that what, one person in a million can look at it, and go "Eh, that looks roughly like I'd expect" ?

For an EV certificate there's going to be stuff they found in a government data source, then the stuff from Dun & Bradstreet, then... what maybe a WAV file of a phone call to the number listed in D&B? PDF scans of headed notepaper? And it tells you... somebody, somewhere said this was fine. So what?

As I've stated on m.d.s.policy the ability to make companies in the US and UK that can't be traced back to their real owners without a heroic effort by law enforcement is not a bug it's a feature. Your government (if you live in the UK, the US, or even arguably the EU) tacitly supports the dirty business done by this route so long as they're able to disclaim any knowledge it's going on.



You can send it through a secondary query, not in the initial cert, so only if the user looks it up. It should be a supported possibility though. As for what you get out of it, that's okay, have it match meatspace level first, not trying to fix the world.




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

Search: