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

[ghen]

@nagmat84

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

For example with Postfix, you could selectively disable STARTTLS (with smtpd_discard_ehlo_keyword_address_maps) only for that provider's MTA IP range, so they will be forced to use plaintext, rather than you having to support legacy crypto specifically for them.

[orangepizza]

well the plan is full availability of ecdsa intermidiates with next run of intermediates and certbot already default to ecdsa, so I think answer likely be "why not ecdsa already?"

Let's Encrypt New Intermediate Certificates

A…

[9peppe]

@ghen

selectively disable STARTTLS

That's a lot of work for something that doesn't see much use; smtp over tls on port 587 should get most mta traffic.

[orangepizza]

another question is: if one doesn't understand ecdsa, how likely it understand pss padding?
looks like golang can't process RSASSA-PSS, crypto/x509: unable to parse certificate with rsassa-pss algorithm · Issue #48314 · golang/go · GitHub is open without any commit attached to it

[nagmat84]

Actually, I am getting tired of this discussion, but anyway.

@danb35

[...] 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.

Who are you telling? Nobody claimed anything different. See

@nagmat84

In Germany we have a saying, "where there is no plaintiff, there is no judge". [...] 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.

There are two "if"s in the paragraph above. Yes, some harm must be done before.

@danb35

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.

Nobody talked about suing LE. Honestly, your post is a straw-man fallacy. You are refuting an argument that has never been made in the first place.

@danb35

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 I'm an end-user, the mis-issued cert might result in my being victim of a scam.

Yes.

@danb35

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.

No. The end-user has not a claim against LE as a CA. On what ground? Please note, that "users" of LE's services is not end-user, but a service providers which use LE to create certificates for their service (e.g. a web site).

The (potential) problem is as follows, and, yes, there must be some harm in the first place. Let's assume there was a data leak or violation of GDPR or some other kind of "harm". An end-user sues the service provider (not LE) and that service provider has been using certificates issued by LE. Now it turns out the certificates were not up to standard. Then, the end user might have good arguments against the service provider. It is the problem of the service providers to ensure that their IT security measures are up to standard. Hence, as a service provider doing business in Germany, this means the service provider need to reconsider whether LE is the right CA for them. Nobody has a claim against LE, because it is the responsibility of the service provider to choose the right CA.

Besides actual lawsuits (worst case) there also also other aspects. As a service provider one typical has to undergo a lot of audits (e.g. ISO 27001, ..., etc., you name it). Even without any actual harm one has to "prove" that one follows technical standards, recommendations etc., because assurance companies, business partners, etc., are crazy for that stuff. So you (as a service provider, not! end-user) has to show that you are using certificates which meet the required strength. You (as a service provider) can't do that if you using LE as your CA.

[orangepizza]

I don't think LE can make BSI complient RSA certificate anyway: you already said it need PSS padding after 2025: and as boulder id written in golang and it doesn't support PSS padding, and unlike anyone written custom padding that only work for like 5 years and legacy client likely not able to use anyway:

[schoen]

While it seems clear that Let's Encrypt won't prioritize this change just for the theoretical compliance with this directive, it would be very interesting to hear BSI's own view on whether their rules were meant to apply to intermediate certificates this way, and whether they can articulate a security rationale for that.

It might turn out that they want to issue a clarification that (at least in some circumstances) intermediate certificates' signing keys are not expected to be 3072 bits¹, or alternatively that they can explain a threat scenario that might be more convincing to the Let's Encrypt team.

I'd be happy to help write a letter to BSI asking them to consider clarifying these topics if there's any chance that that might be helpful.

¹ A detailed threat model for the interaction with Certificate Transparency, for example, seems like a subtle question.

[Osiris]

You could always use other free ACME CAs like Buypass, which (currently) uses a 4096 bits RSA intermediate and a 4096 bits RSA root certificate.

(Or check the others here, I can't check their intermediate/roots as crt.sh is down currently..)