URL:
https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable
simo5 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?
I haven't looked carefully enough to say if this is just a short hand identifer upon
which no security at all impinge, or not. sounds *ok* for now at any rate.
> 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.
Yeah I think the message got simplified to "remove SHA-1 everywhere" in
transit.
It is an easy mistake, and as I said it is better to move to SHA-2 wherever possible
anyway.
In this case the "wherever possible" threshold seem to not have been met.
It's a bug, it will be fixed, doesn't help that OCSP is not yet that common that
you'd spot it right away ...
> Field
> Value and Requirements
>
>
>
>
> CertID
> hashAlgorithm shall be SHA-1The issuerKeyHash and issuerNameHash pair must be
identical within all Single Responses appearing in an OCSP Response
This will come up over and over again probably, damn if you do, damned if you don't
:-)
"""
See the full comment at
https://github.com/SSSD/sssd/pull/837#issuecomment-675027739