Re: [Rats] CoRIM Comments

Hi Hannes,

Yogesh just replied withe the most important essentials. A few 
additional early replies in-line.

Viele Grüße,

Henk

On 04.01.24 14:41, Yogesh Deshpande wrote:
> Hello Hannes,
> 
> Thank you for reviewing the document. The CoRIM team would work on clarifying more in the introductory section the overall goal.
> 
> In the meantime, please feel free to raise specific github issues in the `corim` repository for specific sections!
> 
> In terms of general concepts about CoRIM, please also have a look at the equivalent TCG document:
> 
> https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-V1-R38_pub.pdf
> 
> May be that we can borrow some things from the above document, to enhance general readability.
> 
> Regards,
> 
> Yogesh

On 04.01.24 13:13, Hannes Tschofenig wrote:
> Hi all,
> 
> 
> I have read the Concise Reference Integrity Manifest (CoRIM) 
> specification and in light of the weekly meetings various people have to 
> progress that document I thought I should share my impressions.
> 
> 
> It is unfortunate that the RATS architecture does not even mention the 
> term "Reference Integrity Manifest" but that's a pattern we already got 
> used to.

I am less worried about new terms instead of using terms from the 
architecture incorrectly. The CoRIM I-D inherits quite a few terms from 
RFC 9334, but the quality of the text is still mediocre in some places, 
admittedly. But there are various contributors and text consistency is 
going up and down while the document progresse

I'd be more worried about not using the wording of RFC 9334 correctly, 
such as the stand-alone use of 'attestation', which is a pattern that is 
definitely discouraged by RFC 9334, but still it happens all the time. I 
hope we do not get used to that.

> It is not clear why this is a good term to describe this 
> functionality but absent a clear definition in the document it is 
> difficult to argue.

RIM is a decades old acronym introduced by TCG (the SDO that basically 
came up with the core concept).

> 
> 
> Overall, the document is hard to read. As a reader one is lost in 
> details and there is no big picture. The introduction is 2 paragraphs 
> long to be followed by lots of CDDL definitions in the terminology 
> section.

I strongly agree. Contributors and editors currently work bottom-up to 
address and align industry use cases. The draft definitely lacks more 
expositional test as it dives into the details real quick (not to forget 
the currently way to detailed toc hierarchy).

> The document also defines new abbreviations, which do not make 
> it easier to read. I don't believe there is much value in introducing 
> terms like CoBOM and CoMID.

I personally strongly disagree with that notion. I cannot really speak 
for all contributors, but I am rather sure they would disagree, too. It 
is important to name concepts in order to differentiate them from other 
semantics (and to find out where they can re-applied and where new ones 
are necessary). The 'names of the named concepts' can change, if the 
meaning changes too much. But it is most vital to name different things 
differently in order not to talk past each other when aligning 
contributions.

> 
> 
> What is actually the goal of the document?

The goal is to explain Attesters to Verifiers in support of the 
appraisal procedures conducted by Verifiers. The messages defined can 
convey the RFC9334-defined Reference Values and (conditional) 
Endorsements. The 'default profile' that CoRIM comes with addresses the 
appraisal of Evidence produce by DICE, but TPM-generated Evidence is on 
the roadmap. At the end of the last year, editors/contributors agreed 
that a definition of Verifier behavior must also be part of the draft to 
enable better implementation interoperability.

> The abstract points out that 
> the task for the Verifier is rather complex and it needs a lot of 
> information. It talks about two pieces of information, namely 
> endorsements and reference values. We know from discussions on the list 
> that it also needs trust anchors and policies. Policies, as far as I 
> understand, are not covered. The trust anchor provisioning is, as 
> discussed on the list, in a separate draft. As far as I can tell, it is 
> not possible to create an interoperable implementation with the CoRIM 
> and the CoTS specifications alone.

The CoRIM I-D text is based on real-world implementations and not the 
other way around, see for example Veraison. If, for example, two 
implementation decisions collide, then that is resolved via 
specification text, collaboratively. The resulting resolutions though do 
not trickle back as fast into the corresponding implementations as they 
are agreed on in the I-D text, which leaves basically two types of 
inconsistencies while the work is in progress:

* existing implementation decisions are not in sync with I-D text
* existing resolutions are not reflected in implementation yet

During I-D progression the amount of inconsistency is an up and down 
with a trend to go down, luckily.

> 
> 
> I am wondering whether the CoRIM draft even takes the right approach. Is 
> there an interoperability problem that needs to be solved? If there is 
> one, what exactly is it? I am not even sure whether the underlying model 
> is in practice so simplistic. Reading in between the lines the model 
> seems to be that Evidence is the input and then there are expected 
> values compared against in an equality-matching-style. It would be good 
> to spell out what the limitations of the model are.

There are definitely limitations to the intended 'default profile' scope 
and the I-D will include appropriate expositional text. At the moment, 
the majority of the work is on a technical level to allow for proper 
interoperability. After addressing the topic of Verifier Behavior this 
year, the goal is to come back to more abstract text, such as 
Introduction and Overview

> 
> 
> The draft does not contain examples (yikes).

As the actual layout of the CoRIM data structures are currently under 
churn, it requires significant (automated) effort to keep them in sync 
with the CDDL definitions. There are quite a few examples though. Both 
in the github repo as well as it's corresponding wiki, which is used to 
align proposals quite frequently.

