Allow longer RSA key lengths and add PSS support for acmeServerCert profile

[ysyvachenko]

PR Description

This PR is related to #3491:

• Modified RSA related profiles to allow using RSA key length up to 16384. A few commonly used sizes are added.
• It seems that the ACME Server profile missed PSS support, added PSS signing algorithms as allowed to the profile.

Concerns

• I have added 'long keys' support to all RSA profiles. To be honest I am not aware of the meaning of some of them. I suspect some profiles could be related to some low-power devices or tokens, where usage of long keys may be undesirable. Could you please double-check this?
• I am not sure about unit tests. My view is that we do not need tests for long keys, but maybe need for PSS support in ACME Server profile. Could you please advise me with testing, if needed?

[edewata]

@jmagne @ladycfu Could you take a look at this PR? Thanks.

[jmagne]

This looks fine and all, I would just ask cfu if we even support some of these huge key sizes. That is based on how long it might take for software or hardware to simply generate RSA keys of these sizes.

[ysyvachenko]

I have tested FreeIPA installation with such key sizes for Dogtag:

[DEFAULT]
pki_admin_key_size=8192 
pki_audit_signing_key_size=15360
pki_sslserver_key_size=8192 
pki_subsystem_key_size=15360
[CA]
pki_ca_signing_key_size=15360
pki_ocsp_signing_key_size=15360
[KRA]
pki_storage_key_size=15360
pki_transport_key_size=15360
[OCSP]
pki_ocsp_signing_key_size=15360

I have checked the certificates in FreeIPA and Dogtag generated them correctly. The only issue I found is related to pki_admin_key_size and pki_sslserver_key_size. I guess, it is certutil tool that generates keys for Tomcat, and certutil does not support keys longer than 8192. It would be nice to use openssl instead of certutil, but it is not critical for me.

As for key generation, it is mainly related to the availability of entropy, I think. The worst case I saw in my testing was ~20 minutes for the key 16384 on the quite old Xeon from 2013 without hardware support of cryptography and definitely without any hardware random generator. In any case, I have successfully installed FreeIPA and Dogtag after such a long delay. On some recent installation in the cloud it was ~3 minutes for the same key size, there CPU has some crypto support, but I have not investigated it deeply.

[ysyvachenko]

@jmagne @ladycfu
Is there any additional information I could provide you with to proceed with merging to master and v10.10?

[ladycfu]

sorry for the late response.
Here is my take. Adding support for PSS is a good idea. Bumping up key size to 16384 probably isn't, as that would bring the performance down to a crawl (for the general public). I suggest just bump up to 8192. For those who have beefy systems they could bump up the profiles themselves. just my 2 cents.

[ysyvachenko]

@ladycfu Thanks for your response.

This quite old article from 2016 notices 'that a quantum computer capable of breaking 2000-bit RSA in a matter of hours could be built by 2030': https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf
During 2020 a few companies delivered the next versions of their quantum computers with amazing characteristics and companies began to compete. The corresponding market started growing and thus estimates from 2016 seem less accurate now and we may expect larger keys to be able to be broken by 2030.

A special post-quantum cryptography standard is not available yet, as far as I know. The main hope here is that the current technologies for building quantum computers will face technical issues (the ion trap line should have issues with scaling, superconducting - with accuracy). To leverage possible technical issues we must use as large a key as possible.

I have investigated a few libraries and found that 2 modulus RSA with 16384 key is acceptable in my cases and it seems all modern browsers support this key length. I found that 32768-bit key length is a bit unreliable as key generation is too long on old hardware. This seems to correspond to OpenSSL's vision - it starts showing warnings on 32768-bit keys and larger.

I have successfully installed the FreeIPA system with most certificates using 15360-bit keys. To achieve this I indeed needed to patch a lot of files and profiles. Finally, I can say that it works fine for me and my cases.

Most fixes I made were related to FreeIPA itself and there we can find some controversy, but this particular fix for Dogtag looks fine for me. The reasons are following (I could be wrong, please feel free to correct me):

• We are not going to change any default in Dogtag, it will still use normal keys by default.
• The only issue I found in relation to long keys is a key pair generation. In general, it is fast enough but could take a long time on old hardware.
• We are talking about allowing to sign certificates with large keys, where key pair was generated outside of Dogtag and all computational and entropy demand were put on that third party host. As soon as the host has generated the key Dogtag can easily sign it.
• Every application for which we need to sign a certificate has its own default key size. In most cases, it is 3072 or 4096. Thus, if the Administrator is not worried about quantum computers, they will use defaults in Dogtag and all certificate signing requests. I assume, most Dogtag users won't notice any changes.
• The main goal of PR is to simplify deployments for those Administrator who need really long keys. Dogtag already allows long keys generation for its internal certificates with the custom configuration I mentioned above. The only missed thing is the proper policies. It is the only fix I need in Dogtag for now.

[ladycfu]

@ysyvachenko I do not disagree with you irt the benefits of longer keys against future attacks, as that's a known fact. Although there are other alternatives such as EC keys, or in the case of TLS, Forward secrecy provided by TLS 1.3. There is also a question of how long is long enough, and how much time would that buy us. Could the heartache one bears for 16384 bit key in the name of security in the end proves to be just as useless as 4096 bit key in the case of a Quantum leap in computing powers?
My concern is more on the practicality and how the provision of such selection might take up unnecessary time from people who automatically chooses longest possible keys on the list, just to find them inoperable for their environment.
Anyway, I am actually not firmly against the PR, since like you said, the larger keys are not the default. I am merely voicing my concern. I'll leave it to Endi and Rob and decide then? ;-)

[edewata]

To my understanding the key lengths that we include in these profiles are the default policies that we recommend for most people. The profiles can always be customized if necessary by the admin. If we merge this PR, how likely would it cause a problem for people in general? Do we need to add a disclaimer somewhere saying that the longer keys have not been tested, or might only work in certain environments, something like that?

Also, do we need to update the profiles in existing instances? The PR as it is now will only update the profiles for new installations since during installation the profile configuration files will be copied into the instance folder. To update existing installations we'd have to implement an upgrade script that modifies the profiles already in the instance folder. Here are some examples: https://github.com/dogtagpki/pki/tree/master/base/server/upgrade.

Also note that in IPA during installation the profile configuration files will be imported into LDAP as well, so you might need a different mechanism to update the LDAP profiles in existing IPA installation if that is needed.

[rcritten]

The IPA team had similar concerns about the usability of such large keys. To use these in IPA would require an override file to be provided so the user would be in control of their own fate. I think this change fits into balance of power vs protecting the user from themselves.

Some sort of support/test level statement might be nice as even with automation it would be difficult to test all combinations of key sizes to determine if everything still works correctly.

There is a sister PR to add this capability to IPA in freeipa/freeipa#5640