Comment by huhtenberg | Hacker News Reader

Comment by huhtenberg | Hacker News Reader

I used to be in a contact with a guy who got an intermediate CA certificate, because he was friends with someone who was at the beginning of Thawte (I think, it was a while ago). He said he got it as a gift in the early '00s or late '90s and it had an expiry in 2050 (?). Yep, I too was like O_O

The PKI in its current form and application should really go. Cross-signing of a certificate by two or more independent CAs would be also a good step forward. And so would be a native support for certificate pinning in browsers. In other words, PKI should be used for bootstrapping the trust between two unacquainted parties, but it shouldn't be the only option, nor should be used as a trust provider on an on-going basis.

Consider this, if I hold a certificate for fubar.com, why am I not permitted to issue a certificate for xyz.fubar.com? Or, better yet - another certificate for fubar.com?

(edit) Also, "Enhancing digital certificate security" is such a bullshit title. Very odd to see this coming from Google. They must be very unnerved by the incident, or they are going to use it as a stepping stone to something else.

> Consider this, if I hold a certificate for fubar.com, why am I not permitted to issue a certificate for xyz.fubar.com Or, better yet - another certificate for fubar.com?

Because business model. StartSSL.com is afaik the first (only?) CA that charges solely for identity validation and then let's you create unlimited (wildcard) certificates (with the exception of EV certs).

* No ties, just a customer.

Quite. You, are, of course, free to run your own CA. I rather like my version (a custom minimal Linux virtual machine, ~ 16MB, stored on an IronKey). Built from source, reasonably tamper-proof, works offline, encrypted at rest. It's a bit of pain to remember to reset the time/date every time I boot it, but it works quite well.

Sadly you'll spend the rest of your time installing your root certificates in everything (good luck with mobile devices, I have torn my hair out in the past with Sony-Ericsson; Oh, you have to drag the specially-named-file-in exactly-the-right-encoding onto the HIDDEN node in the PC-suite-file-explorer-horror-window, of course. HOW OBVIOUS.)

Can you elaborate why you've spent the considerable time to do this? Do you habitually travel / connect to completely nefarious networks?

Much for the same reasons I run my own mail server - because I can, I learned something doing it, it gives me more control than I'd otherwise have. I also don't trust any network with plain-text credentials so TLS was a requirement for mobile email.

IronKey was something I already used, so it was natural to try and build a minimal CA that fit on it.

Given the choice I'd prefer a good VPN solution but the aforementioned pre-smartphones simply couldn't do that and SSL VPNs weren't common, so TLS was what we had. Now, that little CA primarily gets used for generating Xauth-RSA certificates for my IPSEC VPNs...

neat, thanks for the followup!

Any chance you could release a scrubbed setup or a blog post?

I'm looking at doing this and rather not have to slog through the nuances if possible. (I deal with certain on a sufficiently infrequent basis that I have to actively try to figure the steps again. One of the frustrating things of having to deal with cryptic options)

Actually, I've thought about starting a "real" CA (read: get certified etc). I'm not sure the world needs another one though.

Your experience running a homebrew setup is exactly why I think CAs will continue to exist—even if self-signed certs would be widely supported via DANE. I doubt many businesses are going to run their own CA in order to save < $1000 a year.

So did Honest Achmed, but he got shut down. https://bugzil.la/647959

The technical reason you can't issue certificates by having one for the parent domain is because the certificate system, for some reason, has no notion of restricted scope for CAs, as far as names go. So there's no way to say that a certain CA can sign for only these names - it's all or nothing.

This is not technically true. X509 contains a provision called name constraints which provides this exact feature, but since no client has ever implemented it in practice you are correct. (There are probably a few clients out there implementing and abiding by name constraints, but they are in the decided minority)

Internet Explorer, Mozilla Firefox, and Google Chrome all respect name constraints. I believe Opera does as well.

The issue is that according to RFC5280, nameConstraints MUST be marked critical, which would break all clients that don't support nameConstraints - including Apple OS X and iOS. As a result of not wanting to break these clients, no CA has practically deployed nameConstraints.

However, as is being discussed in the CA/Browser Forum AND Mozilla's security policy list (and previously, within PKIX), CAs and browsers are considering diverging from 5280, and not REQUIRING that 5280 be marked critical. ( https://groups.google.com/forum/?fromgroups#!topic/mozilla.d... for more context)

This will allow a transition period, where CAs that would otherwise NOT include nameConstraints (because it would break clients) can now safely include nameConstraints and not break the legacy or insecure clients that do not support them. Mozilla's proposed CA Certificate Inclusion Policy ( http://www.mozilla.org/projects/security/certs/policy/WorkIn... ) would REQUIRE that CAs use name constraints when issuing sub-CAs that are not audited, secured, and conformant with Mozilla's policy.

Reply on news.ycombinator.com