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.
However, the hashes that are affected by this pull request are not used in a
_cryptographic_ manner. To obtain the status of a certificate, an [OCSP request
message](https://tools.ietf.org/html/rfc6960#section-2.1) needs to specify the issuing CA
for that certificate. Rather than sending the full distinguished name as part of the
request, a hash is sent instead. (The first paragraph of [section
4.1.2](https://tools.ietf.org/html/rfc6960#section-4.1.2) adds context.) With this pull
request, that hash algorithm can be chosen.
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. (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