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.
@hslatman
I'm thinking just add `ssh-certificate` to the Content-Type in the ACME response to fetch the certificate.
Map the CSR to the ssh certificate?
It should be enough?
@Foxboron either with custom extensions, and/or some assumptions that e.g. subject / dns / email / ip are mapping to requested SSH principals can work. In step-ca we do something like that.
But keep in mind the challenge verification: for host certs you could do an HTTP/TLS/DNS challenge, but then the SSH server (or some orchestration) has to serve the challenge 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?
@hslatman
So we should have systemd (or the kernel) log the hostname into the tpm eventlog. That way you can have the information available during attestation.
We should include system username, and maybe a list of available users, as well.
Then you enroll a device with an attestation of information relevant to establish known principals.
Associating principals and arbitrary roles to the EK needs to belong to the identity/attestation CA anyway.
Doesn't this get us closer to solving this?
@hslatman
This doesn't solve the ACME case completely, but maybe acme should just support ssh certificates as an output type from a CSR, and the principals should be left out of the process and delegated to the attestation part. Similar to how device-attest-01 is defined anyway.
This doesn't solve the ACME case completely, but maybe acme should just support ssh certificates as an output type from a CSR, and the principals should be left out of the process and delegated to the attestation part. Similar to how device-attest-01 is defined anyway.
@Foxboron for device-attest-01 (and acme-rats), leaving those out makes sense. The attestation certificate can carry the allowed principals, with validation having been delegated to the attestation CA (or rather, the verifier role in RATS). The ACME CA is a relying party in this case.
For other challenge types, the principals can still be validated directly.
There’s no standard SSH cert request, but for now depending on an X509 CSR can work.