Merging ssh-key and sshcerts

[obelisk]

Heyo,

So I've been working on SSH Certificate parsing in pure rust for a while and might have some features that we could port over. I would also love to be able to get feedback on the code I've been writing for the past 2 years.

https://github.com/obelisk/sshcerts

Ultimately it would probably be best if we could port all the functionality for dealing with SSH certificates over then I can retire that crate and build more specific ones for the Yubikey portions.

[tarcieri]

Hello!

I just want to say that this is the first time I’ve seen your crate. It definitely looks like we’re working on similar goals.

[obelisk]

I think the biggest thing we could port over is the support for signing with FIDO keys. I use ctap2-hid-fido as the backend for support there as I had a lot of issues with authenticator-rs with CTAP2.1 and Ed25519 keys. However, I understand that might be a tough sell as it pulls in quite a large dependency tree.

[tarcieri]

That sounds interesting.

As it were, my original plan was to add ssh-key as a dependency to yubikey and yubihsm. Integrating that way probably makes the most sense for yubihsm, as it has some built-in features for SSH CAs (including a certificate templates feature which acts as a sort of ACL constraining what types of certificates are allowed)

I could see going the other way for something like ctap2-hid-fido, and potentially yubikey as well.

[obelisk]

The YubiHSM does support SSH Certificates buts we can build SSH certificate support on regular Yubikeys as well (though there are some algorithm limitations such as lack of Ed25519 and NISTP521).

I was honestly quite annoyed with the fact that Yubico only provided APIs for SSH certificates on the HSM and that was where the Yubikey portion of sshcerts came from! :p

[obelisk]

sshcerts is the primary dependency of my Rustica project (https://github.com/obelisk/rustica) which is my automated SSH certificate issuance system. Thus I'll generally be looking through the lens of that project when thinking about features to port or reimplement :)

[tarcieri]

#169 implements some similar functionality

[obelisk]

A lot of the missing functionality is there in sshcerts we can look at porting over (mostly Ed25519 support which is my primary focus).

I've also got the Mozilla backend almost fully integrated as well so you can choose what you'd like to pull in dependency tree wise. I've personally found dealing with CTAP to be very time consuming and difficult so if more people can benefit from it we should see what can be done to port it over here.

Do you have a strong opinion on ctap2_hid vs authenticator-rs?

[tarcieri]

I've personally found dealing with CTAP to be very time consuming and difficult so if more people can benefit from it we should see what can be done to port it over here.

Awesome!

Do you have a strong opinion on ctap2_hid vs authenticator-rs?

authenticator-rs looks much more widely used and actively maintained

[obelisk]

@tarcieri If you could take a look at: https://github.com/obelisk/sshcerts/tree/moz_auth_2023/src/fido

Let me know what you think we might be able to move over from there. The CTAP2 code is more mature and has prove to be very stable but I agree with you, authenticator-rs is probably a good long term play.

Also I'm self taught in Rust so I would welcome any reviews on how to better structure the project, either in issues or pull requests so long as functionality is the same. The goal of sshcerts was to provide a solid foundation for Rustica allowing provably backed hardware keys at scale, but as long as ssh-key provides the same functionality, I'm happy to help maintain here (time permitting) instead of in sshcerts :)

[obelisk]

I'm about to cut over the default backend implementation for dealing with authenticators to authenticator-rs. Let me know if there is anything I can help with because this is also desired for cargo: rust-lang/cargo#11577