Provide the ability to specify the header x5c

[dmulder]

Himmelblau requires this for requesting a PRT.

• cargo fmt has been run
• cargo test has been run and passes
• documentation has been updated with relevant examples (if relevant)

[Firstyear]

I think this can be expanded on a bit:

First, we probably actually should make it so kid can be set or not set - we enforce it right now by default, but we should have a way to say "sorry I don't want it.". Probably when you set x5c, it should cause the kid to be cleared?

The other point is getting x509 certs are both vec https://github.com/kanidm/hsm-crypto/blob/main/src/lib.rs#L466 meaning we should probably have this take a vec, and use that, allowing us to format it in the correct way with base64.

Better, could we actually just pull the x5c from internally rather than this dance when we have a jwtSigner? Some way to have the JwtSigner automatically know if it should provide x5c vs kid? For example, https://github.com/kanidm/compact-jwt/blob/main/src/crypto/es256.rs#L257 which actually sets the kid. For our TPM type we could automatically use this to switch between x5c and kid if a x509 cert exists on the identity key.

[dmulder]

Better, could we actually just pull the x5c from internally rather than this dance when we have a jwtSigner? Some way to have the JwtSigner automatically know if it should provide x5c vs kid? For example, https://github.com/kanidm/compact-jwt/blob/main/src/crypto/es256.rs#L257 which actually sets the kid. For our TPM type we could automatically use this to switch between x5c and kid if a x509 cert exists on the identity key.

I've modified it to pull the x5c directly from the key, but I also left set_x5c() in case someone is trying to set a chain.

[dmulder]

Unfortunately removing the kid did not resolve the issue I'm facing in the himmelblau PRT req :-(

[dmulder]

Unfortunately removing the kid did not resolve the issue I'm facing in the himmelblau PRT req :-(

I got it working. My JWK containing the transport key which I sent during the join wasn't correct. Apparently Microsoft doesn't validate that transport key in any way until it first gets used! So it accepted garbage during the join and stored it for later.

[Firstyear]

I got it working. My JWK containing the transport key which I sent during the join wasn't correct. Apparently Microsoft doesn't validate that transport key in any way until it first gets used! So it accepted garbage during the join and stored it for later.

Opppppsss. That's a bit of a rough discovery.