Make signer optional

[laurencelundblade]

It is completely OK to rely on EAT's signing mechanism to authenticate the measurements.

[laurencelundblade]

I think I misunderstood ckt. It's not about signing the measurement. It's about authorizing install, right? Probably should call it something very different and describe that in a big way. Still might want it optional. A bit confused...

[thomas-fossati]

I think I misunderstood ckt. It's not about signing the measurement. It's about authorizing install, right?

Yes, exactly.

Semantically, it is equivalent to Open-DICE's Authority Data, i.e., a thumbprint of the verified boot trusted authority.

Probably should call it something very different and describe that in a big way.

Makes sense. Do you have any suggestions for the naming?

Still might want it optional.

+1

[laurencelundblade]

You're trying to name some company or person (a legal entity), right? How about what EAT OEM ID did? EAT OEM ID is just trying to name a legal entity. You could add CKT, or CKT could one way to make a random ID.

[laurencelundblade]

And call it "installing entity" or such rather than signer.

I guess you've thought about it, but your adding another legal entity into the mix here in addition to SW manufacturer, HW manufacturer... Is that what you want to do? Seems like you'd want to know the SW manufacturer of the component just as much as who installed it.

[thomas-fossati]

You're trying to name some company or person (a legal entity), right? How about what EAT OEM ID did? EAT OEM ID is just trying to name a legal entity. You could add CKT, or CKT could one way to make a random ID.

In PSA the Signer ID represents the identity of the signer of the firmware component's manifest. So, yes, it is "some company or person", which in PSA's secure boot model is reduced to the thumbprint of a public key.

I am happy to extend the type to include other applicable types, i.e.:

signers: [ + signer-type ]

signer-type /= ckt
signer-type /= TODO

and I like the idea of reusing something already specified, but my reading of EAT is that the semantics of oemid are limited to HW manufacturing entities. What we need here is an OEM ID for software entities :-)

[laurencelundblade]

So I'm thinking of this a bit generally outside of TCG and PSA stuff. That's right, isn't it? There's no requirement that it be used in those contexts, right? If so, the signer/installer gets interpreted in a variety of contexts.

It's not very clear to me what signer/installer is. If the end user installs an app, are they the installer? If the component is the chip HW fuse block area, is the device OEM the installer? Who's the installer if you're measuring part of the file system.

I assume the installer is distinct from the manufacturer of what is being measured because you're not calling it SW_manufacturer.

Maybe you can say more about how the sender should create the signer/installer and what the receiver should do when it gets it.

[thomas-fossati]

So I'm thinking of this a bit generally outside of TCG and PSA stuff. That's right, isn't it? There's no requirement that it be used in those contexts, right? If so, the signer/installer gets interpreted in a variety of contexts.

(In the future) we want to use this as a replacement for PSA software measurements, so we'd like to be able to losslessly map our current semantics onto it.
But yes, we also want this to be generally useful, otherwise we wouldn't have started this :-)
One easy (and reasonable) thing is to make signer(s) optional, so if you don't need it you can just forget it even exists. This would cover the RTIC and file system object use cases, as well as non-signed software components.
Another is to allow signer(s) to have different types.
First, though, we need to agree on the high-level semantics of the field.
It seems to me the most natural mapping is to "code signing", where the code signer can be identified via an X.509 cert, a raw public key or a thumbprint thereof, a COSE Key, etc.
Would that work for you?

I assume the installer is distinct from the manufacturer of what is being measured

In general, yes.

Maybe you can say more about how the sender should create the signer/installer and what the receiver should do when it gets it.

Sure, that shouldn't be too hard.

[thomas-fossati]

@laurencelundblade thanks for the discussion so far. After giving it some more thought, I have made some tentative changes to address your comments. In a nutshell: signers are now optional (i.e., your initial point), and any specific encoding requirements are on the EAT profile that uses measured components.

[laurencelundblade]

I'd like to see some text explaining that the EAT signature will often be the way measurements are protected and authenticated. I think this is a major use case for measured components. It is an efficient way to secure measurements.

CoSWIDs can be unsigned, so we're already doing that in EAT measurements, but it is not discussed. The discussion of signed/unsigned manifests in EAT is an example of what should have been there for measurements.

[thomas-fossati]

Closing this as Laurence's original point (i.e., to make signers optional) has been addressed. The discussion on clarifying what the semantics for signers is has moved to #6