Add API to support key attestation

[ndevillard]

It should be possible to request full information about a stored key: its attributes, but also where the key originates from: was it imported in clear text? wrapped? generated inside the key store? If it was generated on-board, what kind of hardware/software was used to generate it?
That information must be signed by another key assumed to be present in the same key store. Trusting that signing key allows a requester to also trust the attested key.

A key attestation function would take as input the ID of the key to be attested, the ID of the key attestation signing key, and return a signed token in a clearly defined format like an EAT token with a fixed list of mandatory claims and additional vendor extensions.

[gilles-peskine-arm]

Does the crypto service really need to have the relatively complex feature of attestation? (Complex because you have to manage the attestation format, all the embedded metadata, etc.)

We had a similar request previously, and concluded that it was enough for crypto to report “this key has never been exposed”: #13.

[athoelke]

I've added the 'Attestation API' tag as well - this might be an API that fits better within that specification, but it is tightly coupled with the implementation of a key store within a Root of Trust.

If a Root of Trust provides a key attestation service, should there be a standard API to provide the attestation report? - and if so, what does that API look like?

This will depend on details of the use cases for the attestation, and there is currently no standard scheme for doing this. Use case criteria that will affect the API include:

• What is the format of the output report?
• What data about the key is included?
• What data about the Root of Trust is included?
• Can the implementation include additional attributes in the attestation
• Who specifies the signing key?
• What kind of chain of trust is involved, if any?
• How is the API, and the report, related to the existing Attestation API?

[athoelke]

One more important criteria for the API:

• Is the attestation report created and returned at the time of key generation, requiring the caller to store the report (if required); or is the report be generated by the RoT implementation 'on demand' for a previously generated key?

In the absence of a standard covering the this functionality, I would like the definition of an API for this to be driven by real use cases - so it is possible to identify which of the above aspects are driven directly by the user of the API (and consumer of the attestation report), and which ones require some further definition work.

Having more than one use case would be highly valuable, to determine which aspects require flexibility in the specification, or room for future evolution.

There is some existing work to define a EAT-based Key Attestation Token format here: https://datatracker.ietf.org/doc/draft-bft-rats-kat/. This could form the basis for this API, but it would be helpful to identity alternative approaches that exist, or are being developed.