Deeply nested SNP Report type

[derpsteb]

Hey,

currently the Report type does not parse the nested types it includes. For example the TCB versions included are parsed as uint64 and require another function to parse the included data from the field.

How do you feel about accepting a contribution that would change the existing Report type to a nested type that includes subtypes like TCBParts? It seems to me like this would change the layout of the lib in a few places, hence the question.

Best,
Otto

[deeglaze]

That is a breaking change that would need to get in before this tool gets wide use and the message type depended on. No more breaking schema changes would be allowed after 1.0. I'm open to this, seeing as we don't have any separate message consumption jobs that we would need to worry about versioning.

So, signer_info, platform_info, all the tcbs, and policy all should have interpretation messages looks like. I think I would prefer to have those interpretations as new field numbers while marking the raw values as deprecated for removal before v1.0. What do you think?

[derpsteb]

Great! That sounds good to me.
I am not sure yet if/when we would like to implement this and this was mainly to get a first impression if this is even a route that we could take. I will report back if there are more immediate plans. You can close this if you want.

[deeglaze]

Before we go too deep into changing up this format, I do want to say that I'm working with the RATS CoRIM folks to see if we can map all these fields into that, in which case the bit fields will indeed be split out into different named fields.