BUG #17593: min key size 112 bits from FIPS SP800-131 requirement for HMAC-SHA raises exception in SCRAM-SHA-256

The following bug has been logged on the website:

Bug reference: 17593
Logged by: Scott Zelenka
Email address: szelenka(at)gmail(dot)com
PostgreSQL version: 14.5
Operating system: Ubuntu 20.04
Description:

Running postgres with:

postgres -D /home/postgres/pgdata/pgroot/data \
--password_encryption=scram-sha-256 \
--ssl=on \
--ssl_cert_file='/run/certs/server.crt' \
--ssl_key_file='/run/certs/server.key'

Will raise an error when attempting to create a ROLE with a SCRAM-SHA-256
password:

CREATE ROLE "test-enc-pw" LOGIN ENCRYPTED PASSWORD
'SCRAM-SHA-256$4096:RlI0UDRNeEFSRUp0Y29kWA==$knE29fNkMKTvocaIou0vfZ+J+lwp4hawGKrXPVDOA08=:ZMQb8JU1qRdMv0wjFUBuD/E2G+YJhHV+KBSVzDC6ifA=';

Running on Postgres 125 BETA 3 gives more context into the error:

ERROR: could not compute server key: invalid key length

The "invalid key length" is returned from the FIPS Validated OpenSSL library
Postgres is linked to. Where it is enforcing FIPS SP800-131 requirement for
HMAC-SHA, minimum key size is 112 bits when used for security purposes.

This appears to be triggered during the NULL password check during CREATE
ROLE:
https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/commands/user.c#L373

Attaching a debugger, we can see that in normal code execution path, the
plain_crypt_verify method should return STATUS_ERROR (because the password
is not actually empty) then continue on it’s way to perform the actual
encryption. But because we specify SCRAM-SHA we trigger
scram_verify_plain_password:
https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/libpq/crypt.c#L236-L239

Which causes it to error out, rather than returning a STATUS_ERROR like the
working path(s).

There seems to be a conflict with how the NULL password is checked for, and
enforcement of FIPS SP800-131 by a FIPS Validated OpenSSL library.