0

I'm looking into Google KMS and the possibility of signing documents digitally and verifying them with Google Cloud. Keys are stored in a HSM (Hardware Security Module) in a managed Google Cloud.

I have been able to successfully do the above but wanted to also use a certificate from Certificate Authority.

However, I'm confused to where this certificate needs to be stored. After buying it, does it need to be inside HSM? (Google KMS does not have any API endpoint for that). Can't find any documentation about these requirements.

Or can it be stored locally and loaded from the filesystem?

Looked at this: PDF document signing with Google KMS and Entrust certificate and it seems it can be loaded from the filesystem (using Entrust certificate).

Pedro Franco
  • 53
  • 6
  • Can you clarify what you mean by "but wanted to also use a certificate from Certificate Authority"? – sethvargo Apr 15 '20 at 14:05
  • It is necessary a trust provider for signature compliance. Uncertain on how these certificates should be stored using a Google Cloud KMS/HSM workflow. Is it possible to install these certificates in HSM using Google KMS API? Or is there any example of how to handle this scenario? Or these certificates can stored locally? – Pedro Franco Apr 15 '20 at 14:52
  • You can import _keys_ using Key Import (https://cloud.google.com/kms/docs/importing-a-key), but that only works with specific key formats. Could you store the certificate in Secret Manager (https://cloud.google.com/secret-manager) instead? – sethvargo Apr 15 '20 at 15:20
  • You would normally keep the signing key in KMS or in Cloud HSM. Then the certificate itself you would store in your own file system. The certificate doesn't need to be kept secret. – Tim Dierks Apr 15 '20 at 16:14
  • Ok from what I'm understanding then if I buy a certificate from one of the providers of Document Signing Certificates (e.g. https://helpx.adobe.com/acrobat/kb/approved-trust-list1.html), it is sufficient to store the certificate in my own file system (server) or a certificate manager and keep the signing keys in the KMS system. – Pedro Franco Apr 15 '20 at 19:38
  • Yes, that's right. You would either: 1. create a key in KMS, submit the public key for certification, and keep the private key in the KMS; or 2. generate the key on a workstation, create a certificate signing request, and import the private key into KMS. (#2 is easier on Cloud KMS right now due to tooling issues with PKI tools). In either case, the certificate can be stored anywhere, it's not confidential. – Tim Dierks Apr 25 '20 at 20:17
  • What tooling issues are you referring to? @TimDierks. I'm most probably going for the 1st option. – Pedro Franco Apr 26 '20 at 21:08
  • 1
    We don't yet have the API layer to integrate KMS APIs with the open-source tooling (like OpenSSL) which people usually use to create the certificate request, etc., in the formats needed by CAs. So to do this requires a non-trivial chunk of code to prep and sign the certificate request, but it may be easier depending on what libraries/tools you have available. – Tim Dierks Apr 27 '20 at 22:51
  • Hi @TimDierks, do you know if that tooling is going to be added at any point? – Ben Coughlan May 13 '21 at 17:53
  • @BenCoughlan can you email us at cloudkms-feedback@google.com and I'll use that to poke at the eng and product management team? This is still desired but I don't have complete status on exactly how close it is. Thank you! (I was discussing this use case with our product lead this week; it is not forgotten.) – Tim Dierks May 16 '21 at 20:15

0 Answers0