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@gmail.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.