On 2022-06-10 21:26, Laurence Lundblade wrote:
<snip>
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.
I would be cautious using EAT "as is" for media types. The media industry seems to prefer built-in meta data since this permits existing viewers to read files even if they contain non-recognized meta data.
Translated to EAT that would be a specific EAT meta data entry holding an enveloped signature (like in signed PDF). This also means that the need for segmented strings in EAT seems to be limited.
Yeah, there is a reason why I keep babbling about enveloped signatures in other contexts as well; keeping data intact is actually quite handy :)
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
+1
Anders
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
_______________________________________________
RATS mailing list
RATS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/rats
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
