Transformation and processing sections needed for attest key and identity key triples

[nedmsmith]

Also relates to #314
A transformation section is needed for attest key and identity key triples that describes how attest/identity key triples are transformed into an internal representation.

A processing section is needed that describes how the internal representation is processed. For example, it might impact phase 3 where a negative result of the AKT prevents the reference values from being added to the ACS.

Note: Given verifier behavior differs based on the type of key (identity vs. attest), there needs to be a way to represent the key type across external to internal processing. One approach is to modify the internal representation to include key-type info along with the $crypto-key-type-choice key.

[nedmsmith]

There is a thread related to the semantics of what it means for a key to belong to an environment.
The diag snippet below shows a key identifier (e.g., cert path) as a measurement of the environment class-id ending in ...39. This means the key is in the target environment named ...39. Since the private key is a secret the cert / public key serves as its alias.
Example:

  / comid.triples / 4 : {
    / reference-triples / 0 : [
      [
        / environment-map / {
          / class / 0 : {
            / class-id / 0 :
              / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e39' )
          }
        },
        [
          / measurement-map / {
            / mkey / 0 : "thing 2",
            / mval / 1 : {
              / cryptokeys / 13 : [
                / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"),
                / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y")
              ]
            }
          }
        ]
      ]
    ],

The next snippet shows an identity-triple that matches the keys that were named above as measurements and instructs the verifier to do key verification.

    / identity-triples / 2 : [ 
      [
        / environment-map / {
          / class / 0 : {
            / class-id / 0 :
              / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e39' )
          }
        },
        / key-list / [
          / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"),
          / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y")
        ],
        / conditions / {
          / mkey / 0 : "thing 2"
        }
      ]

If the private key for base64_cert_path_X was used to authenticate the Attester to the Verifier. The verifier also has PoP that the private key is indeed on the Attester. The above RV claim asserts that the private key is in the environment named ...39. The identity-key triple is almost a no-op since it did the key verification on key _X already. It just needs to add it to the endorsement record that will be added to the ACS.

The Verifier can also check key _Y, but since it wasn't used earlier, it has to do the cert path validation, crl check. It can't do the PoP check unless there the conveyance protocol exposes an interface for that (out of scope for this spec). Note, the Verifier has the option of creating richer endorsements that might indicate the variety of key verifications checks that were applied and the result for each. That might require breaking out each _X and _Y keys into separate triples entries so they can have different verifier asserted key verification results (or the verifier might just generate an audit log with that information in it).

[deeglaze]

So identity-triple and attest-key-triple both get processed the same way (perform checks before associating keys to environment), and there isn't any requirement to verify a certificate path in cryptokeys if in evidence, since the claim itself means the keys have been verified by the attester? Ah, and that's why the Verifier is the authority when processing identity-triple and attest-key-triple.

But after translating both of these triples to the same internal representation, for what reason are there two triples for the same thing? It looks like they imply some meaning, but if you drop that meaning in the transformation prior to giving the ACS to your policy engine, I don't know what the point is of keeping them separate.

[nedmsmith]

I don't know what the point is of keeping them separate.

DICE certs and TPM keys distinguish between keys intended for use to sign evidence vs. signing an authentication challenge. The Verifier presumably will check this.

We talked about merging the triples, but that would require parameterizing it in some way. Since the convention has been that the predicate part is implicit (not in CDDL) if there are semantic differences that would require parameterization, we decided to avoid that by creating a different triple.

However, if the triples are restricted to using crypto-key-type-choice forms that have certs (or require the verifier to do path construction), then the key type is in the certificate (or the key object itself). It doesn't need to be a parameter of the triple (I don't think?). The wording in the transformation and processing sections imply that the key type / usage restrictions are part of the crypto-key-type-choice object already as the internal representation doesn't parameterize on key type / usage.

Assuming others agree, I think the key verify triples could be merged.