Verify key triples

[nedmsmith]

Addresses the majority of issue #330 (but one challenge remains).

Expanded examples may be needed.

[deeglaze]

I'm thoroughly confused what point an attest-key-triple serves if it is exactly the same as an endorsement of a cryptokey. It loses information about the key usage for verifying evidence to just being about having some key provisioned to it.

[deeglaze]

@yogeshbdeshpande when PSA (not CCA) has its token verified with the IAK, "the verification public key is looked up in the appraisal context using the ueid claim found in the PSA claims-set."

This appraisal context is separate from the ACS? It's some unmentioned data structure that associates an environment with the key that should be used to verify the PSA? If not, and there is an ECT representation of it, then how is the transformation in #341 that strips the attest-key-triple quality to make it just another cryptokey measurement supposed to maintain the integrity of that lookup process?

[yogeshbdeshpande]

Hi @deeglaze : Veraison started when we did not had the concept of ACS within CoRIM draft, forget matching the exact data structure! However the concept of Appraisal context is the same as ACS. I would not prefer to explain too many details about Veraison implementation here, been this is a more generic CoRIM repo, but happy to explain it in a separate issue under Veraison repository!

[deeglaze]

Appraisal Context in this document is used as a nebulous, "stuff related to appraisal that we didn't represent in the ACS".
If we're making attest-key-triple mean something more than an endorsement of an (attesting) environment holding a key, we need to disambiguate it in the ACS to make the evidence verification section self-contained.

[nedmsmith]

The original text was actually wrong (append direction was reversed). The new text fixes this.

The other thread doesn't seem related to the cited text. Maybe it belongs somewhere else or take it to the issue instead of the PR?

[nedmsmith]

If we're making attest-key-triple mean something more than an endorsement of an (attesting) environment holding a key, we need to disambiguate it in the ACS to make the evidence verification section self-contained.

We're not. The ACS has an ECT that associates the name of the key with an environment. This exists under the authority of the RVP as well as the Attester.

The attest-key-triple asked the verifier to do key verification. As a result, the ACS has a third ECT entry identical to the first two, this time under the authority of the Endorser and the Verifier. The Endorser is the entity asking to do the key verify checks, and the Verifier is the entity that did the check.

Putting it all together:
step 1: Attester says key _X exists in environment _E.
step 2: RVP says key _X is supposed to exist in env _E. (aka step 1 is corroborated)
step 3: Endorser says key _X is supposed to be verified.
step 4: Verifier says key _X was verified.

An RP may have a policy that wants to see all 4 steps. There are entries in the ACS for all 4.

[deeglaze]

The triples are named wrong, then. We shouldn't say anything about attesting or identity of the triple just means the signer demands a check to be done. I don't like that though, since there's still nothing that cleanly says "to get the attesting key for evidence of Target Environment E{layer n+1}, use the first cryptokey in E{layer n} (no mkey)"

A profile can of course say do something else, but as long as we're already translating everything to internal representations, I'd like to know in what senses I'm saying profile P's analog to evidence verification is "treat X as Y".

[deeglaze]

I would like this to be the introductory line of the section.

[deeglaze]

Same for the device identity key section above.

[nedmsmith]

Additional use case background on verify-key-triple:
A centralized RoT architecture has a single (monolithic) RoT that is either trusted or not. A distributed RoT architecture has multiple trusted components that are linked cryptographically. The bootstrap flow enables the RoT components but doesn't require each to be an AE. As RoT components they are not updatable / measurable other than that their public keys can be reported as evidence.

User / Verifier will never see data / evidence signed by these keys. However, if a key is revoked, it would be useful information to a RP who is managing security risk to know if such revocation happened. This is not an architecture unique to Intel as CXL devices will have this type of key.

The RefVal triple and concise-evidence triple can validate existence of the keys. However, it is up to downstream processing to determine if any of the keys pose an additional risk as the Verifier would not automatically discover existence of a compromised key.

As an optional to implement triple, a verifier could step up to do these checks (possibly as a way to achieve better scalability vs. pushing it off to downstream RPs? Some other endorsement specification could be used to achieve similar objectives, but that wouldn't change the performance / security dynamics.

Completely ignoring it is another option, but trades security for performance where the cost of doing the security check is easily quantifiable. It seems clear that there will be customers interested in doing the checking. The question is what role should corim play and when.

[deeglaze]

What is a nonce Claim? Is this something like but isn't exactly eat_nonce? Given that the Verifier is allowed to add anything it wants with its authority, maybe we should drop this sentence and allow the reader to decide what claims they want to add.

[nedmsmith]

This is offered as an example. It is already assumed that the reader / implementer will decide what claims they want to add. Since the previous exemplary text is addressed as part of the triples, it isn't a good example. I updated the example to be less prescriptive / more conceptual.

[nedmsmith]

I tried to build with map structure that doesn't use code points, but it failed (again). I'm using latest version of cddl. I don't see a reason to hold up this PR based on build issues. The prose in the .md file doesn't change. So it can be merged and if we want to change it to not use code points, that won't affect merged prose.

[nedmsmith]

multiple comments.

[nedmsmith]

This is offered as an example. It is already assumed that the reader / implementer will decide what claims they want to add. Since the previous exemplary text is addressed as part of the triples, it isn't a good example. I updated the example to be less prescriptive / more conceptual.

[yogeshbdeshpande]

LGTM!