Platform KMS (WIP)

[maraino]

This is a first attempt to create a platform KMS. This KMS is supports mackms, tpmkms, softkms, and capikms.

There's a couple of things that I'll like to consider:

1. Is hw the right argument, or should we use ak?
2. Should we fail if hw (or ak) is set for softkms and capikms?

[hslatman]

• Is hw the right argument, or should we use ak?

hw and ak must not be considered to mean the same thing. All AKs are hardware-bound (currently, at least; especially in the context of TPMs); not all hardware-bound keys are AKs. Using those interchangeably will cause confusion. In general I would say hw is thus the right term to use. Only use ak when it's specifically about an attestation key. At the moment, using ak=true implies hw=true, but not vice versa.

• Should we fail if hw (or ak) is set for softkms and capikms?

I think that's OK. In general, when a specific backing KMS doesn't support a certain functionality, and still instructed to do so, it should fail. Technically, the capikms with Microsoft Platform Crypto Provider set as the provider, will have its keys backed by the TPM, so we could take that into account when hw=true is provided to capikms with the provider set. It might also be possible to manage AKs through capikms, but I don't recall having seen functionality related to that before.

[hslatman]

When considering/introducing these new interfaces, we may want to add a ctx as the first argument to make them more future-proof.

The main reason is I foresee us refactoring existing KMS implementations and the requests to take one too, so that we can cancel requests to remote KMSs and carry OpenTelemetry data, for example.

If we really want to keep the old function signatures we could pass a ctx in the requests, but that's not idiomatic Go. It might be an option to do that temporarily, so that not everything breaks, but then we'd have to work on the same parts at least twice.

[maraino]

We are already adding an interface like this in other places, here I'm making it public. If we want to add the context, I think we could add It everywhere, using one of this options:

1. ctx argument in functions, perhaps using apiv2
2. Context field in requests
3. Something like http.NewRequestWithContext that sets an private field, that can be accessed by a Context() method, that's more or less like 2 the only differences is that in that method we can return context.Background() if it's not set instead of adding if conditions in all the methods where contexts are used.

[hslatman]

I would go with option 1. I'd say it would be OK to keep apiv1, as the request types themselves don't change or get a different meaning, or something like that.

[hslatman]

Should this happen for all calls? It is now done unconditionally.

[maraino]

Only for those that store certificates, but right now I don't have different methods or an argument indicating which kind of transformation we want. This could be an improvement but I think this is the only use case for it.

[maraino]

@hslatman I've fixed most of your comments except the ones related to hw and ak. I see a few options:

1. Change hw with ak and use se=true if ak=true (we're doing this in other places)
2. Keep hw and add ak. hw will be ignored in TPMKMS, but will be used in mackms for se=true and capikms for provider=Microsoft+Platform+Crypto+Provider
3. My least favorite, remove hw and add ak on TPMKMS. And use backend parameters se and provider.

[maraino]

@hslatman What do you think about the custom attestation using the AttestationClient in f1076d3

[hslatman]

@hslatman I've fixed most of your comments except the ones related to hw and ak. I see a few options:

1. Change `hw` with `ak` and use `se=true` if `ak=true` (we're doing this in other places)

2. Keep `hw` and add `ak`. `hw` will be ignored in TPMKMS, but will be used in `mackms` for `se=true` and `capikms` for `provider=Microsoft+Platform+Crypto+Provider`

3. My least favorite, remove `hw` and add `ak` on TPMKMS. And use backend parameters `se` and `provider`.

Options 1 and 3 both don't result in hw meaning something different than ak, so those will most likely not result in behavior that we need. Keep in mind that the AK on macOS is the special case; not the other way around.

Option 2 sounds good to me. The creation of an AK with ak=true is (generally) up to the importer/caller of the package, and is independent of whether or not hw=true (although it will always be hardware backed in TPMKMS). I think that's reasonable, as the caller knows, or at least ought to know, whether or not it is about the create/use an attestation key vs. an application key.

[hslatman]

@hslatman What do you think about the custom attestation using the AttestationClient in f1076d3

It looks OK. Given the current interfaces and existing implementation, I think it can be added like that.

The way the AttestationClient is passed in the request and then the signer using the context, with the AttestationClient depending on retrieving the signer from that ctx again can be a bit confusing. Maybe we can think of something that lets us do that in one go, but it might result in something close to the current Attester interface.

[maraino]

@hslatman I've pushed the changes for hw. Now it only sets se=true (on mackms) and provider=Microsoft+Platform+Crypto+Provider on capi. It is totally ignored on tpmkms.

As it is I think the only thing missing would be to error on softens if hw is set, I will need to refactor all the transformToURI and related tests to return an error. And optionally add a type (keyType, certType, attesterType) to those methods so we can skip one value on capi.