On Monday, May 22, 2017 at 3:58:21 AM UTC-4, Gervase Markham wrote: > On 19/05/17 17:02, Ryan Sleevi wrote: > > I support both of those requirements, so that we can avoid it on a > > 'problematic practices' side :) > > But you think this should be a policy requirement, not a Problematic > Practice? > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
I think it should be a policy, but there's an amount of legacy existing certificates that constitutes a 'problematic practice' > > > There's a webcompat aspect for deprecation - but requiring RFC-compliant > > encoding (PKCS#1 v1.5) or 'not stupid' encoding (PSS) is a good thing for > > the Web :) > > Sure. I guess I'm hoping an NSS engineer or someone else can tell us how > we can measure the webcompat impact. Does it require scanning a big > corpus of certs? I think you misunderstood. If you were to remove support within NSS, there would be a webcompat issue. That part can be noticed by CT. However, you can conditionally 'gate' support on other factors (e.g. policy control within mozilla::pkix, much like SHA-1, that attempts to verify the 'right' way, falls back to the 'accept stupidity' way, and then fail if stupidity is encountered in a cert with a notBefore > some deprecation date). That would avoid the immediate webcompat issue, and in O(# of years w/ last stupid cert), remove the fallback path entirely. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
