URL:
https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable
dpward commented:
"""
Although it is true @dpward that SHA-1 is allowed, you need to read
the fine print as well "for applications that do not require collision
resistance".
Basically this exclude unique identifier if those are used in any "security"
sense, while you still can use SHA-1 in applications where a collision is handled
appropriately (for example hash-maps).
@simo5 Are there any concerns about that for the issuer hash in the OCSP request though?
So it really depend more and more on the kinds of usage, which is why
it is preferable, where possible, to simply move off of SHA-1.
This is an OCSP client implementation, which needs to be compatible with the OCSP server
in order for it to be useful. The reason given for this particular change was "FIPS
compliance". Not only am I unable to locate such a requirement in FIPS, but this
change has the practical effect of actually breaking out-of-the-box compatibility with
OCSP servers that have a **mandate** to comply with FIPS. How was this change tested? As
another data point here, please see:
https://devicepki.idmanagement.gov/certificateprofiles/#ocsp-response-pro...
Field | Value and Requirements
-- | --
CertID | hashAlgorithm shall be SHA-1<br />The issuerKeyHash and issuerNameHash
pair must be identical within all Single Responses appearing in an OCSP Response
"""
See the full comment at
https://github.com/SSSD/sssd/pull/837#issuecomment-675020401