URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
karlg100 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? Yes, we have proven that manually configuring the client does work around the issue. It seems however that other implementations will fallback. I do realize some of this is openSSL behavior, but this change may have broken existing implementations, especially already deployed RHEL8 systems. I'm actually ok leaving this default as I'm working with those needed on my side to advance OCSP forward, but mostly an FYSA based on the RH Bugzilla comment stating that OCSP responders must have SHA2 enabled and ok to change the default, which is an incorrect assumption. > > 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. Thank you for the link. We were aware of the DoD Memo for the rollout, but the STIG info is helpful guidance for infrastructure admins. """ See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672886466
_______________________________________________ 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]
