In the mTLS + token scenario, how does the server establish trust in client in the first place? Once you've done that, everything else is easy enough - the server could sign a cert for the client to use with mTLS, or you could do the RFC 8705 thing as described here, or any number of things. But that initial trust bootstrap is the hard part!
Are you advocating something like generating a private key on a TPM and submitting a CSR over a trusted channel (which might be out of band, e.g. a meatspace meeting; basically however those bearer tokens get passed around today)? I could get behind that, but I think it'd be less confusing to explicitly say that, and to talk about exactly where the trust is rooted.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2022-05-16 04:27 pm (UTC)In the mTLS + token scenario, how does the server establish trust in client in the first place? Once you've done that, everything else is easy enough - the server could sign a cert for the client to use with mTLS, or you could do the RFC 8705 thing as described here, or any number of things. But that initial trust bootstrap is the hard part!
Are you advocating something like generating a private key on a TPM and submitting a CSR over a trusted channel (which might be out of band, e.g. a meatspace meeting; basically however those bearer tokens get passed around today)? I could get behind that, but I think it'd be less confusing to explicitly say that, and to talk about exactly where the trust is rooted.