age-plugin-yubikey support for RSA keys -- specifically, CAC ones

[matthewsht]

In Bug #39, it was said:
"We will therefore not support ssh-rsa keys (which don't match what the plugin's protocol requires) and cannot support ssh-ed25519 keys (which use a curve that YubiKey's PIV applet doesn't even support)"

I wanted to ask politely if this requirement for not supporting ssh-rsa keys could be reconsidered.

US federal government issues smartcards/CAC cards/PIV cards (various names are used) and at the moment they have RSA keys on them (an auth key, an encrypt key, etc).

For us, its either impossible or strongly discouraged to attempt to add a key of any type - and it would be EXTREMELY useful to be able to use the existing encryption key on the card (rsa) with age through this plugin.

However, I'm not a card expert and certainly not an age expert - so I don't know if there are technical details of what I just asked that make it impossible.

[str4d]

This is an interesting request, for a few reasons:

• The first version of this plugin that I wrote did use RSA keys (because that's what I had pure-Rust crates for at the time). However, once I had P-256 implemented, we decided to focus solely on the design with better UX (P-256 enables significantly shorter recipients and identities, and having a single). There was some discussion about this on the old mailing list.
• However, I doubt that we can support ssh-rsa keys specifically, as usually SSH applets on hardware tokens only implement authentication (which is what SSH needs), and do not expose the raw operation we need for encryption. So even if we did have RSA PIV support, it would likely need to be for separate keys. But I think you're referring to RSA PIV keys, not ssh-rsa support (even though you reference UX: How to upload my SSH key to YubiKey? #39).
• age-plugin-yubikey explicitly only operates using the 20 "retired" slots, in order to not collide with any usage of the four main slots (the auth key, encrypt key etc. that you refer to), because those slots have specific interpretations that we didn't want to collide with. My first draft of the plugin did allow the KeyManagement slot to be used (which AFAICT from the PIV specs is the only one that is supposed to be used for encryption), but that was removed pretty early on.

The only officially supported hardware token for this plugin is YubiKeys, so focusing specifically on a smooth UX for them will always be the primary goal. However, I'm not adverse to having specific functionality that serves more constrained PIV environments. This functionality would necessarily be behind default-off feature flags, as it wouldn't be generally interoperable (and thus would need both the encrypting and decrypting users to be set up to use it, which means they can compile age-plugin-yubikey with the necessary feature flags).

My main question is, what precisely are you asking me to implement? Would it be sufficient to have a feature flag that enabled an RSA-2048 key in the KeyManagement slot to be used as an identity?

[matthewsht]

"think you're referring to RSA PIV keys"... I'm not entirely sure. I know all the keys on our smartcards are RSA.
Using a reader app, I know that Slot 9a is our "PIV Authentication" key, slot 9d is the "Key Management" or encryption key.

From your point 3 "using the 20 retired slots" I know without asking that the powers that be would not be happy if we added anything (or changed anything) to the cards.

I think I'm asking specifically for the "KeyManagement" / encryption key thats already on the card to be used for an identity under some kind of feature flag.

I appreciate you considering this request - government/ CAC card users want to get off of GPG as much as anyone else.

[str4d]

Hmm, I'm thinking more about this, and am less certain that this should be part of age-plugin-yubikey. The feature sets are very divergent:

• RSA instead of P256.
• Slot 9d instead of the 20 retired slots.
• CAC cards instead of YubiKeys (yes they both speak PIV, but I'm not convinced that the two will be completely interoperable).
• The machinery for generating new identities would go unused (and in fact need to be gated off for safety):

  I know without asking that the powers that be would not be happy if we added anything (or changed anything) to the cards.

I think my overall concern is that it would make the codebase more brittle, as changes to the main YubiKey "face" would need to be tested against the minor CAC "face" (and I do not have CAC devices for testing).

I'm instead contemplating creating an age-plugin-cac specifically for this use case. It would mean duplicating some of the general scaffolding, but I think it's likely a safer approach. The UX would initially be based on age-plugin-yubikey but it could then be tailored for the environment and constraints of CAC holders. I'd also probably use the yubikey crate just to get things off the ground, but with the expectation that a CAC-specific PIV crate may need to be developed.

[matthewsht]

Given the .... oddities of CAC in general, I think this is a logical and practical idea. Thank you for continuing to consider the needs of us CAC holders.

…

-- Hunter Matthews Scientific System Engineer [C] NIH/National Human Genome Research Institute ***@***.******@***.***> | (919) 491-2124 On Dec 30, 2022, at 8:17 AM, str4d ***@***.******@***.***>> wrote: Hmm, I'm thinking more about this, and am less certain that this should be part of age-plugin-yubikey. The feature sets are very divergent: * RSA instead of P256. * Slot 9d instead of the 20 retired slots. * CAC cards instead of YubiKeys (yes they both speak PIV, but I'm not convinced that the two will be completely interoperable). * The machinery for generating new identities would go unused (and in fact need to be gated off for safety): I know without asking that the powers that be would not be happy if we added anything (or changed anything) to the cards. I think my overall concern is that it would make the codebase more brittle, as changes to the main YubiKey "face" would need to be tested against the minor CAC "face" (and I do not have CAC devices for testing). I'm instead contemplating creating an age-plugin-cac specifically for this use case. It would mean duplicating some of the general scaffolding, but I think it's likely a safer approach. The UX would initially be based on age-plugin-yubikey but it could then be tailored for the environment and constraints of CAC holders. I'd also probably use the yubikey crate just to get things off the ground, but with the expectation that a CAC-specific PIV crate may need to be developed. — Reply to this email directly, view it on GitHub<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstr4d%2Fage-plugin-yubikey%2Fissues%2F62%23issuecomment-1367915274&data=05%7C01%7Chunter.matthews%40nih.gov%7Caf0ad7f3161248ffc47a08daea68420d%7C14b77578977342d58507251ca2dc2b06%7C0%7C0%7C638080030768471411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JEDCsKuoT8rqv6UDMVxN%2BCdzyz%2FtC9UufLOULn6MvR0%3D&reserved=0>, or unsubscribe<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FATFEQQYES4K62Q34R632IA3WP3OH3ANCNFSM5UDIJGSQ&data=05%7C01%7Chunter.matthews%40nih.gov%7Caf0ad7f3161248ffc47a08daea68420d%7C14b77578977342d58507251ca2dc2b06%7C0%7C0%7C638080030768471411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w7%2B9DW4Jd6ZKpBaqMGRipYaXhf1HYUNlx6Y4dJh22Ww%3D&reserved=0>. You are receiving this because you authored the thread.Message ID: ***@***.***> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and are confident the content is safe.