Hi, > Any model that offers a security feature to a trivially tiny minority, > to the expense of the dominant majority, is daft. The logical > conclusion of 1.5 decades worth of experience with centralised root > lists is that we, in the aggregate, may as well trust Microsoft and the > other root vendors' root list entirely. > > Or: find another model. Change the assumptions. Re-do the security > engineering.
You have avoided the wording "find a better model" - intentionally so? Because such work would only be meaningful if we could show we have achieved an improvement by doing it. Which brings us to the next point: how do we measure improvement? What we would need - and don't have, and likely won't have for another long while - are numbers that are statistically meaningful. On moz.dev.sec.policy, the proposal is out that CAs need to publicly disclose security incidents and breaches. This could actually be a good step forward. If the numbers show that incidents are far more frequent than generally assumed, this would get us away from the "low frequency, high impact" scenario that we all currently seem to assume, and which is so hard to analyse. If the numbers show that incidents are very rare - fine, too. Then the current model is maybe not too bad (apart from the fact that one foul apple will still spoil everything, and government interference will still likely remain undetected). The problem is that CAs object to disclosure on the simple grounds that public disclosure hurts them. Even Startcom, otherwise aiming to present a clean vest, has not disclosed yet what happened on June, 15th this year. Mozilla seems to take the stance that incidents should, at most, be disclosed to Mozilla, not the general public. While understandable from Moz's point of view - you don't want to hurt the CAs too badly if you are a vendor - it still means researchers won't get the numbers they need. And the circle closes - no numbers, no facts, no improvements, other than those subjectively perceived. Ralph
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
