Closed dwmw2 closed 1 year ago
thanks for the pointer.
yeah, i'm aware of the wrapped format which as you cited, i used with openssl (eg for nginx+ssl
this repo is pretty much scratchpad for tinkering w/ stuff only (i.e nobody should use this in prod as-is)...but will try to find sometime to add it in (since you've got it working, i'll cite your repo and attribution for any of the structs i use).
on the topic of AWS, apart from signing, you maybe interested in HMAC based auth (i.,e you can save the access secret to tpm (or import or duplicate, and then use it for authentication.
yeah, i'm aware of the wrapped format which as you cited, i used with openssl (eg for nginx+ssl
Nice, but I hate that you have to do anything except give nginx the /root/tpm_certs/tpm.key
as its private key file. All that messing around with openssl.cnf and explicit OpenSSL engine stuff is not something any user should ever have to do. Is there already a bug open with nginx for that?
this repo is pretty much scratchpad for tinkering w/ stuff only
Background: http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
tl;dr: We should stop hating our users and making life hard for them. This stuff should Just Work™ — whether they give us any sensible kind of file, or just a PKCS#11 URI in place of a filename, or whatever.
The crypto libraries seem to actively make it hard for applications to get that right. It takes hundreds, perhaps even thousands of lines of code, to make an application which simply conforms to what I've written there, which I consider best practice.
Perhaps we should take something based on your code and turn it into a standard library for "give me a crypto.Signer and a cert based on (certificateId string, privateKeyId string)
" and stop expecting application authors to do all the work?
on the topic of AWS, apart from signing, you maybe interested in HMAC based auth (i.,e you can save the access secret to tpm (or import or duplicate, and then use it for authentication.
Nice. Duly heckled at the PKCS#11 support there :)
Now, can we get to a mode where role credentials for an instance are not presented in plain text through IMDS but are instead presented as a TPM-loadable key for the NitroTPM of that instance?
agree, its incredibly tedious to do anything with all this
re: simplify nginx, i'm not sure if there is any bug to make it easier (either cognitively or convenience is the number of specific steps require).
re: pkcsURI for the aws_hmac stuff. you're right; i'll reply on that issue/repo. that stuff i really should add in; i'll work on that shortly.
The idea for the aws_hmac was really to allow users ouside of AWS environment to securely stash their creds (vs in a file). I don't know much about nitro so i can't really comment there.
Ideally, applications should silently accept a PEM file containing a
-----BEGIN TSS2 PRIVATE KEY-----
and use the TPM for it without asking the user to do anything more.This is the file type supported by GnuTLS and the two OpenSSL engines, as well as other things like OpenConnect. It's documented here
Please consider supporting this format. There's example code at https://github.com/dwmw2/rolesanywhere-credential-helper/blob/tpm/aws_signing_helper/tpm_signer.go which is Apache v2 licensed and you're welcome to use.