> Since I wanted to see 
> examples I looked at Veraison, which offers an implementation of the 
> draft. As you can imagine, a developer has to write these complex 
> structures somehow and pass them into the tools. JSON was obviously used 
> for this purpose. Unfortunately, the names of the elements in those 
> JSON-based structures are not in sync with the CBOR-equivalent from the 
> draft. Since the document focuses on CBOR there is no such equivalence 
> to expect but it makes the life of a developer so much harder and why 
> CBOR has been used here for a unconstrained Web interface is a mystery 
> to me. Here is an example. Imagine you want to specify a reference value 
> for a bootloader - a concept that should be super simple. The draft 
> defines the following structures (simplified version for readability):
> 
> 
>     reference-triple-record = [
>       environment-map
>       measurement-map
>     ]
> 
>     environment-map = non-empty<{
>       ? &(class: 0) => class-map
>       ? &(instance: 1) => $instance-id-type-choice
>       ? &(group: 2) => $group-id-type-choice
>     }>
> 
>     class-map = non-empty<{
>       ? &(class-id: 0) => $class-id-type-choice
>       ? &(vendor: 1) => tstr
>       ? &(model: 2) => tstr
>       ? &(layer: 3) => uint
>       ? &(index: 4) => uint
>     }>
> 
>     measurement-map = {
>       ? &(mkey: 0) => $measured-element-type-choice
>       &(mval: 1) => measurement-values-map
>       ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
>     }
> 
>     measurement-values-map = non-empty<{
>       ? &(version: 0) => version-map
>       ? &(svn: 1) => svn-type-choice
>       ? &(digests: 2) => [ + digest ]
>       ? &(flags: 3) => flags-map
>       ? (
>           &(raw-value: 4) => $raw-value-type-choice,
>           ? &(raw-value-mask: 5) => raw-value-mask-type
>         )
>       ? &(mac-addr: 6) => mac-addr-type-choice
>       ? &(ip-addr: 7) =>  ip-addr-type-choice
>       ? &(serial-number: 8) => text
>       ? &(ueid: 9) => ueid-type
>       ? &(uuid: 10) => uuid-type
>       ? &(name: 11) => text
>       ? &(cryptokeys: 12) => [ + $crypto-key-type-choice ]
>       * $$measurement-values-map-extension
>     }>
> 
> 
> Here is what I have to specify in Veraison with CoCli
> 
> (CoCli = Corim command line interface):
> 
> 
>      "reference-values": [
> 
>        {
> 
>          "environment": {
> 
>            "class": {
> 
>              "id": {
> 
>                "type": "psa.impl-id",
> 
>                "value": "YWNtZS1pbXBsZW1lbnRhdGlvbi1pZC0wMDAwMDAwMDE="
> 
>              },
> 
>              "vendor": "ACME",
> 
>              "model": "RoadRunner"
> 
>            }
> 
>          },
> 
>          "measurements": [
> 
>            {
> 
>              "key": {
> 
>                "type": "psa.refval-id",
> 
>                "value": {
> 
>                  "label": "BL",
> 
>                  "version": "2.1.0",
> 
>                  "signer-id": "rLsRx+TaIXIFUjzkzhokWuGiOa48a/2eeHH35di66Gs="
> 
>                }
> 
>              },
> 
>              "value": {
> 
>                "digests": [
> 
>                  "sha-256:h0KPxSKAPTEGXnvOPPA/5HUJZjHl4Hu9eg/eYMTPJcc="
> 
>                ]
> 
>              }
> 
>            },
> 
>            ...
> 
> 
> As you can see, the two do not align.
> 
> There is a lot more to say about this draft but I have to start somewhere.
> 
> 
> Ciao
> Hannes
> 
> 
> PS: Just a few random notes from reading the draft:
> 
> - CoMIDs are, for example, claims about hardware and firmware while 
> CoSWIDs are claims about software. Firmware isn't software? Later in the 
> text CoMIDs are then re-defined to be claims about hardware, firmware 
> and module composition. I am not sure what "module composition" means in 
> this context. Section 3.1.4.1.5 then defines measurements and says it 
> could be about "software,firmware, configuration files, read-only 
> memory, fuses, IO ring configuration, partial reconfiguration regions, 
> etc." Is this confusing?
> 
> - In the intro of Section 3 we are told that CoMID tags contain triples 
> and it lists 7 of them. The triples are the meat of the entire document 
> and their description is buried in Sections 3.1.4.2 - 3.1.4.10 (note 
> that there are 9 subsections defining triples). The triple is supposed 
> to describe a subject, an object and a predicate. If you, however, look 
> at the definitions of the triples then they are not triples. For 
> example, the reference value triple from above is a tuple with an 
> environment and a measurement. The predicate is the text in the draft 
> and says "predicate = expected". If you like this RDF-style, then why 
> not also encode the predicate to really make it a triple? This would 
> give the entire approach more flexibility. I fear that you will need 
> even more flexibility, which you can only accomplish with a language.
> 
> - Section 3.1 defines the concise-mid-tag structure (not the comid-tag 
> structure) and lists the map elements. One of the elements is called 
> "language". A few lines below the definition it is then referred to as 
> the "lang" member. Just small inconsistencies - but they are everywhere.
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats