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

Reply via email to