What is the roadmap for intermediate certificates with 3072bit RSA or EC 384bit (tightened BSI regulations)?

Issuance Policy
1

As of January 2024, the BSI (German Federal Security Authority) has tightened its technical guidelines regarding key sizes (see https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile). For asymmetric algorithms over finite fields (e.g. RSA signatures, RSA encryption, DH key exchange) the minimal requirements are 3,000 bits.

It is possible to generate an end entity certificate with appropriate key size. For example via certbot certonly --key-type rsa --rsa-key-size 3072 ... or (alternatively) certbot certonly --key-type ecdsa --elliptic-curve secp384r1 ...

However, this fall short and does not meet those legal requirements as of today, the intermediate sub-CA certificate has only 2048bit RSA.

What is the roadmap to either increase the RSA key size above 3,000 bits along the entire PKIX chain or go full EC?

2

Could you please cite the exact requirements for intermediate certificates from that document? Because I'm not able to find it.

3

What aren't you able to find? The document or the requirements?

Please note, there are no requirements specifically for the case of intermediate certificates. The requirement is on RSA encryption, RSA signatures, etc. But as the Let's Encrypt intermediate certificate uses an RSA signature this requirement on RSA signatures still apply.

From the document, table 1.2 (p. 18), "Recommded key lengths for various cryptogaphic mechanisms":

Block Ciphher: 128
MAC: 128
RSA: 3000
DH F_p: 3000
ECDH: 250
ECDSA: 250

Also, table 2.1 (p. 28), "Recommended classical asymmetric encryption and key derivation schemes as well as key lenghts":

RSA: 3000
DLIES: 3000
ECIES: 250
DH: 3000
ECDH: 250

In chapter 5 "Data Authentication", subsection 5.3 "Signature Algorithms", subsubsection 5.3.1 "RSA" (p. 49):

Key Length The length of the modulus n should be at least 3000 bits.

4

The requirements for the intermediate certificates.

I read those as "recommendations" indeed. No hard requirements.

If not explicitely mentioned, I'm not sure if intermediate certificates are required to follow these, well, guidelines? The guide is not specifically written for TLS for example. If I read chapter 5, I'm more enclined to think it's about general data encryption, not specifically for TLS.

That said, I'm curious to know the answer from the Let's Encrypt staff :slight_smile:

By the way, weren't these 3000 bit requirements already added back in 2023? ("Increase of the security level to 120 bits (…)")

2 Likes
5

I too was hoping that Let's Encrypt would use at least 3072 bits for the new intermediates instead of implementing a weird randomization system with the stated goal of forcing people to do things a certain way. I guess, by the time these new certificates expire, there will be no demand for lengthening the keys anymore, since the first post-quantum algorithms will be rolling out.

1 Like
6

That won't help you let's say in a court proceeding. Yes, they are "only" recommendations, but unless you don't have very good reasons to not follow them, you are lost. (Good reasons could be closed, offline network and industrial PLC.)

This is not how technical specifications work. They are intentionally be supposed to be generic in order to avoid to repeat everything for every single use case and to avoid the pitfall to leave something out. For example, if one would explicitly list application A, application B, etc., some clever guys would certainly argue that the regulation does not apply, because they are using application C.

The recommendations apply to RSA signatures. Period.

7

This is already possible today. Let's Encrypt has both an ECDSA root certificate (P-384) as well as ECDSA intermediates [Chain of Trust - Let's Encrypt] (all P-384).

Currently, your account must be on an allowlist to get your ECDSA leafs signed by ECDSA intermediates. However, this is likely going away soon.

