URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
dpward 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? > 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. How was this change tested? As another data point here, please see: https://devicepki.idmanagement.gov/certificateprofiles/#ocsp-response-profile > Field | Value and Requirements > -- | -- > CertID | hashAlgorithm shall be SHA-1<br />The issuerKeyHash and > issuerNameHash pair must be identical within all Single Responses appearing > in an OCSP Response """ See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-675020401
_______________________________________________ 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]
