URL: https://github.com/SSSD/sssd/pull/837 Author: sumit-bose Title: #837: p11_child: make OCSP digest configurable Action: opened
PR body: """ Currently sha1 is used to create the certid for an OCSP request. Since sha1 is not recommend for new applications anymore and not FIPS compliant this patch changes the default to sha256 and makes the digest function configurable as well.
Related to https://pagure.io/SSSD/sssd/issue/4032 """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/837/head:pr837 git checkout pr837
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """ @sumit-bose, could you please explain for sake of clarity, did you decide to drop idea of using "4.4.7. Preferred Signature Algorithms" RFC6960 extension completly, or do you still plan to implement this as part of another patch? """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-506404695
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
sumit-bose commented: """
@sumit-bose, could you please explain for sake of clarity, did you decide to drop idea of using "4.4.7. Preferred Signature Algorithms" RFC6960 extension completly, or do you still plan to implement this as part of another patch?
Hi,
I would prefer to add it later. The main reason is that I want to test how different OCSP implementation will react.
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-506417946
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """
@sumit-bose, could you please explain for sake of clarity, did you decide to drop idea of using "4.4.7. Preferred Signature Algorithms" RFC6960 extension completly, or do you still plan to implement this as part of another patch?
Hi,
I would prefer to add it later. The main reason is that I want to test how different OCSP implementation will react.
I see, thanks for clarifying.
Btw, should not be change of `Makefile.am` moved to commit e4a0513 from a4c20fe ?
I also wonder, are all of those flags really required to allow include of `pkcs11[t].h`? Or is there other reason to add it? ``` if HAVE_NSS test_utils_CFLAGS += \ $(NSS_CFLAGS) \ $(NULL) else test_utils_CFLAGS += \ $(P11_KIT_CFLAGS) \ $(CRYPTO_CFLAGS) \ $(SSL_CFLAGS) \ $(NULL) endif ```
Otherwise, patch LGTM code-wise. It also pass internal CI and covscan successfully. But I didn't verify it manually. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-506436632
URL: https://github.com/SSSD/sssd/pull/837 Author: sumit-bose Title: #837: p11_child: make OCSP digest configurable Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/837/head:pr837 git checkout pr837
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
sumit-bose commented: """ Hi @alexey-tikhonov,
thanks for the review, you are right with both, in the latest version I moved the changes for Maklefile.am to the other patch and removed the CRYPTO and SSL cflags.
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-507254036
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """ retest this please """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-507285845
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """ Thank you. ACK code-wise. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-507347238
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
jhrozek commented: """ Sorry it took me almost four weeks to test the PR. I think OSCP in general works fine.
With a valid certificate I was getting: ``` (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_card] (0x4000): Found [tuser] in slot [Yubico YubiKey OTP+FIDO+CCID 00 00][0] of module [1][/usr/lib64/pkcs11/opensc-pkcs11.so]. (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_card] (0x4000): Login required. (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [read_certs] (0x4000): found cert[Certificate for PIV Authentication][/C=SE/ST=Sweden/O=SSSD Intermediate/CN=tuser/emailAddress=tuser@ipa.test] (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_ocsp] (0x4000): Using OCSP URL [http://localhost:8888]. (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_ocsp] (0x4000): Nonce in OCSP response is the same as the one used in the request. (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_ocsp] (0x4000): OCSP check was successful. (Wed Jul 31 15:34:44 2019) [[sssd[p11_child[23202]]]] [do_card] (0x4000): /usr/lib64/pkcs11/opensc-pkcs11.so /usr/lib64/pkcs11/opensc-pkcs11.so tuser tuser 01 01. ```
With a revoked certificate I get: ``` (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_card] (0x4000): Found [tuser] in slot [Yubico YubiKey OTP+FIDO+CCID 00 00][0] of module [1][/usr/lib64/pkcs11/opensc-pkcs11.so]. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_card] (0x4000): Login NOT required. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [read_certs] (0x4000): found cert[Certificate for PIV Authentication][/C=SE/ST=Sweden/O=SSSD Intermediate/CN=tuser/emailAddress=tuser@ipa.test] (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_ocsp] (0x4000): Using OCSP URL [http://localhost:8888]. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_ocsp] (0x4000): Nonce in OCSP response is the same as the one used in the request. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_ocsp] (0x0020): OCSP check failed with [1][revoked]. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_ocsp] (0x0020): Certificate is revoked [-1][(UNKNOWN)]. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [do_verification] (0x0040): do_ocsp failed. (Wed Jul 31 15:36:25 2019) [[sssd[p11_child[23274]]]] [read_certs] (0x0040): Certificate [Certificate for PIV Authentication][/C=SE/ST=Sweden/O=SSSD Intermediate/CN=tuser/emailAddress=tuser@ipa.test] not valid, skipping ```
This was with an openssl ocsp and: ``` certificate_verification=ocsp_default_responder=http://localhost:8888 ``` """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-516857056
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
jhrozek commented: """ OK, I tried also different values of the `ocsp_dgst` option and at least I see that the revoked cert is still revoked..and invalid value seems to fall back to the default which seems OK.
So I only left two small nitpicks. Feel free to fix them or not if you feel like they are too nitpicky. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-516861998
URL: https://github.com/SSSD/sssd/pull/837 Author: sumit-bose Title: #837: p11_child: make OCSP digest configurable Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/837/head:pr837 git checkout pr837
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
sumit-bose commented: """ Hi Jakub,
thank you for the review, I addressed both of your comments.
Btw, if you record the OCSP check with wireshark you can see the used hash type since OCSP typically uses plain http without encryption.
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-518659367
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/837 Author: sumit-bose Title: #837: p11_child: make OCSP digest configurable Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/837/head:pr837 git checkout pr837
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
jhrozek commented: """ * master: * ad9dd137e2f8ad46cfb921fb7bf137fb3442692e * a97ec73e04b6347bb6aa9794f5ea9f4ca3424801 * ba01db0dcd43ef1b2079d9cc209534d45a3e938d
"""
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-519239898
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
Label: +Pushed
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
karlg100 commented: """ @sumit-bose / @alexey-tikhonov
I just updated the RH bugzilla ticket, but I'll post the same here.
@alexey-tikhonov -
Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
OCSP responders are NOT guaranteed to accept SHA2 algorithms, and depends on the deployment's configuration. We have encountered an issue where an OCSP responder configured for only SHA1 will deny entry to a system when SHA256 is not enabled. Looking thru the RFC, I don't see mention of a responder to be required to answer for all hash types.
I'm sure we're not the only ones noticing this change has broken PKI authentication, and it may be prudent for p11_child to attempt a fallback back down to SHA1 if SHA2 OCSP request fails unauthorized.
Also, I've not been able to locate the language in FIPS140 that bans SHA1's use. Could you please refer to this in the standards document?
"""
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672831519
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
karlg100 commented: """ @sumit-bose / @alexey-tikhonov
I just updated the RH bugzilla ticket, but I'll post the same here.
@alexey-tikhonov -
Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
OCSP responders are NOT guaranteed to accept SHA2 hash types, and depends on the deployment's configuration. We have encountered an issue where an OCSP responder configured for only SHA1 will deny entry to a system when SHA256 is not enabled. Looking thru the RFC, I don't see mention of a responder to be required to answer for all hash types.
I'm sure we're not the only ones noticing this change has broken PKI authentication, and it may be prudent for p11_child to attempt a fallback back down to SHA1 if SHA2 OCSP request fails unauthorized.
Also, I've not been able to locate the language in FIPS140 that bans SHA1's use. Could you please refer to this in the standards document?
"""
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672831519
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """
@alexey-tikhonov -
Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
OCSP responders are NOT guaranteed to accept SHA2 hash types, and depends on the deployment's configuration. We have encountered an issue where an OCSP responder configured for only SHA1 will deny entry to a system when SHA256 is not enabled.
Could you please check if using `ocsp_dgst=sha1` helps?
Looking thru the RFC, I don't see mention of a responder to be required to answer for all hash types.
I'm sure we're not the only ones noticing this change has broken PKI authentication, and it may be prudent for p11_child to attempt a fallback back down to SHA1 if SHA2 OCSP request fails unauthorized.
But that would be against our intent.
Also, I've not been able to locate the language in FIPS140 that bans SHA1's use. Could you please refer to this in the standards document?
I think strictly speaking SHA-1 is still allowed for a limited uses (like `HMAC-SHA-1`) by FIPS 140-2, but intention is clearly to ged rid of it. Quick search yields things like https://www.stigviewer.com/stig/application_security_and_development/2017-12... : ``` While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this algorithm, DoD PKI policy prohibits the use of SHA1 as of December 2016. ``` etc.
For this reason it was made configurable, defaults changed to more secure option, but sha-1 is still allowed to be configured explicitly. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672847772
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
karlg100 commented: """
@alexey-tikhonov - Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2 OCSP responders are NOT guaranteed to accept SHA2 hash types, and depends on the deployment's configuration. We have encountered an issue where an OCSP responder configured for only SHA1 will deny entry to a system when SHA256 is not enabled.
Could you please check if using `ocsp_dgst=sha1` helps?
Yes, we have proven that manually configuring the client does work around the issue. It seems however that other implementations will fallback. I do realize some of this is openSSL behavior, but this change may have broken existing implementations, especially already deployed RHEL8 systems. I'm actually ok leaving this default as I'm working with those needed on my side to advance OCSP forward, but mostly an FYSA based on the RH Bugzilla comment stating that OCSP responders must have SHA2 enabled and ok to change the default, which is an incorrect assumption.
Looking thru the RFC, I don't see mention of a responder to be required to answer for all hash types. I'm sure we're not the only ones noticing this change has broken PKI authentication, and it may be prudent for p11_child to attempt a fallback back down to SHA1 if SHA2 OCSP request fails unauthorized.
But that would be against our intent.
Also, I've not been able to locate the language in FIPS140 that bans SHA1's use. Could you please refer to this in the standards document?
I think strictly speaking SHA-1 is still allowed for a limited uses (like `HMAC-SHA-1`) by FIPS 140-2, but intention is clearly to ged rid of it. Quick search yields things like https://www.stigviewer.com/stig/application_security_and_development/2017-12... :
While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this algorithm, DoD PKI policy prohibits the use of SHA1 as of December 2016.etc.
For this reason it was made configurable, defaults changed to more secure option, but sha-1 is still allowed to be configured explicitly.
Thank you for the link. We were aware of the DoD Memo for the rollout, but the STIG info is helpful guidance for infrastructure admins.
"""
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672886466
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """
Could you please check if using `ocsp_dgst=sha1` helps?
Yes, we have proven that manually configuring the client does work around the issue. It seems however that other implementations will fallback. I do realize some of this is openSSL behavior, but this change may have broken existing implementations, especially already deployed RHEL8 systems.
I'm actually ok leaving this default as I'm working with those needed on my side to advance OCSP forward, but mostly an FYSA based on the RH Bugzilla comment stating that OCSP responders must have SHA2 enabled and ok to change the default, which is an incorrect assumption.
You are right, there are some deployments that were broken.
But I think it's totally fine that admins will be made aware that their OCSP server uses (near to) deprecated SHA-1 and they need to configure this explicitly.
"""
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-672962573
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
dpward commented: """ @alexey-tikhonov I think you are getting a few things confused here.
The FIPS requirement you referenced is for **cryptographic** hashes. This pull request did not change _cryptographic_ hashing behavior. Instead, it changed how an OCSP request _identifies_ a certificate that the OCSP responder needs to validate. That is independent of which algorithm is used to _cryptographically sign_ the OCSP response that is returned (or optionally, the OCSP request that is sent).
In addition, some OCSP responders (including Microsoft's) implement RFC 5019, which places additional restrictions on how OCSP is used. In particular, [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 the change here actually breaks compatibility with RFC 5019 responders out-of-the-box. The fact that this hashing algorithm is configurable in SSSD is fine, but the default should be changed back to SHA-1. Again, this is not a _cryptographic_ hash.
---
As an aside, you might wish to add the [Preferred Signature Algorithms extension](https://tools.ietf.org/html/rfc6960#section-4.4.7) to outgoing OCSP requests instead. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
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.
The change made here did not affect _cryptographic_ hashes. An OCSP request message needs to specify the issuing CA for the certificate in question. Rather than send the full distinguished name in plain text, it is sent in the form of a hash (think `sha1sum`). This change made it possible to choose the hash algorithm.
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. Again: this is not being used to produce a _cryptographic_ hash.
(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
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 a (plain text) string, the hash of the DN is sent instead. 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
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
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
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
sumit-bose commented: """ Hi @dpward ,
thanks for pointing to https://tools.ietf.org/html/rfc5019#section-2.1.1, so the default should be switched back to SHA-1. I will check if this works as expected even if the client is switched into FIPS mode.
@alexey-tikhonov, shall we reopen this ticket or do you prefer a new one?
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-673889511
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.
...
However, the hashes that are affected by this pull request are not used in a _cryptographic_ manner.
We [didn't confuse](https://github.com/SSSD/sssd/pull/837#issuecomment-506404695) those.
But intention (perhaps wrong) was to get rid of sha-1 as much as possible as its widespread deprecation feels anticipated.
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).
Thanks for the reference. This is a strong point.
The issuer hash algorithm should remain a configuration option, but the default should be reverted to SHA-1, which satisfies RFC 5019.
Seems so.
@simo5, do you agree? """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-674802133
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
dpward commented: """
But intention (perhaps wrong) was to get rid of sha-1 as much as possible as its widespread deprecation feels anticipated.
@alexey-tikhonov Could I kindly point to [NIST SP 800-131A](https://www.nist.gov/publications/transitioning-use-cryptographic-algorithms...) (March 2019)? According the abstract, it provides the "specific guidance for transitions to the use of stronger cryptographic keys and more robust algorithms".
Please see Table 8 and especially the text below it:
SHA-1 for non-digital signature applications: For non-digital-signature applications, the use of SHA-1 is **acceptable** for applications that do not require collision resistance. SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256: The use of these hash functions is **acceptable** for all hash function applications. SHA3-224, SHA3-256, SHA3-384, and SHA3-512: The use of these hash functions is **acceptable** for all hash function applications.
There is no indication here of SHA-1 being deprecated for *non-digital signature applications*. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-674963727
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
simo5 commented: """ @alexey-tikhonov if there is a compatibility issue, I would certainly allow sah-1 to be used, but perhaps with an easier way to flip it off in future.
Alsthough 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).
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. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-674968818
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
simo5 commented: """ @alexey-tikhonov if there is a compatibility issue, I would certainly allow SHA-1 to be used, but perhaps with an easier way to flip it off in future.
Alsthough 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).
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. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-674968818
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
simo5 commented: """ @alexey-tikhonov if there is a compatibility issue, I would certainly allow SHA-1 to be used, but perhaps with an easier way to flip it off in future.
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).
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. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-674968818
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-profil...
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
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-profil...
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
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-profil...
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
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """
@alexey-tikhonov, shall we reopen this ticket or do you prefer a new one?
Ok, I'll take care of this. """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-675084120
URL: https://github.com/SSSD/sssd/pull/837 Title: #837: p11_child: make OCSP digest configurable
alexey-tikhonov commented: """ I reopened #5002 and opened PR #5280 """
See the full comment at https://github.com/SSSD/sssd/pull/837#issuecomment-675465646
sssd-devel@lists.fedorahosted.org
-
alexey-tikhonov -
dpward
-
jhrozek
-
karlg100
-
simo5
-
sumit-bose