Specifying allowed parameter encodings in Mozilla policy

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Specifying allowed parameter encodings in Mozilla policy

Gervase Markham
Brian Smith filed two issues on our Root Store Policy relating to making
specific requirements of the technical content of certificates:

"Specify allowed PSS parameters"
https://github.com/mozilla/pkipolicy/issues/37

"Specify allowed encoding of RSA PKCS#1 1.5 parameters"
https://github.com/mozilla/pkipolicy/issues/38

I am not competent to assess these suggestions and the wisdom or
otherwise of putting them into the policy. I also am not able to draft
text for them. Can the Mozilla crypto community opine on these
suggestions, and what the web compat impact might be of enforcing them?

Gerv


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Specifying allowed parameter encodings in Mozilla policy

Ryan Sleevi-5
I support both of those requirements, so that we can avoid it on a
'problematic practices' side :)

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 :)

On Fri, May 19, 2017 at 9:57 AM, Gervase Markham <[hidden email]> wrote:

> Brian Smith filed two issues on our Root Store Policy relating to making
> specific requirements of the technical content of certificates:
>
> "Specify allowed PSS parameters"
> https://github.com/mozilla/pkipolicy/issues/37
>
> "Specify allowed encoding of RSA PKCS#1 1.5 parameters"
> https://github.com/mozilla/pkipolicy/issues/38
>
> I am not competent to assess these suggestions and the wisdom or
> otherwise of putting them into the policy. I also am not able to draft
> text for them. Can the Mozilla crypto community opine on these
> suggestions, and what the web compat impact might be of enforcing them?
>
> Gerv
>
>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Specifying allowed parameter encodings in Mozilla policy

Gervase Markham
In reply to this post by Gervase Markham
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

> 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?

Gerv

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Specifying allowed parameter encodings in Mozilla policy

Ryan Sleevi-6
In reply to this post by Gervase Markham
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Specifying allowed parameter encodings in Mozilla policy

Gervase Markham
In reply to this post by Gervase Markham
On 23/05/17 14:08, [hidden email] wrote:
> I think it should be a policy

OK. Are you able to propose wording and a location within the policy
(section 5.1) for both of these proposals? If you are willing to do
that, I'm happy to include it.

Gerv
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Specifying allowed parameter encodings in Mozilla policy

Hubert Kario
In reply to this post by Gervase Markham
On Friday, 19 May 2017 15:57:18 CEST Gervase Markham wrote:
> Brian Smith filed two issues on our Root Store Policy relating to making
> specific requirements of the technical content of certificates:
>
> "Specify allowed PSS parameters"
> https://github.com/mozilla/pkipolicy/issues/37
>
> "Specify allowed encoding of RSA PKCS#1 1.5 parameters"
> https://github.com/mozilla/pkipolicy/issues/38

In general I support them, but I'm afraid that the PSS specification is not
detailed enough.

I'd say there are 3 different places that the RSA-PSS parameters can be:
 1. In the signature (certificate, CRL, S/MIME or CMS, etc.)
 2. in the public key info structure of CA certificate
 3. in the public key info structure of EE certificate

Presence of parameters in 1 is mandatory. Presence of parameters in 2 is
recommended (SHOULD in RFC 5756) and optional (MAY in RFC 5756) in 3.

Given the interactions between TLS and certificates, I'd say we should suggest
_against_ inclusion of them in 3. Thus the valid value would also be "absent".

Second possible problem stems from the fact that saltLen is differently
interpreted in signature (1) and in public key info (2, 3). In case of
signature, it's the literal value. But in case of public key info it's the
_minimum_ size of salt allowed. I don't think we gain anything from rejecting
bigger salts, they are limited by key size anyway.

To oversimplify a bit, we should be lenient for signatures made by end-user
software and strict for signatures made by CA software.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (836 bytes) Download Attachment