KBS: combine CoCo Token and Jwk Token verifier

[Xynnn007]

This patch is part of #514.

ITA token and CoCo Token are both JWTs. They both need a JWK to verify the JWT. The difference is the way to gather the JWK.

This commit combined the two logic, and add two ways to get the JWK.

1. From the configured JwkSet when launching KBS
2. From the JWT's Header's jwk field.

The two ways will check the jwk endorsement in different ways. The first way is to configure the trusted JwkSet from the config. The second way is to configure the trusted CA in config. Then get the public key cert chain from Jwk's x5c field. The both ways are also supported in this patch.

The difference between CoCo Token and ITA Token are where Tee Public key is embedded inside the token, this could be configured in the launch toml of KBS, because it is hard to detect during runtime.

Rust does not provide a mature crate to verify cert chain, thus openssl is used in this patch. We also abondon rustls and openssl feature of KBS because openssl is by default used. Then we use openssl by default to make the code base simpler.

Close #486

cc @mythi

[LiuPeng-running]

Good good good.

[Xynnn007]

This PR also changes some logic of previous JWK of CoCoAS, so ptal @jialez0

[fitzthum]

LGTM

Wdyt @mythi

[mythi]

My earlier comment in the original PR was that my preference is to not expose "ITA" as a token type to the user and that seems to be in this PR still. I was wondering whether we could just ask users to provide the list of trust anchors and try to parse the provided file:// and OpenID config paths.

The only reason for "token type" to still exist seems to be the tee-pubkey search path in the claim. Would it make sense to have the paths configurable instead of having them implicit via the token type? The search paths config could be a list to support tokens with different paths simultaneously.

[Xynnn007]

I was wondering whether we could just ask users to provide the list of trust anchors and try to parse the provided file:// and OpenID config paths.

Yes. This PR supports the original ITA way, s.t. provode file:// to speficy jwkset, or openid url for jwksets. The modification is the configuration name in the config file, from trusted_certs_paths to trusted_jwk_sets.

Another option is trusted_certs_paths. It's for trusted root certs to verify the jwk/x5c field within the JWT header.

The only reason for "token type" to still exist seems to be the tee-pubkey search path in the claim. Would it make sense to have the paths configurable instead of having them implicit via the token type? The search paths config could be a list to support tokens with different paths simultaneously.

Nice suggestion. The pro is flexibility while the con is extra complexity to remember the paths. I personally prefer the "token type" way as the user only needs to care about token type rather than claims inside that. I think you are caring about the name ITA to be exposed to users, so what do you prefer to name it?

[mythi]

The modification is the configuration name in the config file, from trusted_certs_paths to trusted_jwk_sets.

Another option is trusted_certs_paths. It's for trusted root certs to verify the jwk/x5c field within the JWT header.

I was not very clear earlier. My comment was that can we have just one config entry. It would be easier for the user. It should be possible to handle ["file:///foo/coco.pem", "file:///foo/ita.jwks"].

The pro is flexibility while the con is extra complexity to remember the paths

True, OTOH, we can always make known paths as the default and only provide the mechanism to add supplemental paths.

[mythi]

Would it be OK to aim fixing #519 with PR too?

[Xynnn007]

Would it be OK to aim fixing #519 with PR too?

Probably not. Currently it is hard for KBS to detect the JWT type (CoCoAS/ITA or else) runtimely. See #519 (comment)

[Xynnn007]

True, OTOH, we can always make known paths as the default and only provide the mechanism to add supplemental paths.

Do you mean that we have two config items

• type: specify the token type, s.t. CoCo or ITA
• tee_publickey_path: if this parameter is given, ignore type and try to extract tee key from this path

[mythi]

Would it be OK to aim fixing #519 with PR too?

Probably not. Currently it is hard for KBS to detect the JWT type (CoCoAS/ITA or else) runtimely. See #519 (comment)

Could kid/x5* header fields be used to map to what trust anchors we have configured. ITA token has kidand we use it to search the corresponding JWK in the JwkSet.

Do you mean that we have two config items

Just one because type isn't used for anything else than just for mapping to tee-pubkey paths. So I'm thinking could we drop type completely, have some default tee-pubkey paths and allow users to configure supplemental tee_publickey_paths.

[Xynnn007]

Could kid/x5*header fields be used to map to what trust anchors we have configured. ITA token haskid`and we use it to search the corresponding JWK in the JwkSet.

Yes it can and it is implemented in this PR. What #519 aims is to support different public key claim path.

Just one because type isn't used for anything else than just for mapping to tee-pubkey paths. So I'm thinking could we drop type completely, have some default tee-pubkey paths and allow users to configure supplemental tee_publickey_paths.

Ok. Could you provide an example for this in your mind?

[mythi]

Could kid/x5*header fields be used to map to what trust anchors we have configured. ITA token haskid`and we use it to search the corresponding JWK in the JwkSet.

Yes it can and it is implemented in this PR. What #519 aims is to support different public key claim path.

Right, sorry. I had missed that and got side tracked when you wrote that JWT detection cannot be done easily.

Just one because type isn't used for anything else than just for mapping to tee-pubkey paths. So I'm thinking could we drop type completely, have some default tee-pubkey paths and allow users to configure supplemental tee_publickey_paths.

Ok. Could you provide an example for this in your mind?

Instead of match self.token_type we could just loop all configured/known paths until claim.pointer(path) returns Ok. For starters this could be just the two we know today (i.e., TOKEN_TEE_PUBKEY_PATH_COCO and TOKEN_TEE_PUBKEY_PATH_ITA) but maybe we want to add a config entry that allows users to add more paths to search.

[Xynnn007]

@mythi Adds the change that you suggested. I think it is good to have some internal defined paths together with user defined extra paths.

[mythi]

@mythi Adds the change that you suggested. I think it is good to have some internal defined paths together with user defined extra paths.

thanks! I personally feel it's better this way and I guess this now meets #519 also. My remaining concern is whether we need separate user facing config entries for trusted_certs_paths and trusted_jwk_sets.

[Xynnn007]

Well as they are different things. One is jwkset and the other is root pem certs

[mythi]

Suggested change

	insecure_key: true,
	insecure_key: false,

[mythi]

Well as they are different things. One is jwkset and the other is root pem certs

If the take this path, we might need a third one for "OpenID Configuration endpoints" which is what the default ITA config prefers. But my point was that some generic config entry would probably keep things simple for the users.