Couple of comments below > On Jun 9, 2022, at 11:50 PM, Martin J. Dürst <duerst@xxxxxxxxxxxxxxx> wrote: > > Hello Laurence, others, > > On 2022-06-10 04:57, Laurence Lundblade wrote: >>> On Jun 9, 2022, at 12:30 PM, Carsten Bormann <cabo@xxxxxxx> wrote: >>> >>> On 2022-06-09, at 21:17, Laurence Lundblade <lgl@xxxxxxxxxxxxxxxxx> wrote: >>>> >>>> One person legitimately implements sending EATS with segmented strings Another person legitimately implements without being able to decode segmented strings. >>> >>> Well, an implementation that doesn’t handle segmented strings may be “legitimate”, but it won’t be a complete implementation (and thus not interoperable) if you decide EAT to make no restrictions on generating segmented strings. >> Maybe use the term “fully conforming” rather than “legitimate” or “complete” where "fully conforming" means adherence to what is in the specification and its normative references and no more. No tacit assumptions about the way typical libraries behave or their level of completeness are required to guarantee interoperability. > > "fully conforming" doesn't sound right to me. I'd expect everybody to expect that two fully conforming implementations would be guaranteed to interoperate. > > What about "minimally conforming"? "Two minimally conforming implementations are not guaranteed to interoperate." sounds much more reasonable than "Two fully conforming implementations are not guaranteed to interoperate.” Yes, that’s what I mean to say. :-) > > Regards, Martin. >> Since the CBOR specification also says “some applications and protocols will not want to use indefinite-length encoding”, I’d like to understand if there even exists a reasonable case for an EAT which requires indefinite length encoding. > > Embedding a video in an EAT? Evidence that war crimes videos are from a real trusted camera. Evidence that still pictures for an insurance claim are not Photoshopped. Big SBOMs. That makes it pretty clear we should not exclude indefinite lengths from EAT. Still, these may not be common use cases. We could provide a base constrained device profile in the EAT document: 7.2.1 - CBOR only (no JSON) 7.2.2 - No indefinite-length maps or arrays 7.2.3 - No indefinite-length strings 7.2.4 - Preferred encoding required 7.2.5 - COSE_Sign1 protection 7.2.6 - Receiver must accept ES 256, ES384 and ES 512. Sender must send one of these. 7.2.7 - DEB is not used 7.2.8 - UEID serves as a verification key identifier (a bit awkward as the unverified token contents must be decoded to get the key to verify the contents) 7.2.9 - (Not sure what to recommend for Endorsement identification) 7.2.10 - A new single unique nonce is used for every token request 7.2.11 - 7.2.14 - No recommendation made as this varies too much by use case 7.2.15 - The token should not be a CBOR tag. It is assumed the carrying protocol identifies the token as a nonce 7.2.16 - No recommendation for manifests or evidence as this varies too much by use case LL -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
