Description of problem:
Many DNSSEC ZSK keys used on public zones use short keys. Those short keys verifications works on RHEL 9.0 at the moment, but is going to be fixed by bug #2077884.

Version-Release number of selected component (if applicable):
unbound-1.13.1-13.el9_0.x86_64

How reproducible:
would be reliable

Steps to Reproduce:
1. kdig +multi -t dnskey 100.in-addr.arpa | grep '1[0-9]{3}b'
2. fips-mode-setup --enable && reboot
3. unbound-host -rdD -t dnskey 100.in-addr.arpa

Actual results:
validation failure <100.in-addr.arpa. DNSKEY IN>: ...

Expected results:

1. unbound-host -rdD -t dnskey 100.in-addr.arpa
   [1650638908] libunbound[5250:0] notice: init module 0: subnet
   [1650638908] libunbound[5250:0] notice: init module 1: validator
   [1650638908] libunbound[5250:0] notice: init module 2: iterator
   [1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: response for 100.in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: prime trust anchor
   [1650638908] libunbound[5250:0] info: generate keytag query _ta-4f66. NULL IN
   [1650638908] libunbound[5250:0] info: resolving . DNSKEY IN
   [1650638908] libunbound[5250:0] info: resolving _ta-4f66. NULL IN
   [1650638908] libunbound[5250:0] info: response for . DNSKEY IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validate keys with anchor(DS): sec_status_secure
   [1650638908] libunbound[5250:0] info: Successfully primed trust anchor . DNSKEY IN
   [1650638908] libunbound[5250:0] info: resolving arpa. DS IN
   [1650638908] libunbound[5250:0] info: response for _ta-4f66. NULL IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was NXDOMAIN ANSWER
   [1650638908] libunbound[5250:0] info: response for arpa. DS IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validated DS arpa. DS IN
   [1650638908] libunbound[5250:0] info: resolving arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: response for arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validated DNSKEY arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: resolving in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: response for in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validated DS in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: resolving in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: response for in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validated DNSKEY in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: response for 100.in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: reply from <.> 10.2.32.1#53
   [1650638908] libunbound[5250:0] info: query response was ANSWER
   [1650638908] libunbound[5250:0] info: validated DS 100.in-addr.arpa. DS IN
   [1650638908] libunbound[5250:0] info: resolving 100.in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: validated DNSKEY 100.in-addr.arpa. DNSKEY IN
   [1650638908] libunbound[5250:0] info: validate(positive): sec_status_secure
   [1650638908] libunbound[5250:0] info: validation success 100.in-addr.arpa. DNSKEY IN
   100.in-addr.arpa has DNSKEY record 257 3 8 AwEAAdu8S6vA/qjjqhpy+uHwCI6OROw/XYHEzflqQNIxx8duJgjoWNCcFWM2IFd0IYE/ZAIY8u1+eyV8abfnQNvLtww/SrNgOmkJwEJuato7sSOYUYdWMkYzUHtyvykaRk9/MeN+zFAJvSL3/qwI0WlQvgXeOpzpLdedndsy5SSAR9NnqWXnx8zsfDvbAlAKiw6jh4MGPZXYx7amuHdjUT56I8ve5kBDtmYokA4VsZnLkVvmXPrMBV7D/EkUMMnAh0E/vwpvTDymy+1FdlsUfahSTk5FDoefPCbM/rdLPIzaeOiv4hpBJRSVRmPqNXDpAYme7LBYeBoOY1HUCHdQu4GNLbk=
   100.in-addr.arpa has DNSKEY record 256 3 8 AwEAAbR4oHfWLSP0zkavL3qHJ9zvfEwnKEOmivHW4iXicr5r/Qg1q0OBnvuXSPfZejCJ//3YQZdBG8iBLAH6GF7J+/Bw1txtXbAR38d1Vr2RGqrvk814QwunYBof/abLjFalp+oXkGROUa8ZyoYlM4j+rBsuUL8gVAATLJW+JQb8eYNN
   100.in-addr.arpa has DNSKEY record 256 3 8 AwEAAdTgLMi5YbiAEE1zb2hXsmIIJIpqEt+YyV1NLbmeVYAoBvXKK+U3H6N2PrlQ/HEF0jNWBQfxIsvpkLuDZ/HOKlOuDaESaNHioLu42Jcfv4AQDRrjDiPvnmpzmOYFFVocDSd1wkM/6uZoz1kr8WtsXtDLT843xgY+GJL2moqwbNzn
   100.in-addr.arpa has DNSKEY record 257 3 8 AwEAAcV24UXiGxCcmKYdQXt/z3W3JNgqh0ycG0/WTS/H+bXV/pmLB9N2fq45gwbJfS2UAvz7pMNqFYTdqaPNK0eCYal4fRVwZvI655pUZr/rXYHhj0ASvSmJZOV5wiiQ27VB30lM+57DXSYVzXdGIi16R3ScEE/HwdYq/Cuge/G/tUqYpOYowHDkEjPTtQB3SlZzlvCFNQ30l6y7i2/ZI5scmmS/QS18dZlsYRV6+aWIFY6AfQ5jZgS3Rrrs9mH9ZiJlvdh314bZDk7Zt1SBCI8/6JEdadt6DG0+TJMBl2lQZM/+UJUGtz+ZO30eVB5n6JQLCKU0wgrNouDks9hOxJNHFJM=

Additional info:
Similar bug #2077906 for bind. It is needed to find a way to make those queries insecure in FIPS mode, but not failing.

Another issue is with ED25519 and ED448 algorithms, which are disabled in FIPS mode. They make validation failing:

unbound-host -rD secure.d4a15n3.rootcanary.net.
secure.d4a15n3.rootcanary.net. has address 145.97.20.20
validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust
secure.d4a15n3.rootcanary.net. has IPv6 address 2001:610:188:408::20
validation failure <secure.d4a15n3.rootcanary.net. AAAA IN>: key for validation d4a15n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust
validation failure <secure.d4a15n3.rootcanary.net. MX IN>: key for validation d4a15n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d4a15n3.rootcanary.net. A IN>: use of key for crypto failed from 10.x.x.1 for key d4a15n3.rootcanary.net. while building chain of trust

Those are failing in sldns_ed255192pkey_raw and sldns_ed4482pkey_raw calls. A good fallback to insecure is needed for them as well.