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.
@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.