El miércoles, 4 de abril de 2018, 4:10:16 (UTC+2), Matt Palmer escribió: > 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
Thanks for your comments Matt Regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
