Eddy Nigg (StartCom Ltd.) wrote: > But back to our issue, if a compromised server issues a certificate from > within the name constraint and uses it to attack another user (by > claiming to send mail from [EMAIL PROTECTED] or setting up a fake > site for https://really.allowed-domain.com), this would be the classical > MITM vector SSL is meant to prevent.
I never claimed that compromise of a name constrained subordinate CA was of no consequence. As you note, it would allow an attacker to impersonate another server or user, similar to what would be possible if the attackers compromised the private key of that server or user. > Hence it doesn't matter really if > there is or isn't a name constraint, just the range of possible attacks > is limited. Why the "just"? I think it is significant from a policy perspective that the range of possible attacks is limited. Having a server's private key be compromised is a bad thing, and can lead to bad problems, but our policy doesn't focus on this case because the impact of a successful attack is limited to that server (at least from a PKI perspective). We simply assume that CAs have subscriber agreements in place requiring customers to protect their keys, and specifying the consequences (including cert revocation) if they don't. We don't require that (for example) CAs mandate use of hardware devices to protect EE private keys, and we don't require that CAs audit subscribers to ensure they are protecting their keys properly. My claim is simply that compromising a domain-constrained subordinate CA is an intermediate case; it is worse that compromise of an EE cert, but not as bad as compromise of an non-constrained CA, and our policy (to the extent it addresses this case) should reflect these differences. (Thus, for example, we might not impose exactly the same audit requirements as we would for other CAs.) Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
