FIPS provider too conservative with legacy checks?

[Thomas Dwyer III]

Our organization signs image artifacts with 2048-bit DSA keys before 
releasing them to the field. Some of these signatures fail to verify 
when using the OpenSSL 3.0 FIPS provider. It turns out that while most 
of our signing keys are (L,N)=(2048,256), two early keys created long 
ago are (2048,160) and the signatures that fail to verify were created 
with these keys. Disabling security checks in the configuration file 
resolves this but I'd prefer not do that and inadvertently let something 
else non-compliant go undetected.

I discovered this code in providers/common/securitycheck.c:

         /*
          * For Digital signature verification DSA keys with < 112 bits of
          * security strength (i.e L < 2048 bits), are still allowed for 
legacy
          * use. The bounds given in SP800 131Ar2 - Table 2 are
          * (512 <= L < 2048 and 160 <= N < 224)
          */
         if (!sign && L < 2048)
             return (L >= 512 && N >= 160 && N < 224);

I am by no means an expert in cryptography but this logic does not seem 
to match my interpretation of the spec which for legacy use allows:

     ((512 <= L < 2048) or (160 <= N < 224))

with "or" being the operative word here. OpenSSL is making this an "and" 
condition. Doesn't 800-131Ar2 allow (2048,160) when verifying a DSA 
signature, or am I misreading the spec?


Thanks,
Tom.III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230609/2f6b015b/attachment.htm>