KeySize - was DRAFT CA Communication, Feb 2012

[Robin Alden]

> > 4) Certificates chaining to root certificates in Mozilla’s root
> > program should not have 512-bit keys or MD5 algorithms.
>
> Eddy Nigg:
> Didn't you meant to say 1024bit? Shouldn't the required minimum
> supposed to be 2048 bit these days?
>

Hi Eddy,
I agree that this point warrants further examination, but I disagree with your implied suggestion for the immediate revocation of end entity certificates with 1024 bit keys.

a) Looking at Kathleen's wording, 'should not have 512 bit keys' would allow a 513 bit key. I think that's too small.

The suggestion from Opera to the CAB Forum back in November was that we should make sure any issued certificates with keys shorter than 1000 bits (and **definitely** those shorter than 700 bits) are revoked.
We have been led to believe that, in the near term, Microsoft IE will give a visible warning for (or will refuse to connect to) sites with otherwise trusted certificates with keys smaller than 1024-bit RSA.

Looking at real-world key sizes, I would say the real crunch point is whether you think 768 bit keys are strong enough to remain unrevoked in the short term. Either 768 is enough, in which case that becomes the minimum that may remain unrevoked, or 768 is not enough in which case the minimum needs to be a value of at least 1000.


b) Considering certificates with 1024 bit RSA keys, Microsoft's 'Windows Root Certificate Program - Technical Requirements' (at http://social.technet.microsoft.com/wiki/contents/articles/1760.aspx) says (among other things):
"Issued 1024-bit RSA intermediate and end-entity certificates must expire by December 31, 2013"

The CAB Forum baseline requirements says the same thing in Appendix A.

If Mozilla were (at your suggestion) to request the immediate revocation of SSL certificates with 1024 bit RSA keys (or in any case before 31-Dec-2013) I think it would result in the revocation of certificates for a lot of active sites.
If there is evidence of significant compromise or weakness of 1024 bit RSA then that might be a reasonable thing to do, but otherwise it would be rather extreme.

Regards
Robin Alden
Comodo

[Brian Smith]

Robin Alden wrote:
> The suggestion from Opera to the CAB Forum back in November was that
> we should make sure any issued certificates with keys shorter than
> 1000 bits (and **definitely** those shorter than 700 bits) are
> revoked.
> We have been led to believe that, in the near term, Microsoft IE will
> give a visible warning for (or will refuse to connect to) sites with
> otherwise trusted certificates with keys smaller than 1024-bit RSA.
>
> Looking at real-world key sizes, I would say the real crunch point is
> whether you think 768 bit keys are strong enough to remain unrevoked
> in the short term. Either 768 is enough, in which case that becomes
> the minimum that may remain unrevoked, or 768 is not enough in which
> case the minimum needs to be a value of at least 1000.

There are already successful factorings of RSA-768, so the limit can't be RSA-768 or below.

If Microsoft is going to set their limit at 1024 and we're planning to set our limit in Firefox at 1024 then I think that it makes sense to have the policy set the limit for revocation to 1024. In fact, I doubt we will set the limit at exactly 1024 bits; we should instead set the the limit at 1024/8 = 128 bytes, allowing the 7 most significant bits to be zero (so effectively, 1017 bits).

- Brian

[Ryan Sleevi]

For Chromium, the limit has been set at < 1024 bits, and will generate a
fatal error for keys below this size. This is scheduled to ship in Chrome
19 [1][2].

However, note that the CA/Browser Forum's Baseline Requirements, v1.0,
Appendix A [3] states 2048 as the minimum keysize for subscriber
certificates whose expiration after 31 December 2013. so this minimum
requirement may be tightened over time.


[1] http://code.google.com/p/chromium/issues/detail?id=102949
[2] http://src.chromium.org/viewvc/chrome?view=rev&revision=114709
[3] http://cabforum.org/Baseline_Requirements_V1.pdf

[Kathleen Wilson]

http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

"8. We consider the following algorithms and key sizes to be acceptable
and supported in Mozilla products:
- SHA-1 (until a practical collision attack against SHA-1 certificates
is imminent);
- SHA-256, SHA-384, SHA-512;
- Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
SECG and NIST named curves P-256, P-384, and P-512;
- RSA 2048 bits or higher; and
- RSA 1024 bits (only until December 31, 2013)."


Does this need to be updated?

Kathleen

[Brian Smith]

Kathleen Wilson wrote:
> http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
>
> "8. We consider the following algorithms and key sizes to be
> acceptable and supported in Mozilla products:
> - SHA-1 (until a practical collision attack against SHA-1
> certificates is imminent);
> - SHA-256, SHA-384, SHA-512;
> - Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
> SECG and NIST named curves P-256, P-384, and P-512;
> - RSA 2048 bits or higher; and
> - RSA 1024 bits (only until December 31, 2013)."
>
> Does this need to be updated?

I don't think so. There was a previous discussion on this mailing list about this.

Is $0,123,456 a 7-figure salary? Kind of, but not really, right? A similar, but less obvious, issue happens when you try to determine whether something is a 1024-bit number or a 1023-bit number; some tools (e.g. OpenSSL) will report a number as having 1023 bits whereas our tools might count it as having a 1024 bits, because the most significant bit is a zero. When we enforce this 1024-bit restriction in Firefox, we should just make sure we're doing something reasonable here, and what we're doing is consistent with other implementations.

- Brian

[ianG]

On 14/02/12 06:16 AM, Brian Smith wrote:
> Robin Alden wrote:
>> The suggestion from Opera to the CAB Forum back in November was that
>> we should make sure any issued certificates with keys shorter than
>> 1000 bits (and **definitely** those shorter than 700 bits) are
>> revoked.
>> We have been led to believe that, in the near term, Microsoft IE will
>> give a visible warning for (or will refuse to connect to) sites with
>> otherwise trusted certificates with keys smaller than 1024-bit RSA.
>>
>> Looking at real-world key sizes, I would say the real crunch point is
>> whether you think 768 bit keys are strong enough to remain unrevoked
>> in the short term. Either 768 is enough, in which case that becomes
>> the minimum that may remain unrevoked, or 768 is not enough in which
>> case the minimum needs to be a value of at least 1000.
>
> There are already successful factorings of RSA-768, so the limit can't be RSA-768 or below.
>
> If Microsoft is going to set their limit at 1024 and we're planning to set our limit in Firefox at 1024 then I think that it makes sense to have the policy set the limit for revocation to 1024. In fact, I doubt we will set the limit at exactly 1024 bits; we should instead set the the limit at 1024/8 = 128 bytes, allowing the 7 most significant bits to be zero (so effectively, 1017 bits).

Just a governance nitpick. The policy *should not include* a number
like that. Instead, the policy should state that certificates are to be
issued according to a risk profile stored on the wiki somewhere and
maintained by the module officer, with routine changes to take effect
(say) with 6 months notice.




iang