Add support for Tink keyset signer #563
Conversation
haydentherapper
requested review from
roger2hk
and removed request for
a team
|
Reopening, ref to #282 for the previous discussion. |
This PR adds support for in-memory signing using a Tink keyset. The keyset is encrypted with a key-encryption-key stored in GCP KMS. The key is decrypted on startup and loaded into memory. This uses a utility to unpack the keyset into a crypto.Signer so that it can be used to sign certificates. This also validates that the key is an ECDSA P-256 key as per RFC 6962, since Tink supports many key types. Signed-off-by: Hayden <[email protected]>
haydentherapper
force-pushed
the
add-tink-signer
branch
from
9286b5a to
76ff1a7
Compare
|
Bumping this, is there any interest in supporting this at this time? |
| // primary key. | ||
| // | ||
| // NOTE: Tink validates keys on [keyset.Handle] creation. | ||
| func KeyHandleToSigner(kh *keyset.Handle) (crypto.Signer, error) { |
There was a problem hiding this comment.
To avoid opening the objets and doing curve operations, do you think that it would be possible to wrap an object around the keyset.Handle, which itself would implement crypto.Signer, and calls Tink's methods directly?
There was a problem hiding this comment.
I mentioned this in #282 (comment), the issue is that keyset.Handle takes in the pre-image while crypto.Signer takes in the digest. I'd like to simplify this, but we'd need Tink to implement a prehashed signer.
|
Sorry that this is taking a while - Secure Key management is on the roadmap for Beta, we just haven't had the time to get to it properly yet. We'll get to this before the end of Q4 / Q1 as we get closer to Beta. There are a few sticking point that we'd like to resolve before making a final decision on whether we need Tink, or whether we can simply use the standard Go crypto library primitives. Specifically, we'd like to do a proper tradeoff analysis given that I don't necessarily think TesseraCT needs some of Tink's star features as I understand it: keysets, key rotation, multi-language. At the moment, TesseraCT also uses two type of key APIs internally (to sign checkpoints, and to sign SCTs), so I'd like to take this as an opportunity to clean things a bit before adding a third API. In the meantime, I've popped a comment on something that could maybe be improved if we merged that PR. |
2 participants
This PR adds support for in-memory signing using a Tink keyset. The keyset is encrypted with a key-encryption-key stored in GCP KMS. The key is decrypted on startup and loaded into memory. This uses a utility to unpack the keyset into a crypto.Signer so that it can be used to sign certificates. This also validates that the key is an ECDSA P-256 key as per RFC 6962, since Tink supports many key types.