3 ms·

You're right, it's a ridiculously large organizational overhead. Not to mention the CA's become single-point-of-compromise for the whole PKI. Even after 10 yea

by count 13y ago

You're right, it's a ridiculously large organizational overhead. Not to mention the CA's become single-point-of-compromise for the whole PKI. Even after 10 years or so of the CAC, the DoD process is still not pain-free. They've finally moved to OCSP instead of CRLs, which helps (the CRL is so large now that it will bluescreen Windows on import to the registry, haha) some of the pain. Even the DoD doesn't roll it's own cards and foundry stuff: they're standard Gemalto (and a few other provider) cards. You can order blanks yourself, I believe. It's also a black art - VERY very few people seem to know how to 'boostrap' the system (enable PKI for a domain or web server, get new certs issued, etc.) even within the over-archign framework. That said,my point still stands: millions of people (literally) use PKI for client SSL certs daily.

dredmorbius 13y ago
the CA's become single-point-of-compromise for the whole PKI. It's a bit more nuanced than that. A compromised CA can issue new certs which can spoof old one's identity, but it can't be used to create certs which will read traffic from an existing host. The big risk is that someone is subject to a MITM attack, doesn't clue in on the certificate change (their client should note this), and accepts the new key. Signed / validated keys (used for major sites in some browsers) also help this somewhat. Not that SSL/TLS isn't a huge mess.
- count 13y ago
  A compromised CA in a client cert PKI world, like the DOD one I was talking about, is effectively an end-game scenario. Every machine in the org. would have to be updated (root CA's don't have CRLs, afaik). The big risk isn't a mitm attack - that's a risk with traditional server-side certs. The big risk is that all of a sudden there are unlimited legitimate users with no control over identities anymore. It's like getting write access to /etc/passwd.
  - dredmorbius 13y ago
    Doesn't that depend on how you authorize the client certs themselves? It's one thing to _issue_ a cert. It's another to _approve_ that issued cert. If you're blindly accepting certs, you've got other issues.

by count 13y ago

dredmorbius 13y ago

the CA's become single-point-of-compromise for the whole PKI. It's a bit more nuanced than that. A compromised CA can issue new certs which can spoof old one's identity, but it can't be used to create certs which will read traffic from an existing host. The big risk is that someone is subject to a MITM attack, doesn't clue in on the certificate change (their client should note this), and accepts the new key. Signed / validated keys (used for major sites in some browsers) also help this somewhat. Not that SSL/TLS isn't a huge mess.

count 13y ago
A compromised CA in a client cert PKI world, like the DOD one I was talking about, is effectively an end-game scenario. Every machine in the org. would have to be updated (root CA's don't have CRLs, afaik). The big risk isn't a mitm attack - that's a risk with traditional server-side certs. The big risk is that all of a sudden there are unlimited legitimate users with no control over identities anymore. It's like getting write access to /etc/passwd.
- dredmorbius 13y ago
  Doesn't that depend on how you authorize the client certs themselves? It's one thing to _issue_ a cert. It's another to _approve_ that issued cert. If you're blindly accepting certs, you've got other issues.