On Thu, May 22, 2014 at 1:21 PM, Stephen Kent <[email protected]> wrote: > PKIX, per se, does not have the trust problems that seem to motivate > CT; the Web PKI does. That PKI has always had a serious problem because > any TA can issue a cert for any Subject, irrespective of the Subject name. > because DNSSEC intrinsically incorporate the equivalent of PKIX Name > Constraints, it does not suffer from that specific problem. That's not to > say that mis-issuance is not possible in DNSSEC, but rather that its > effects are more limited.
On the contrary, it has a rather more severe problem in that the names can be reassigned by the upstream zone. Depending on your application, this might not matter. But if you want to try hooking an enterprise PKI off a DNSSEC system then this matters a great deal. I am sure that Google would not want to find that VeriSign could direct their infrastructure to change configuration by issuing a fraudulent DNSSEC signed zone. Come to that, that particular sort of compromise is the type of thing that we spent a lot of time and effort trying to put out of reach when I worked at VRSN. I don't want to have someone's private key because I don't want to be accused of losing it. Don't think of CT in this case being something to solve a problem faced by DNSSEC users, instead think of it as something that enables use for problems where it is otherwise unsuited. The other major advantage is that it provides a tool to avoid some of the cryptographic lock in problems that are causing certain countries to cause issues in ICANN. You don't have to agree with their analysis to find value in addressing the concerns. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
