URL:
https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable
dpward commented:
"""
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.
The FIPS requirement you referenced is for **cryptographic** hashes. For example: an [OCSP
response
message](https://tools.ietf.org/html/rfc6960#section-2.2) contains a
"signature computed across a hash of the response", which involves the use of a
private key.
The change made here did not affect _cryptographic_ hashes. An OCSP request message needs
to specify the issuing CA for the certificate in question. Rather than send the full
distinguished name in plain text, it is sent in the form of a hash (think `sha1sum`). This
change made it possible to choose the hash algorithm.
Now, note that some OCSP responders (including Microsoft's) implement RFC 5019, which
places restrictions on how OCSP is used. [Section
2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that for OCSP requests,
```
Clients MUST use SHA1 as the hashing algorithm for the
CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So using hash algorithms other than SHA-1 here breaks compatibility with RFC
5019-compliant responders, which may refuse to even process the request (as we are in fact
seeing).
The algorithm should remain a configuration option, but the default should be reverted to
SHA-1, which satisfies RFC 5019 in case that is what the OCSP responder implements. Again:
this is not being used to produce a _cryptographic_ hash.
(Also note that when SSSD is built with NSS support, the default algorithm is already
SHA-1, because others are unsupported.)
"""
See the full comment at
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907