(Also, because we just had a key ceremony a few weeks ago, we know that we're likely going to remain at 2048 bits RSA for at least 2 more years)

5 Likes
8

I think it is more likely we discontinue RSA intermediates than go to larger ones, especially as we expect post-quantum cryptography methods to be adopted over the next decade.

We do plan to make ECDSA intermediates generally available once our new intermediates come online this year. Expect an announcement on that front in the next few weeks.

6 Likes
9

@Osiris : In case you insist on a technical guideline written specifically for TLS, see https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7, which is part 2 of the same guideline and which deals exclusively with TLS. It had been updated at the same time as part 1. Unfortunately, I only found the German version. However, it should suffice to look on the title page which clearly states "TLS" and then table 13 in section 3.6.1. A key length of 3000 bit is required since 2023 (third column of that table) and is expected to be good enough until 2030 (fourth column of that table).

10

I probably could have read the German version, but changing the -1 to -2 in your original PDF link is actually the English version for part 2 :stuck_out_tongue:

It's interesting to see that the recommendations actually allow for CBC modes until 2030+ while it's actually known CBC has some severe limitations.. I'm quite puzzled by that. Didn't read the foot note saying "Note: The use of cipher suites with CBC mode is only recommended in conjunction with the TLS extension “Encrypt-then-MAC”, as soon as suitable implementations are available (see Sections 3.3.4.4 and 3.3.4.5)." which probably makes CBC more secure again.

Hm, according to table 6 in 3.3.3 the usage of RSA is only up to 2025 with TLS1.2.. So only this year. That means you're forced to use ECDSA only for 2025 and onwards if you want to keep using TLS1.2. Or drop 1.2 and only support TLS1.3. Although that section is for what signature algorithms the client wants to use..? Does that section/table also impact servers? :thinking: Probably not looking at table 2 in section 3.3.1.1.. Confusing :stuck_out_tongue:

Also curious that there's no mention of CHACHA20+POLY1305.. :roll_eyes:

2 Likes
11

@mcpherrinm That is great news, but I would like to see RSA some time longer.

The reasons why I am currently occupying myself with this matter is some compatibility problem. My mail server has been using EC with 384bits since I set it up for the first time one year ago. I recently got some complains from a user how was not able to receive mails from one of his friends who is with a different provider. As it turned out there is at least one middle-sized mail hoster in Germany whose mail server do not support EC crypto at all. (Argghh! WTF?! :dizzy_face: ) Hence, that mail hoster's SMTP servers were not able to connect to my SMTP server. :frowning:

In order to increase compatibility and to help my users I created an RSA certificate this morning. (Unfortunately, I had no luck to explain the admins of that other mail hoster that they should really, really update their completely outdated OpenSSL and Exim installation. I mean OpenSSL 0.9.7 without EC support is how old?!)

This puts me into a difficult spot. Actually, I don't want to support RSA anymore. However, I have to in the interest of my users and to be compatible with the rest of the world. But if I do so, I have to be at least compliant with the regulations. (Please don't ask me how that other mail hoster achieves that.)

1 Like
12

Not necessarily, see the paragraph below that table. It depends on the padding scheme. If you use RSA with PSS padding, then you are free to use it until 2030. (Which also probably explains why there are recommendations for key length that are valid until 2030.)

I am not sure what you are refering to or find confusing. I assume you mean the different years until you are allowed to use certain ciphers? I guess you refer to the fact table 2 allows to use certain ciphers with RSA signatures until 2030, but table 6 allegedly only allows to use RSA signatures until 2025? Well, it depends on the padding scheme, see above.

13

We will continue to support RSA for a long time yet, but we will not likely increase key sizes beyond 2048.

I recognize that may have some regulatory compliance issues for you, but the tradeoffs of larger key sizes don’t necessarily make sense for relatively short-lived intermediates. If you have regulatory restrictions prohibiting rsa2048, you may need to use another CA.

There’s no IMO credible reason to believe that rsa2048 is going to be threatened inside the lifetime of our current intermediates.

Government standards tend to assume very slow-moving changes, so they may sometimes be more conservative with key sizes and choices than necessary because they are worried about ability to adapt.

On the other hand, the “weird randomization” is entirely designed to make sure that we can rapidly deploy new intermediates if and when required. This isn’t a theoretical issue either: Another CA needed to revoke an intermediate recently and struggled a lot with users pinning intermediates incorrectly.

6 Likes
14

I suppose there's known vulnerabilities, and if admins don't care, data protection authorities and script kiddies might?

3 Likes
15

Why? The load for computing secp384r1 is almost equal to 3072 bit RSA. Yes, the keys are longer, but sacrificing security for speed isn't worth it. Let's Encrypt seems to put a lot of effort in making handshakes as small as possible in a world of ever increasing internet speeds.

I would agree that such pinning practises are bad, but how is this your problem? If users can't take a "don't do this" in the documentation as advice, it's their fault. I just don't see why there need to be technical measures to make it more inconvenient for people to shoot themselves in the foot.

16

This is not about time to render the entire page, it's about time to first draw. Also, there's no reason to be inefficient for RSA keysize's sake.

NB: p-256 and rsa3072 are pretty close as far as bruteforce resistance goes.

