URL:
https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented:
"""
@alexey-tikhonov -
Re you comment
https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
OCSP responders are NOT guaranteed to accept SHA2 hash types, and depends on the
deployment's configuration. We have encountered an issue where an OCSP responder
configured for only SHA1 will deny entry to a system when SHA256 is not enabled.
Could you please check if using `ocsp_dgst=sha1` helps?
Looking thru the RFC, I don't see mention of a responder to be
required to answer for all hash types.
I'm sure we're not the only ones noticing this change has broken PKI
authentication, and it may be prudent for p11_child to attempt a fallback back down to
SHA1 if SHA2 OCSP request fails unauthorized.
But that would be against our intent.
Also, I've not been able to locate the language in FIPS140 that
bans SHA1's use. Could you please refer to this in the standards document?
I think strictly speaking SHA-1 is still allowed for a limited uses (like `HMAC-SHA-1`) by
FIPS 140-2, but intention is clearly to ged rid of it.
Quick search yields things like
https://www.stigviewer.com/stig/application_security_and_development/2017...
:
```
While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this
algorithm, DoD PKI policy prohibits the use of SHA1 as of December 2016.
```
etc.
For this reason it was made configurable, defaults changed to more secure option, but
sha-1 is still allowed to be configured explicitly.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/837#issuecomment-672847772