On 04/12/2011 02:58 AM, Gervase Markham wrote:
On 09/04/11 18:05, Adam Barth wrote:
In addition to thinking about orderly transitions to new certificates
(as you mention), there's also the case of disorderly transitions.
For example, what happens if the site's private key gets compromised
and it wishes to move to a new certificate before it planned.
This is why it seems to me that certificate attribute locking, as
opposed to particular certificate locking, has to be the way to go.
The entire point of PKI, as opposed to models like SSH/TOFU, is that
it's not the particular certificate which matters, but the chain to the
point of trust. The aim of "locking" is to segment the trust landscape
so that a site can say "do not trust all X hundred CAs for my site,
trust only this one, or these two". They can then insulate themselves
from the possibility of a compromise elsewhere.
Counterpoint: If the attacker is (or colludes with) a rogue CA, they are
in a position to make the *entire contents* of the certificate be
whatever they want. They can forge EV status, they can forge the O=,
they can forge the serial number, they can make it appear to be exactly
the same as the legitimate certificate they're spoofing. If the rogue
CA is the *same* as the CA that signed the legitimate certificate (which
is a real possibility in "the attacker is a nation-state" scenarios)
they can even make the signing key match.
The only thing that *can't* match the legitimate certificate is the
public key itself, because the attacker doesn't get anything for their
trouble if they don't change the keypair.
Therefore, I don't see attribute locking as providing any real security
benefits. Pubkey locking (or, equivalently, cert locking), on the other
hand, *does*, and CA locking also helps if you don't have to worry about
*your* CA being suborned (which should be the common case even with
state surveillance expanding as fast as it is).
Worries about disorderly transitions, needing to change CAs, etc., seem
to me to be adequately addressed by short-lived records in DNS - it's
not any worse than needing to change IP addresses, anyway.
zw
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
