Morten LinderudHas there been any work to issue ssh certificates through ACME?
You can pass custom content-type headers, so it should be possible to jam it inn there?
hslatman@Foxboron I hacked on it a bit, and have a partial implementation (for host certs, primarily). The main decision is what challenge channel to use: do something custom on the SSH level/protocol, so that the CA can verify the SSH server directly (similar to HTTP/TLS challenges), or go “out-of-band” and verify the SSH host is the same as e.g. HTTP host (similarities to DNS challenge). The latter is simpler to implement, and probably what you are thinking of too.
@Foxboron there is some standardization work on ACME for client certs through SSO and email, and corresponding challenge channels. With those in place, and the out-of-band verification, SSH client certs could also be issued.
Attesting the SSH key could also be integrated, but there’s still the mapping from TPM key to user/host identity in that case.
@hslatman
I don't see why this can't be done through `device-attest-01`?
Why would you need a new scheme when we just only really want another format?
@Foxboron not saying it can’t be done, but you’ll still need the mapping from TPM EK to principals to issue for.
With ACME, generally the point is to verify ownership over the domain/ip (identifier in general). Translating that to SSH requires verifying ownership of a principal. With device-attest-01 the attestation certificate can carry those (after verification by the attestation CA), and changing the accept header (or something like that) can be sufficient.
@Foxboron what I’m trying to say is that for this use case (and device-attest-01 in general), ACME is primarily used as the flow/protocol, and less so for directly verifying the ACME identifiers (which is basically delegated to the attestation CA) to issue for.
Another approach would be to verify the identifiers as in standard ACME, and include additional signed proofs (attestations, e.g. key residency; origin) to carry additonal facts for the CA to include in its verification.
@hslatman
Right, this makes sense! Thanks for writing it up.
I'll try and think this through a bit more, but the principal<->EK binding seems tricky. It might be possible to have the kernel or a privileged process log something we trust that we can tie with a signed session of sorts?
@Foxboron yeah, that could work: have a trusted backchannel providing the required context to verify the principals (to a sufficient extent). To remain close to ACME, that would be verified by the attestation CA, resulting in an attestation certificate with valid proncipals, which can then be ised with device-attest-01.
Tou might also be interested in the acme-rats draft. That’ll require more implementation work, and probably some more guesswork considering its current state 😅
@hslatman
I tried reading up on rats and I couldn't understand anything 😕
But that's generally how I feel anytime I watch a presentation on Confidential Computing.
@hslatman
okay, one "shortcut" could be to enroll the device into the attestation/identity CA with the principal <=> EK association.
It's less nice, but removes parts of this from the issue?
@hslatman
But then you are still back at the original issue, adding a content-type so acme gives back an ssh-cerificate serialized from the crs sent from the client.
And this seeeemmmmsss not that hard to solve?