Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically verify cached pin and retry general auth on sw = 6982 #338

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

qpernil
Copy link
Contributor

@qpernil qpernil commented Dec 2, 2021

No description provided.

@qpernil qpernil self-assigned this Dec 2, 2021
@qpernil
Copy link
Contributor Author

qpernil commented Dec 2, 2021

Different approach to problems with always-auth keys - automatically verify cached pin and retry general-authenticate

@qpernil qpernil changed the title automatically retry general auth Automatically retry general auth on sw = 6982 Dec 2, 2021
@qpernil
Copy link
Contributor Author

qpernil commented Dec 2, 2021

The trouble with this approach is that it is in the library, and hence affects all usage, not just piv-tool

@qpernil qpernil changed the title Automatically retry general auth on sw = 6982 Automatically verify cached pin and retry general auth on sw = 6982 Dec 2, 2021
@qpernil qpernil force-pushed the auto-verify-cached-pin branch from 0801ef2 to 69a21a3 Compare December 2, 2021 16:21
@mouse07410
Copy link

I like this approach very much, as it returns the decision whether to (re-)authenticate, back to where it belongs - to the token itself.

@qpernil qpernil force-pushed the auto-verify-cached-pin branch from 69a21a3 to f614661 Compare December 21, 2021 17:07
@qpernil
Copy link
Contributor Author

qpernil commented Dec 29, 2021

I think this is probably the wrong approach after all, even if it happens to be very convenient and slots into the code very smoothly. It would essentially negate the intention with always-auth keys, with no way for the application to choose behaviour.

@mouse07410
Copy link

It is the right approach of the user wants his app to behave this way. So, using cached PIN or not should be a configurable option.

@qpernil
Copy link
Contributor Author

qpernil commented Dec 29, 2021

I think it is more in line with pkcs#11 that the application chooses what to do, after all there is support in pkcs11 to to it well from the application, either using the flag to preeemptively prompt, or to just automatically re-verify a pin it keeps in memory, or alternatively to base the behaviour on the return codes (and hope that different pkcs11 modules give the 'right' error code)

@qpernil qpernil marked this pull request as draft December 31, 2021 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants