Modeling finer grain binary provenance: endorsement? CoSWID entity-entry extension?

[deeglaze]

The concept of endorsement vs just signing a CoRIM with reference values is still a point of confusion for me, so apologies if I get the terminology wrong. I'm particularly perplexed about the notion of endorsement.

At Google we're working on an open standard for binary integrity in terms of linking source + trusted builder with the set of binary artifacts. This is called SLSA, and it's not so much an entity that created software dependencies like an SBOM would describe, but more of a holistic "all that source" => "all these binaries" integrity claim. I don't particularly know what the expectation is for CoSWID tag creation when you're building a patched version of on open source project.

Even so, our builders don't produce CoRIMs and I don't expect them to for a while. If I want to combine SLSA with CoRIM with a profile definition, I'm not sure where to begin. I think my CoRIM signer would be recertifying the SLSA document's claims by linking to the original SLSA document and additionally signing the CoSWID representation that includes binary digests. Is that what y'all would recommend?

Or, by signing the CoSWID without a SLSA link as an entity-entry extension, we can state an inference. The SLSA document is not part of the CoSWID but is instead a supporting endorsement?

Endorsement according to CoRIM: "Additional measurements that are valid when a Target Environment has been verified against reference measurements."

We would then define a SLSA Profile for CoRIM that extends measurement-values-map with some linking representation that the CoSWID tag has extra integrity when verified against the SLSA provenance? We could furthermore have counter-signers that independently verify the build and endorse those links? I don't know. Counter-signing by a third party seems to be yet another modeling difficulty I'm unsure how to handle.

[nedmsmith]

Signing the corim means the signer (aka a principal in the supply chain) asserts the claims contained in the corim. The principal is the authority that is speaking. Some principals may be more qualified to assert a statement than other principals. E.g., the manufacturer / designer of a widget may be more qualified to say how the widget was created than say a retail store that sells the widget. Any of these principals could assert the same claim. But one might be the most qualified. An appraisal policy might want to specify which principal is most qualified to assert claim X.

Anything a principal says about an Attester is an endorsement.

Reference Values are (in a way) a special case of endorsement except that reference values describe claims that are corroborated by evidence. The attester is also a principal that asserts claims (aka Evidence). The limitation on attesters is they can only assert claims that are reasonable for hardware or software to make. For example, they can read FLASH / ROM and report what they read. They can't tell however what version of software was used to populate the FLASH / ROM (unless read from somewhere else). They can't tell if a particular test or qa process was followed as part of writing the contents to the FLASH / ROM. These are examples of endorsement claims.

FIPS 140 calls for self-tests that run as part of the bringup process in a FIPS certified chip. It is reasonable for an Attesting Environment (AE) to be able to detect if the FIPS self-tests ran. This can be reported as evidence. But the quality of the self-tests may rely on engineering practice and other quality control procedures that the AE can't monitor and report. Hence, these are endorsements.

[nedmsmith]

We could furthermore have counter-signers that independently verify the build and endorse those links?

I don't think counter-signing is necessary for basic attestation. The semantics of counter signing has to be understood in the context of what processing the signing principal is performing before adding their signature. Normally, the Verifier processes the various attestation inputs and produces an attestation results. The signed result asserts the verifier processed the inputs an realized a certain result. The Verifier is (in a way) counter signing the claims made by the other principals (even though it doesn't fit the technical definition of cryptographic counter-signature).

If you removed all the claims, and just counter-signed a signature, what would the counter-signing principal be asserting? It seems like an existential statement about the signature that has esoteric value.

If a second supply chain entity wanted to assert build properties, then it could do so by simply signing the same claims as were signed by the first supplier.

The Verifier would have two principals asserting the same claim about the Attester. Does that mean two principals are more believable than one? Well, that depends on what policy is being applied. If a policy says two principals have to agree, then that is something the Verifier can enforce. But if the policy says only one principal (e.g., the entity that stamped the widget on the assembly line is the most authoritative), then adding a second principal wouldn't carry additional credibility.

[deeglaze]

"Anything a principle says about an Attester is an endorsement"

Yes, so a key certificate is an endorsement conceptually but isn't necessarily going in the endorsed-triple. As I conceptualize this for provisioning certificates for AMD SEV-SNP or Intel TDX, I'm unsure what this means. AMD says the attestation key is authentic for a given CHIP_ID, TCB_VERSION, and model stepping name. The AMD key distribution service binds those claims in bespoke x.509 certificate extensions. If AMD or Intel were to embrace CoRIM over x.509 extensions / TLS-protected responses from the PCS respectively, how would it do so for a TEE on particular firmware? Is the firmware security version(s) an endorsed-triple for the same environment-map of the attest-key-triple that includes the VCEK or PCK certificate?

The environment-map piece has an instance representation that we'd need to extend to allow CHIP_ID (AMD 64 bytes), PlatformManifest (Intel, yikes), or encrypted ppid (Intel, 384 bytes) in the case of chip-specific environments, but there are group keys as well. AMD has a VLEK that is certified for a whole cloud service provider ID that itself needs a group representation somehow.

Now if I'm essentially rewrapping that information as interpretations from the provisioning services, then I'm endorsing an Attester, but for the VCEK certificate I can provide some evidence. For the Intel PCK certificate, I can't really give evidence about the TCB versions since those were just in a protected response by the TLS session.

I guess I have to ask if it's even worth using the attest-key-triple to model these certificates that are produced outside the CoRIM model, and instead just define some special profile to link the actual data to some expectation from the ATTESTATION_REPORT or TDQUOTE evidence.

[thomas-fossati]

We could furthermore have counter-signers that independently verify the build and endorse those links? I don't know. Counter-signing by a third party seems to be yet another modeling difficulty I'm unsure how to handle.

From a purely technical standpoint, RFC9338 provides the COSE building block for counter signatures. You compute it and stash it in an unprotected header of the original Sign1. An example here.

BTW, countersignatures are implemented in go-cose.