Decrypting with multiple identities

[mntn-xyz]

I'm having the same issue as the age-plugin-yubikey user here: str4d/age-plugin-yubikey#178

I set up multiple recipients and identities, with the goal of having backup keys. Unfortunately, if the first key in the list of identities is not present, decryption fails. Ideally it would decrypt as long as one valid key is present.

At first I thought it was an issue with passage, but now I see that it's a consequence of how age handles multiple identities. It tries each identity one-by-one. What this means in practice is that if the first identity reports an error, it quits without trying other identities.

I'm not clear that there is a good solution for this, but I'm leaving it here as a placeholder in case a solution can be devised. It seems like calling age with multiple identities shouldn't fail if an identity is not available, but I'm not sure how one would even determine this since FIDO2 keys of the same model will "look alike" until after you enter the PIN.

This may just be an issue in the age spec which implies that this is still a "TODO" item: https://github.com/C2SP/C2SP/blob/3883452af70c6ed2a2de348d4634d814cab03545/age-plugin.md?plain=1#L475

[olastor]

@mntn-xyz Thanks for raising this issue. It's a somewhat complicated problem especially for this plugin since there is no device identitfier.

At first I thought it was an issue with passage, but now I see that it's a consequence of how age handles multiple identities. It tries each identity one-by-one. What this means in practice is that if the first identity reports an error, it quits without trying other identities.

Age actually tries them in order without failing early, but for plugins it only does so if the error is age.ErrIncorrectIdentity. In this case, it just got the fido2 error which is "no credentials" if the credential that is tried wasn't created with the current token. I fixed that in 0dc32cf . It might not be released immediately though because I just merged a refactoring which is not fully ready for release yet. That probably doesn't solve the entire problem though, which is more complicated and maybe more a specification question (e.g. see this comment).

Not sure if for fido2 there will ever be a good way of knowing it's the correct token without doing an assertion (entering pin, touching token) for every candidate identity/stanza. Maybe there could be short user-defined nicknames included in the identity/stanza and the user can choose. That'd require the mentioned TODO comment above to be realized, though.