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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.