More on collections security

[thomas-fossati]

Due to the reflow of S3.3 I created a separate section to hold CMW/JWT-related considerations. That, in turn, necessitated moving the X.509 section to a closer place.

Fix #115

[nedmsmith]

LGTM

[laurencelundblade]

I haven't actually finished the review, but wanted to get this comment to you now because I'm kind of buried in some other work right now and won't get to the full review right away.

[laurencelundblade]

You can make an EAT submod a format other than EAT by defining a type for it. In CBOR-format EATs, that's just defining a new CBOR tag to identify it. Might be a bit weird to define a CBOR tag to identify an X.509 format attestation, but it is possible.

So I don't think 1. is true.

A more correct statement would be that EAT can't represent layered attestation when the topmost/outermost/lead attestation is not EAT format.

EAT seems fine for most layered attestation (see recent email to rats). Seems to me that CCA is doing rather unusual layered attestation. CCA attestation evidence spans devices, right? That's unusual for attestation IMO and beyond what I imagined anyone doing in EAT (and RATS).

EAT should not be presented as being unsuitable or bad at layered attestation.

Maybe say something like, while EAT submods are fine for most layered attestation, CMW is more flexible and can represent more complex or unusual layered attestation like a bottom-up chain of trust.

[thomas-fossati]

You can make an EAT submod a format other than EAT by defining a type for it. In CBOR-format EATs, that's just defining a new CBOR tag to identify it. Might be a bit weird to define a CBOR tag to identify an X.509 format attestation, but it is possible.

So I don't think 1. is true.

This is not what I understand from reading 4.2.18. submods (Submodules). There is no mention of the possibility of incorporating non-EAT tokens/claims-sets.

Can you point me to the relevant text?

A more correct statement would be that EAT can't represent layered attestation when the topmost/outermost/lead attestation is not EAT format.

EAT seems fine for most layered attestation (see recent email to rats). Seems to me that CCA is doing rather unusual layered attestation. CCA attestation evidence spans devices, right? That's unusual for attestation IMO and beyond what I imagined anyone doing in EAT (and RATS).

EAT should not be presented as being unsuitable or bad at layered attestation.

Maybe say something like, while EAT submods are fine for most layered attestation, CMW is more flexible and can represent more complex or unusual layered attestation like a bottom-up chain of trust.

We can certainly curate the text to avoid sounding adversarial vs EAT (that's certainly not my intent, on the contrary, I think EAT and CMW are an excellent pair.)

However, I stand by my assessment that submods are not great at layered attestation because they go counter the "natural" construction of the chain of trust of the device.

Typically (e.g., DICE, Arm CCA), the layer below signs the layer above, not the opposite. As I also said on the list, it could be my bias, but this doesn't look either complex or unusual to me.

[carl-wallace]

Re: incorporating non-EAT tokens/claims-sets, I think Laurence is referring to the fact that $EAT-CBOR-Tagged-Token is extensible. The potential for adding new types is noted in section 4.2.18 as follows:

The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket.

You are correct the text does not explicitly call out that ASN.1 types, or other, could be accommodated this way but the means to support such is there.

[thomas-fossati]

Thanks for the pointer!

Would it be fair to say something like:

"* {{EAT}} allows carrying non-EAT-formatted types by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket. However, these need to be specified in subsequent standard documents updating the EAT specification."

?

[carl-wallace]

I think so.

[thomas-fossati]

Integrated in 39e1f53

[thomas-fossati]

Taking this a step further, we may as well drop this and add a new subsection "Transporting CMW in EAT submods" that defines the sockets extensions:

$EAT-CBOR-Tagged-Token /= #6.TBD(cbor-CMW)

and

$JSON-Selector /= [type: "CMW", nested-token: json-CMW]

Where:

• cbor-CMW and json-CMW are defined in Appendix A of CMW
• 6.TBD is the CBOR tag requested for CMW

@carl-wallace @laurencelundblade @gmandyam would that work?

[thomas-fossati]

A preview of that is in the cmw-in-submods branch: 701013c

[carl-wallace]

Adding use of submod extensibility here seems like a good idea to me.

[henkbirkholz]

lgtm

[nedmsmith]

LGTM