On 07/02/2017 08:11, Tom wrote:
> Le 07/02/2017 à 05:01, Patrick Figel a écrit :
>> On 27/01/2017 19:53, Ryan Sleevi wrote:
>>> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham 
>>> <g...@mozilla.org>
> wrote:
>>>> 
>>>> * RSA keys with a minimum modulus size of 2048 bits
>>>> 
>>> 
>>> Nits and niggles: Perhaps 2048, 3072, 4096?
>>> 
>>> - 8K RSA keys cause Web PKI interop problems - RSA keys that 
>>> aren't modulo 8 create interop problems
>> 
>> It looks like a number of CAs currently accept RSA keys with 
>> modulus sizes != (2048, 3072, 4096). Censys currently finds 21,150
>> EE certs[1]. Does it make more sense to explicitly add the mod 8 
>> requirement to the policy in this case, while allowing anything >=
>> 2048 <= 4096?
>> 
>> [1]:
>> 
> https://censys.io/certificates?q=current_valid_nss%3A+true+and+parsed.subject_key_info.key_algorithm.name%3A+RSA+not+parsed.subject_key_info.rsa_public_key.length%3A+%282048+or+3092+or+4096%29&page=1
>> 
> 
> Why the 4096 limit?
> 
> https://rsa8192.badssl.com/ work well, and if somebody wish a 
> certificate with that size of key (or even bigger), why refusing it?
> 
> ECC certificates are allowed but cause a lot of PKI interop problems 
> too. That's not a reason for refusing it.

It's not quite the same thing - web servers can detect ECC support
through the signature_algorithms TLS client hello extension and fall
back to a RSA cert if needed. Clients don't announce the maximum key
size they support that way, so that wouldn't be possible (some fancy
client hello fingerprinting to detect the client/UA might work, but that
would be rather complex).

There are about 2k RSA certs with a key size > 4096 out there (and < 100
with > 8192). I don't personally see the need for > 4096, but don't feel
very strongly about that, so if most of the ecosystem does indeed
support 8192, I'd be fine with that limit too.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to