On Fri, Apr 26, 2019 at 5:39 PM Wayne Thayer <wtha...@mozilla.com> wrote:
> This does not, however, address the last part of what Brian proposes - >> which is examining if, how many, and which CAs would fail to meet these >> encoding requirements today, either in their roots, subordinates, or leaf >> certificates. >> >> > While I agree that this would be useful information, for the purpose of > moving ahead with this policy change would it instead be reasonable to set > an effective date and require certificates issued (notBefore) after that > date to comply, putting the burden on CAs to verify their implementations > rather than relying on someone else to do that work? > To the extent a phase-in approach is valuable, I think such a phase-in would require that the *chains* of certificates issued after that date must comply. The concern is that if there are existing issuing intermediates that do not comply, putting a phase-in date for leaf certificates doesn't resolve any of the ambiguities or issues this proposal seeks to resolve, nor does it address the security issues that are mitigated by it. However, as CAs can always construct new issuing intermediates that do comply with this policy, that's more preferable. To be explicit here: It's not requiring that CAs would revoke their existing intermediates. Rather, that by some particular phase in date, they must have constructed new issuing intermediates (or, more generally, a new issuing hierarchy) that does comply - shifting issuing new certificates onto the new hierarchy, while no longer issuing certificates from the old hierarchy and letting the existing certificates naturally age out. However, I'd be curious if this is even needed - perhaps its something that can be revisited closer to finalizing policy, if it turns out there's no publicly detectable technical need. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
