On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via dev-security-policy wrote: > Completely agree with you about that a new root by itself do not solve the > problem.
The phrase you're looking for is "necessary but not sufficient". That is, it is necessary to create new roots to restore trust, but not sufficient to do so. You also have to demonstrate a high degree of competence in running a CA, and understanding and responding to legitimate concerns. > The issue now is choosing the starting point. > > 1.- New root 2018 > > 2.- 2016 root, after revoke all certificates (< 100 units) and pass an > "Point in Time" BR compliant audit. (Camerfirma proposal) The problem with the 2016 roots is that there is no way to rehabilitate them to the point that they will be as worthy of trust as new, fresh roots, for several reasons. Firstly, revocation is "fail open". Not every relying party checks revocation information, and when the checks are made but they fail, it is *usually* OK to continue, so user agents do so. Revocation is the ejection seat of PKI. It's the option of last resort when everything else has gone to hell, and you can only hope it does the job. You don't build a crappy fighter aircraft whose wings fall off periodically, and then justify it by saying "oh, it's OK, it's got an ejection seat". No, you build the best 'plane you can, and you add the ejection seat as the "well, it's *slightly* better than nothing" final option. Because they hurt to use. A lot. And for various reasons they don't always work quite right. But they give you a better chance of survival than a crash. However, back to the point at hand: even if revocation were 100% reliable, there's still the possibility of incomplete enumeration of certificates. I cannot think of a way you could possibly prove that there is zero chance of there being undisclosed certificates chaining to the old roots. New roots, on the other hand, have that zero chance, because they're new, and have been under effective audited control since day zero. So, again, new roots would be more trustworthy than the old roots. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
