Hacker News Reader

Comment by bcoates | Hacker News Reader

Wouldn't it make sense to lower the exposure by having the server only have access to its own ephemeral private key?

So instead of having the key to the hard to change site certificate on many vulnerable front-line servers, it rolls up a key and on boot sends a certificate signing request to a hardened internal system?

View on HN

This would be ideal. One of the problems with heartbleed has been that while you can revoke your cert and mint a new one, browsers don't check CRLs so they'll continue to trust the old compromised cert.

However, I don't think X.509 supports the concept of CA certs being limited to signing only subdomains (could be wrong), and you have a large industry that prefers the status quo of you having to pay them for each cert you mint.

This ends up with ridiculous things like tying payment to the lifetime of the certificate, which allows for things like "2 year certs", which are obviously less secure than 2×1 year certs.

But having your server roll it's cert every 12 hours from a more secure cert elsewhere would be a very nice feature.

It would have to be time based, not boot based, unless you want to do key revocation for all the previous at-boot-time generated keys. But yeah, if you rotated keys once an hour or once a day, then if they got leaked the window for MITMing your customers would only be that long.

This is feasible in the current X509 public CA system, thanks to name and path length constraints. However, I don't know of any CAs which will issue restricted suitable certs for any sensible amount of money.

I'm very confused why the X.509 model isn't already set up to accommodate this. Imagine that a CA could only sign CSRs for subjects hierarchically-below its own subject. Then:

• Instead of issuing plain leaf-node certs, CAs could (and would) issue CA-certs by default.

• You'd be able to issue as many plain certs as you like, using your own CA-cert, and revoke them as often as you like. (OCSP would be much more necessary here.)

• The current CAs would be renamed to "global CAs": their power would come from the fact that they have no subject (or their subject is '.') in their CA-certs.

• Anyone owning a domain would become the CA for its own subdomains. (foo.tumblr.com would be signed by Tumblr's CA; foo.s3.amazonaws.com would be signed by the Amazon AWS CA; etc.)

Probably because there's a small market for that? I've met technical people that don't even make their CSRs, they actually have their CA generate private+public keypair so they don't have to figure it out.

Also, CAs make more money if they can issue each leaf cert themselves. Some CAs don't even allow you to get multiple private keys signed (only one active at a time) without paying more.

Because your browser doesnt know the chain, yourdomain.com could sign google.com and browser will accept it as is today.

For your proposal to work the CA system would have to check with dnssec and probably another protocol to enforce the subca signs only its domain constraint.

I think the change would simply require servers to always send a certificate chain (up to at least the cert's most-proximate global-issuer CA) instead of just a cert. Which is pretty much what every web-scale site does already, to short-circuit OSCP lookups on intermediate CAs.

DNSSEC needn't be involved; you aren't determining whether the CA owns the domain it's issuing certs for at runtime. Instead, the parent-CA who issued the CA's signing cert determined that when they issued the cert. As long as each certificate in the sent chain both 1. checks out as signed by its parent, and 2. has a subject hierarchically below its parent's subject, you can be sure each CA in the chain did whatever it considers diligence before issuing certs to its child-CAs.

Reply on news.ycombinator.com