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 states it 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. RFC 6960 discusses the security considerations when [choosing
the response signing
algorithm](https://tools.ietf.org/html/rfc6960#section-5.1).
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-is, its hash is
computed and that is sent in the request 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, 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 issuer hash algorithm should remain a configuration option, but the default should be
reverted to SHA-1, which satisfies RFC 5019. Note that SHA-1 is already the default
algorithm when SSSD is built with NSS support, rather than OpenSSL support.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907