Skip to content
This repository has been archived by the owner on Aug 29, 2024. It is now read-only.

software-component claim structure #2

Open
thomas-fossati opened this issue Oct 31, 2023 · 0 comments
Open

software-component claim structure #2

thomas-fossati opened this issue Oct 31, 2023 · 0 comments

Comments

@thomas-fossati
Copy link

As much as I like the idea of reusing PSA semantics, I think there's a chance here to "sit on the shoulder of the giant" (poorly paraphrasing Bernard de Chartres) and see what we can improve. In particular, I think there are some low-hanging fruits to be reaped from the work we've done on the verifier side, i.e., the guy who needs to make sense of the evidence blob.

Here are a few observations and proposals for discussion:

  1. software-component is a bit of a misnomer, because it's not just software/firmware that gets measured, it's also other kinds of blobs (e.g., configuration). A better, more generic name for the claim could be measured-component.

  2. Measurement Type is actually the hash algorithm identifier that is used to compute the digest, so using Type is not accurate, and frankly quite confusing. If I were to rewrite the PSA claim today, I'd group the measurement data (digest and algorithm) in a digest type, similar to CoSWID/CoRIM:

In CDDL:

digest = [
  hash-alg: int. ; codepoint from the COSE algorithms registry
  digest:   bstr ; the actual digest
]

In ASN.1:

Digest ::= SEQUENCE {
  hashAlgorithm AlgorithmIdentifier, -- OID for the hash algorithm
  digest        BIT STRING
}
  1. When building the verifier, we learned the importance of stable identifiers for measured components. These identifiers help in tracking the same measured item across updates and enable higher-quality signalling from the appraisal procedure to relying parties. A "component identifier" that provides a stable name along with an optional version is a good start. PSA got that bit right but makes it optional which doesn't promote the best practice. Again, with the benefit of hindsight:

In CDDL:

component-identifier = [
  name:      tstr
  ? version: tstr
]

In ASN.1:

ComponentIdentifier ::= SEQUENCE {
  name    PrintableString,
  version PrintableString OPTIONAL
}

So, to summarise, the data format I'm suggesting for §3.9 is:

In CDDL:

measured-component = {
  component-id: component-identifier
  measurement: digest
  signer-id: ckt ; COSE Key thumbprint
}

In ASN.1:

MeasuredComponent ::= SEQUENCE {
  componentId ComponentIdentifier,
  measurement Digest,
  signerId KeyIdentifier
}
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant