Add support for cached UIF

[robin-nitrokey]

The OpenPGP 3.4.1 spec reserves two UIF flags for a cached mode (03 and 04, see § 4.4.1). We should consider implementing this mode.

AFAIK only Yubikeys implement this at the moment:

• https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html#_touch_cache
• https://github.com/Yubico/yubikey-manager/blob/a767ecaf26a18871c3222dacbae0906d8d67f05c/ykman/_openpgp.py#L99-L100

[tcanabrava]

hit this today.
I package KDE apps for Arch linux and have a nitrokey 3c NFC.
the KDE apps are around 250
plus around 80 libraries and plasma with ~60 packages. that's around 400 packages to manage, 400 times I need to touch the physical device twice (one for the git commit, one for the signing of the package),
so ~800 times finger-going-up-and-down.
Might look like a small problem but it's a really tedious process that can go wrong if I don't touch the device on a timely manner, but because of the amount of touches, it's hard to get it completely right.

Is there any way I can help to implement this?

[sosthene-nitrokey]

For this use case it seems pretty necessary to have a way to avoid repeated user confirmation.

This is only a temporary cache. It's not standard so we have some leeway regarding how we would implement it.
If we follow the Yubikey version of this feature, the cache is only for at most 15 seconds, which I don't think would solve the case of having to perform hundred of signatures this way.

Touch confirmation is not enabled by default and can be disabled (unless it was set to permanently enabled), is there a specific reason that disabling UIF and re-enabling after having signed all the packages is not an option?

[tcanabrava]

I think my fav. option (and I'm unsure if this is possible) is to have away for the cache to work on child processes of the process that triggered the cache.
the reason is that the builds happen online and if I disable touch confirmation and for any reason my computer is exposed I could potentially sign things I didn't mean to.
Now, if there was a way to use the touch verification for a process, and that process hold the lock, any children of that process would be safe to sign, and things outside of that process would require touch.

[sosthene-nitrokey]

My understanding is that it is possible to know clear the cache if the process that uses the device changes when using pcscd directly (not gpg I'm afraid, because gpg-agent keeps the connection opened and does not re-create it when a new process connects to it). But assuming a compromised host I don't know how far it is to compromise a running pcscd too.

This would require having an cache UIF setting with unlimited duration for a given session. Since the UIF configuration mechanism in the standard does not give a good way to configure such a timing this would have to be the only option, and I don't like the idea of having a user interaction cache that last infinitely.

Maybe we could add a custom extension command that gives you an option to validate user presence for a given number checks in advance. These "buffered" checks could be discarded if the process connecting changes.