Bug 2169478

The problem with proliferating subpolicies
is that then we don't have the procedure for dropping them
once people start using them and kinda maintain them forever
(which is especially problematic in case of Fedora).

I see your point and I do agree that FUTURE has raised the bar too high
with the RSA size requirement, but, unfortunately, we can't lower it now
(and sorta just hope for Let's Encrypt and its clients to bump the sizes,
 so if you could nag them to do that, that'd be great too).

I'd say, the usefulness of such a policy
would directly depend on how it'd be marketed.
If it's never mentioned anywhere,
it won't get used widely since it just won't be discovered.
If it's marketed as a milder FUTURE in addition to FUTURE,
that might end up confusing.
Or do you envision promoting it as a replacement to FUTURE?
How would you market it?

I'd also agree that FUTURE raised the bar a little too high, especially with regards to the RSA key size.
There should be some sort of middle ground and maybe FUTURE:RSA2048 could fit in there.
But perhaps a dedicated policy between DEFAULT and FUTURE might make even more sense.
How would somebody call the "not so distant" future? 

In any case, for "marketing" I think at least referring to a RSA2028 subpolicy in the update-crypto-policies(8) would be a start. 
SHA1 is mentioned there as well, right?

I'd like to see people rather recommending use of FUTURE:RSA2048 instead of simply DEFAULT to "fix" the issue when they cannot connect to sites on the Internet.
Actually the first thing I noticed after switching to FUTURE was freshclam failing...

2048-bit RSA certificates will most likely not go away anytime soon (say, in the next few months).
I'd therefore think this would justify a dedicated note, like the one for SHA1.

Also note that Letsencrypt made a conscious decision to use 2048-bit intermediates for bandwidth reduction, see:
https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html#why-we-issued-an-ecdsa-root-and-intermediates

Also contacted Letsencrypt. Let's see what they have to say about the topic.

To my previous comment: 
How about a DEFAULT, MODERN (with 2048-bit RSA) and FUTURE policy?

> MODERN

Sounds rather confusing to me, TBH

> SHA1 is mentioned there as well, right?

No. Git history suggests that it's there because it was inherited from Fedora,
and Fedora had it added at around Fedora 33 "for backwards compatibility", whatever it meant.

> I'd therefore think this would justify a dedicated note, like the one for SHA1.

I'm not sure which note you're referring to, where is it advertised?

> Also note that Letsencrypt made a conscious decision
> to use 2048-bit intermediates for bandwidth reduction, see:
> https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html#why-we-issued-an-ecdsa-root-and-intermediates

I don't see that claim on the page.
I think they're only talking about bandwidth reduction
in the context of switching over to ECDSA.
And if they have ECDSA roots and intermediates in place
and ACME clients default to ECDSA keys now,
do they have plans to default to signing ECDSA leaves with ECDSA intermediates?
IMO, that'd make a lot of sense on their side.

I'm bad at naming, so bear with me. I was just suggesting there could be something in between DEFAULT and FUTURE if something like FUTURE:RSA2048 is better avoided.

The subpolicy SHA1 is mentioned (calling it "advertised" is exaggerated) in the "CUSTOM POLICIES" section in update-crypto-policies(8) of crypto-policies-20220815-1.git0fbe86f.el9.noarch.

Regarding Let's Encrypt: Fair enough, the key size isn't mentioned at https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html#why-we-issued-an-ecdsa-root-and-intermediates.
But if they're concerned about the length of the CN subject so it's probably fair to assume they also took the key size into account for the RSA certificates.

We've discussed this request, and decided to not proceed with it
for several additional reasons:

1. a hypothetical MODERN policy won't be much different from DEFAULT,
   the most prominent difference would be requiring 256-bit ciphers
2. a policy with <256-bit ciphers disabled, but allowing 2048-bit RSA
   would be pretty imbalanced

Thanks for your interest in simplifying security tightening though.
I'm afraid we'll just have to accept
that we've painted ourselves in the corner here
and wait for Let's Encrypt world to default to full-ECDSA.

Fair enough! Thanks for taking the time to consider and discuss it!