feat(core): New cryptoProvider config

[dmihalcik-virtru]

• define new cryptoProvider config structs to support rotation with different keys
• this means the algorithm must be present
• I'm using some heuristics to maintain backward compatibility of standard crypto configs, but hsm configs must be updated
• Adds kid in response to kas_public_key
• Adds kid in key access objects produced by SDK
• Still no support in nanotdf, as we have not agreed on how/where to store the kid value in the header. See ADR: NanoTDF KAS resource locator path and key identifier #900

New Config:

server:
  cryptoProvider:
    type: standard
    standard:
      keys:
        - kid: r1
          alg: rsa:2048
          private: kas-private.pem
          cert: kas-cert.pem
        - kid: r0
          alg: rsa:2048
          private: kas-private-old.pem
          cert: kas-cert-old.pem
        - kid: e1
          alg: ec:secp256r1
          private: kas-ec-private.pem
          cert: kas-ec-cert.pem
services:
  kas:
    enabled: true
    keyring:
      - alg: rsa:2048
        kid: r1
      - alg: rsa:2048
        kid: r0
        legacy: true
      - alg: ec:secp256r1
        kid: e1

some notes:

• kid values should be unique, preferably for the lifetime of the kas host domain name
• kid values should short strings (I'd suggest maxing out at 44 characters)
• private and cert indicate the location of private key and a certificate, if available
• For hsm keys, these should be label values
• For standard keys, these should be paths to PEM files relative to the current working directory
• I've deprecated the eccertid for a new keyring parameter which describes how KAS will interpret the key. So we have two sections: server.cryptoProvider describes what keys are available, while service.kas.keyring describes how KAS uses those keys.
• We don't have a 'rotate' script yet. To do this manually, update the init-temp-keys script to use a new name/label and rerun and add the new keys to the list, updating the certid fields to point to the new values

To come:

1. nanoTDF support

[dmihalcik-virtru]

@pflynn-virtru Can you review this?

Some ideas for improvement to discuss:

• How to clean up how the default kid (rsacertid/eccertid is how we used to do it; we need at least a map from algorithm->kid somehow, either as a list or directly as a map, and we should avoid names that don't directly map to an algorithm)
• How to load KAOs (and nanotdf headers) that don't have a kid. Right now it only tries the current default so it will fail on all older TDFs (especially given they won't have keys). Previously my plan was to either try them in reverse order from oldest to newest, so we'd have to specify an order or add some other sortable field to the KeyPairInfo object, or just use the ordering from the file.

[strantalis]

@dmihalcik-virtru I opened up this issue earlier today. I think @ttschampel ran into similar issues. But it's not clear what eccertid is needed for or what it does.

Also what are your thoughts on moving the crypto provider. It has felt kind of odd living under the server block when kas is the only service that leverages it.

#954

@biscoe916 @jrschumacher Would we use this same crypto for signing attributes or other resources in the future?

[dmihalcik-virtru]

@strantalis We can probably move all of the config into the keyring section with little disruption to KAS. The code is written at the moment to allow all services to use a shared crypto provider, which is really an abstraction layer that allows us to switch between a pkcs#11 backend and a golang crypto backend - which could be something other services desire but in practice so far we haven't needed it elsewhere