On 18 October 2016 at 08:00, Jakob Bohm <[email protected]> wrote: > On 18/10/2016 14:35, Gervase Markham wrote: >> >> On 17/10/16 16:35, Jakob Bohm wrote: >>> >>> In the not so distant past, the Mozilla root program was much more >>> useful due to different behavior: >>> >>> 1. Mozilla managed the root program based on an assumption that relying >>> parties would use the common standard revocation checking methods >>> *only* (regular CRLs as present since Netscape created SSL and OCSP). >> >> >> Now is not the time to re-debate the failings of those methods, but >> please don't pretend you don't know why this change was made. >> > > I wasn't in this instance, simply noting the following problem: By > assuming all relying parties run code that implements Mozilla's other > revocation methods (OneCRL, custom notBefore checks etc.), the root > list published by Mozilla becomes less useful for relying parties whose > applications do not.
I'm sympathetic to this - it's unfortunate that we've had to bolt on certificate validation checks that do not appear in any standardized form, in any central location, and differ from client to client. It makes 'the most dangerous code in the world' even harder to get correct. It seems like more and more of CA/HTTPS related ecosystem could benefit from an equivalent to caniuse.com But I'm not sure what Mozilla could do to help downstream users of the root store? What would make you happier? Projects who blindly import and trust it will be subject to the default decision Mozilla takes - sure. (And hopefully they have the prescience to delineate between default-trust certs and default-don't-trust certs!) Two things I can see would be: - Carefully choose the action taken with the root store to be a 'keep in the root store' choice or a 'remove from the root store' choice. For example, WoSign would probably be in the 'remove' category and then FF gets special processing code to accept WoSign under specific circumstances. - Have some additional comments or tooling that are designed for downstream importers. Maybe a script that runs over the official file converting it to other frmats (Java keystore, directory-of-certs, etc) and prompts people 'This CA is subject to specific filtering in FF, do you want to include it in the export?' Are there other actionable things Mozilla could do to make things better-by-default for downstream users? -tom _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
