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

["Smith, Ned" <[e-mail]>]

(speaking not as chair)
If submods claim is Evidence, then there is an expected Reference Values expression that matches it. The RV schema could contain more richly typed expressions that the Verifier might rely on for interpretation of the submods label value. If it is a string, but the RV typing expects binary ('bstr') then the label should be an ascii-fied encoding of the binary label. If the label were however a choice (CDDL type choice) that permitted both 'str' and 'bstr' forms then the Verifier can rely on the encoding to tell it which form to compare against.
-Ned 

On 12/17/21, 11:26 AM, "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.