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. > How was this change tested? As another data point here, please see: > https://devicepki.idmanagement.gov/certificateprofiles/#ocsp-response-profile 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
_______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
