Cryptographic validation of Evidence with attest-key-triple #318
Conversation
Validation is specific to a method. This reorganizes example methods into subsections and adds a new example based on attest-key-triple and CoTS. This is an attempt to make actionable "key lookup" normative language as marked in Issue#317. This is an attempt to resolve the ae verification concern in Issue#314.
deeglaze
requested review from
henkbirkholz,
thomas-fossati,
yogeshbdeshpande and
nedmsmith
as code owners
| A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment. | ||
| The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment. | ||
| The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment. | ||
| For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`. | ||
| The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment. |
There was a problem hiding this comment.
Given this topic is still relatively fresh, I understand the reluctance to add strong statements. However, these MAYs totally lack bite. I think a better way to phrase this is to state clear requirements under a set of well-defined circumstances. For example:
If
attest-key-triples are used during phase 1 for evidence verification, then:
- The verifier MUST ...
- The verifier SHOULD ...
There was a problem hiding this comment.
Okay, if I use this method in the SEV-SNP CoRIM profile, then I can add that normative language for the profile, but this is still an example, and that profile doesn't actually use CoRIMs in this way.
For that profile I will still be making suggestions that Verifiers include a CoTS tag binding the SEV-SNP attestation class-id for the AMD-published keys as an implicit input, and then treating VCEK certificates from KDS as "virtual" attest-key-triples, since they don't issue CoRIMs.
When I describe translating an ATTESTATION_REPORT to claim structure that lines up with reference values in the CoRIM profile, I still describe the whole verification scheme.
It all just feels more like a mental exercise than an actual use of the CoRIM representation.
There was a problem hiding this comment.
We seem to have similar requirements for PSA/CCA. Maybe we could sit down and see if we can extract a core set of requirements that are profile-independent.
There was a problem hiding this comment.
The verifier will accept Evidence assertions so long as the channel to the Attester is authenticated (but not attested). Attest-key triple is not second guessing this assumption.
Phase 3 (corroboration of ref values) may be a better phase to process attest-key triples since the enforcement of a key measurement that fails key verification would reasonably result in that measurement NOT being corroborated.
It might make sense to require the RIM author to include RV triples that do binary compare operations as a pre-requisite to applying attest-key processing.
There was a problem hiding this comment.
RV triples that do binary compare operations of what? I'm not following.
| ##### Example: `attest-key-triple` | ||
|
|
||
| A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment. | ||
| The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment. | ||
| The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment. | ||
| For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`. | ||
| The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment. |
There was a problem hiding this comment.
These lines pertain to the handling of attest-key-triple-record and its transformation and processing logic. Possibly, it makes sense to move this text to issue #330?
It doesn't make sense to describe it as an example since it is / will be described in another part of the spec.
| If the `$crypto-key-type-choice` is an identifier type (e.g., `tagged-thumbprint-type`) and the Verifier cannot retrieve the associated public key material, then the key identifier MUST be discarded. | ||
| The Verifier MAY use the Evidence's Target Environment to fetch input to verify and admit a relevant `attest-key-triple`. | ||
|
|
There was a problem hiding this comment.
These lines are included with the previous comment related to attest-key-triple-record.
|
|
||
| ##### Example: `attest-key-triple` | ||
|
|
||
| A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment. | ||
| The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment. | ||
| The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment. | ||
| For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`. | ||
| The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment. |
There was a problem hiding this comment.
| ##### Example: `attest-key-triple` | |
| A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment. | |
| The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment. | |
| The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment. | |
| For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`. | |
| The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment. |
|
|
||
| As a second example, in PSA {{-psa-token}} the verification public key is looked up in the appraisal context using the `ueid` claim found in the PSA claims-set. | ||
| If found, COSE Sign1 verification is performed accordingly. | ||
|
|
||
| Regardless of the specific integrity protection method used, the Evidence's integrity MUST be validated successfully. |
There was a problem hiding this comment.
| Regardless of the specific integrity protection method used, the Evidence's integrity MUST be validated successfully. | |
| Nevertheless, Evidence integrity MUST be validated successfully. |
| The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment. | ||
| For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`. | ||
| The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment. | ||
| If the `$crypto-key-type-choice` is an identifier type (e.g., `tagged-thumbprint-type`) and the Verifier cannot retrieve the associated public key material, then the key identifier MUST be discarded. |
There was a problem hiding this comment.
| If the `$crypto-key-type-choice` is an identifier type (e.g., `tagged-thumbprint-type`) and the Verifier cannot retrieve the associated public key material, then the key identifier MUST be discarded. |
This logic shouldn't apply when crypto-key-type-choice is used as a measurement-values-map value. If the value is corroborated by RVs then that should be good enough.
If the context is a key verification triple like attest-key-triple, then it makes sense to consider this text as part of the processing steps. But this is one of many possible failure conditions. Maybe there isn't a need to callout this condition explicitly?
Validation is specific to a method. This reorganizes example methods into subsections and adds a new example based on attest-key-triple and CoTS.
This is an attempt to make actionable "key lookup" normative language as marked in Issue #317.
This is an attempt to resolve the ae verification concern in Issue #314.