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-12-18/finding/V-70193 : ``` 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
_______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
