Re: [Rats] Should we remove submods from EAT? (was Re: EAT Review Comments)

[Ira McDonald <[e-mail]>]

Hi Laurence,

+1 to keeping submods in EAT spec.

A proliferation of vendor-specific "solutions" to claims for composite
systems
would be a nightmare and defeat interoperability.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Fri, Dec 17, 2021 at 2:26 PM Laurence Lundblade <[e-mail]>
wrote:

>
> > On Dec 16, 2021, at 7:11 AM, Michael Richardson <[e-mail]>
> wrote:
> >
> > Smith, Ned <[e-mail]> wrote:
> >> There has been discussion that EAT as a standalone spec can’t
> >> reasonably be implemented without a profile.
>
> The same is true for CBOR, CWT, JWT, COSE and JOSE (more comments below).
>
> >> Possibly, the profile
> >> context addresses some of these concerns? The PSA draft goes further to
> >> define a profile, but I don’t see it directly addressing the
> >> consideration for multi-vendor device composition.
> >
> > That's unfortunate if that is really the case.  Profiles of profiles of
> profiles.
> > I think of EAT as the profile of COSE that let's us do attestation.
>
> Do you mean EAT as a profile of CWT, not COSE?
>
>
> > If there is a profile, then it would address the naming concern that you
> > raised.
> >
> > In general, I think that every single vendor/integrator who puts the
> right
> > manufacturer supports (Endorsements, Reference Values) and/or operates a
> > Verifier (likely in Background Check model) will need to solve the
> naming and
> > profile problem.    I'm not sure that we need standardization here: it's
> all
> > under control of the manufacturer.
>
> Agreed, submod naming is left to the manufacturer, specifically the maker
> of the Attester. I haven’t been able to come up with anything better so far.
>
> More below in response to Thomas.
>
>
> >
> >> The other EAT claims (not submod) seem to imply a simple composition
> >> where the thing (module) to which the CWT/JWT is issued / bound is the
> >> thing (module) that has the EAT claim.
> >
> > I would prefer that the EAT document was simplified/shortened, that
> anything
> > we do not presently have running code for be removed to another document.
> > I'd like to see EAT published by Summer 2022, even if that means four or
> five
> > extension documents come later.
>
> There is running code for submodules (CToken & Xclaim) and most other
> claims, but not for DEB.
>
>
>
> > On Dec 16, 2021, at 3:37 AM, Thomas Fossati <[e-mail]> wrote:
> >
> > hi Laurence,
> >
> > I agree with you that submods exist for a very good reason. They have
> > particular value if the composition pattern is static and known
> > a-priori (Ned's email has some interesting points in this regard). The
> > existence of submods has enabled some interesting expression during
> > prototyping efforts here.  Note also that I would be concerned
> > that if submods did not exist then that might result in multiple custom
> > solutions emerging to express nesting, which would be a poor result for
> > the wider RATS standardisation efforts.
>
> So, unless a strong consensus emerges, I will keep submods in EAT.
>
> >
> > The current definition is nice and simple, though I would like to
> > explore some extra functionality at some point. The small trouble I have
> > with it is that the string type limits the expressiveness of the submod
> > identifier.  Ideally, one could have a composite, more powerful type on
> > the LHS of the submod definition.  Note that this would be possible in
> > CBOR but not in JSON, so if we want interworking between the two formats
> > we'd need to find another solution. For example one where the RHS
> > clearly separates identification information from the measurements.  At
> > that point the string key would be redundant, or left as a hint.  At the
> > moment I don't have a very concrete proposal (i.e., code) though, so
> > this is just a thought.
>
> Maps with labels that are not strings or integers are generally a bit
> scary and off the beaten path. I suspect many CBOR libraries (like QCBOR)
> have built-in support for maps with string and integer labels, but not for
> arbitrarily complex labels. So some aggregate type in the label would up
> the implementation cost a lot, particular on the decode side.
>
> I don’t know what sort of submods you are trying to implement.
>
> Best I can think of is that you pack some structure into the string label.
> Maybe we also allow byte string labels to help. The Verifier and RP usually
> have ample CPU power and memory so multiple scans of the submods section
> are OK. The implementation can unpack the whole submods section into memory
> including unpacking the structure in the label and do whatever it needs to
> do to get to the submod it wants. Maybe in the extreme, the byte string
> labels are wrapped CBOR.
>
> LL
>
>
>
> A few more comments on interoperability and profiles:
>
> - One CBOR implementation sends indefinite lengths and a receiver only
> decodes definite lengths —> no interoperability
> - There are no required algorithms and no handshake for COSE and JOSE so
> the —> no interoperability is possible
> - There are no required claims in CWT or JWT —> —> no interoperability is
> possible
> - Even the PSA profile of EAT is not locked down enough to guarantee
> interoperability
>
> Though it is common, all this lack of guaranteed interoperability seems a
> bit odd for the IETF in a way. It was a main motivator for me to put
> profiles in EAT.
>
> FIDO has a conformance certification program. The FIDO spec is therefor
> tight on this. In theory vendors on different planets that can’t talk to
> each other can produce interoperable and conformance-passing FIDO
> implementations.
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>