Unable to read an encrypted email using renewed tokens
Steps to Reproduce:
1. Enroll a smartcard token. 2. Send an encrypted email using the certs on the smartcard 3. Renew the token with the following steps Format and enroll a smartcard token Send an encypted and signed email using the certificates on the token. Change the policy of the token to RENEW=YES on the TPS Web UI. Enroll the token again 4. Try to read the sent in step 2 using the renewed token
Actual results:
Unable to decrypt the email
Expected results:
Read the email successfully
Additional info:
The following was Jack's finding after initial investigation: I've duplicated the problem on my box. The renewed certs appear to be fine. They are using the same keys as before and their attributes are the same as the old ones. Also the private key appears good on each one. The issue appears to be that the smime code in NSS , when trying to decrypt the email, is searching for a cert with the same issuer and serial number as the one that encrypted it. It should have another means to find the cert.
commit 1efc001db20afc34b7353f6d2b114593eb761b90 Author: Jack Magne jmagne@dhcp-16-206.sjc.redhat.com Date: Wed Oct 5 18:16:35 2016 -0700
Fix for: Add ability to disallow TPS to enroll a single user on multiple tokens. #1664 This bug was previously not completely fixed where we left a loophole to allow a user to end up with 2 active tokens. This fix closes that loophole. Also: Fix for: Unable to read an encrypted email using renewed tokens. #2483 This fix provides for a new optional renewal based token policy, that allows the user to retain or recover old encryption certs for that profile, that get overwritten by the renewal process. An example is: RENEW=YES;RENEW_KEEP_OLD_ENC_CERTS=YES The default is YESk you have to explicitly set it to NO to turn it off. The second part of the policy is new. When this is set to "YES", the system will make sure the old enc cert will remain on the token. If it's missing or "NO", no such attempt will be made.
jmagne and rpattath discovered an issue during QE testing of the existing patch.
Closing due to this checkin:
Author: Jack Magne jmagne@dhcp-16-206.sjc.redhat.com Date: Tue Oct 18 15:08:44 2016 -0700
Cert/Key recovery is successful when the cert serial number and key id on the ldap user mismatches Fixes this bug #1381375. The portion this patch fixes involves URL encoding glitch we encountered when recovering keys using the "by cert" method. Also this bug addresses: Bug 1379379 - Unable to read an encrypted email using renewed tokens The URL encoding problem was affecting the proper verification of this bug. and Bug 1379749 - Automatic recovery of encryption cert is not working when a token is physically damaged and a temporary token is issued The URI encoding was also making this bug appear to fail more than it should have. There is also a minor fix to the feature that makes sure it works. This small fix is in TPSEngine.java where the constant for GenerateNewAndRecoverLast scheme is declared.
Metadata Update from @rpattath: - Issue assigned to jmagne - Issue set to the milestone: 10.3.7
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2603
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.