Also: if you compromise an intermediate all you can do is issue leaf certificates (and other intermediates, perhaps), or revoke the intermediate itself. I don't know how that plays with the CT ecosystem.

2 Likes
17

My best guess:
Unless an enhanced requirement [beyond 2048] is mandated [which seems highly improbable], any further work done down the RSA path would simply be wasted.
And LE has zero time to waste.

2 Likes
18

I would kindly like to ask everyone to stop discussing the pro and cons of that randomization technique. This post was about the LE's roadmap for key sizes and the updated BSI regulations. The randomization technique tries to solve another problem and if this randomization technique has undesired or impractical side effects for some people, please open a new discussion thread.

I am not sure what kind of "time" you are referring to. Personnel expenditure at LE's side to implement the transition from 2048 to 3072 bit or computational complexity every time a TLS server/client has to perform a calculation with the (larger) key.

With respect to personnel expenditure, I don't see that. It isn't like that there is a complete new feature to be developed or that something changes on the architectural level. The key size is supposed to be a parameter which only needs to be set to a new value. As of today it is already possible to obtain leaf certificates with 3072 bit without further ado.

With respect to enhanced requirements, there are those requirements by the German BSI. That why I started this post in the first place.

I assume that you once again aim at the wording as "recommendations". As I already wrote in post #6 those recommendations are strict, unless you have very good reasons to not follow them and you have compensational measures in place (e.g. fixed industrial PLCs which cannot be updated, but everything is air-gapped on a closed network).

In Germany we have a saying, "where there is no plaintiff, there is no judge". Yes, the German BSI cannot enact laws as the BSI is not a legislative body, but part of the executive branch. However, BSI regulations are comparable to statutory ordinance. If something happens and if someone sues you or someone pulls charges against you (e.g. consider a data leak in violation of the GDPR) a judge will refer to BSI regulations as the lower barrier for state-of-the-art security measures.

Exactly, thank you. Basically any arguments like

are futile (at least for German users). All these kind of arguments have already been made during the discussion of that BSI regulation. However, as always when there is a continuum of possible options (in this case key sizes), the final result will always be arbitrary. But this is intrinsic to that kind of regulations. There will always be good arguments for smaller key sizes, there will always be arguments for larger key sizes, but eventually one has to draw a line in the sand. And the BSI drew the line at 3000 bits.

Take speed limits for car traffic as another example. In most regions the speed limit within city limits is 50km/h (or 30mph in North America). That limit is also completely arbitrary as can already be seen from the fact that some regions allow 60km/h (~35mph) and some other only 40km/h (~25mph). As long as nobody catches you and as long as nothing happens, going over the speed limit won't have any consequences. However, if one violates the speed limit and something happens (e.g. car accident), then any argument along the lines that the speed limit didn't make sense, because the car had some extra safety measures, won't help you.

Having said that, let's summarize. My objectives for this thread were twofold:

  1. raising awareness on LE's side for the new BSI regulations, and
  2. asking about the LE's future road map.

I believe both goals have been achieved. @mcpherrinm works for LE and is now aware of the new BSI regulations. I myself also got my answer that there are no such plans to increase RSA key size above 3000 bits. That puts German user into a difficult spot, but so be it. That's something German users have to deal with unless LE changes its position.

1 Like
19

Really, I don't think that some BSI recommendation is of any practical relevance here. Maybe for federal websites, but not much else. I'm all for 3072 bit keys, but I don't see how 2048 bit intermediates could get me into trouble, and let's face it: The actual rules for the web are made by Google these days. Not that I like that either, but it is how it is.

1 Like
20

I'll admit my practice doesn't include Germany, but in my 25 years of practice that just isn't how the law works. Failure to follow established guidelines/recommendations can (and often will) result in your being found negligent, if and only if some harm has resulted from your failure to do so.

The harm is a critical element. I can't sue LE just because I think their signing cert is too small; I'd need to have suffered some harm as a result. The only possible harm that could result from an insufficiently-secure intermediate cert would be that it's used to mis-issue a cert. So how does that harm me?

  • If there's cert mis-issuance for a domain I own, that could allow the attacker to impersonate me and do things I don't want done, possibly damaging my reputation or financially harming me.
  • If I'm an end-user, the mis-issued cert might result in my being victim of a scam.

Users in either of these two categories could, perhaps, have a claim against the CA. But it's not like there are any "cert police" who are going to take a CA to court.

3 Likes