Re: [Iot-directorate] [Last-Call] Segmented strings (Re: [Rats] EAT profiles (was Re: Iotdir last call review of draft-ietf-rats-eat-13))

Laurence Lundblade <lgl@island-resort.com> Fri, 10 June 2022 19:26 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96637C13A2B8 for <iot-directorate@ietfa.amsl.com>; Fri, 10 Jun 2022 12:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.93
X-Spam-Level:
X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33okhXERVS1U for <iot-directorate@ietfa.amsl.com>; Fri, 10 Jun 2022 12:26:34 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE49C13A2B6 for <iot-directorate@ietf.org>; Fri, 10 Jun 2022 12:26:34 -0700 (PDT)
Received: from [192.168.1.4] ([75.80.148.139]) by :SMTPAUTH: with ESMTPA id zkH9n6X12Ozp0zkHAn6nJp; Fri, 10 Jun 2022 12:26:32 -0700
X-CMAE-Analysis: v=2.4 cv=Qo2bYX+d c=1 sm=1 tr=0 ts=62a39ae8 a=qS/Wyu6Nw1Yro6yF1S+Djg==:117 a=qS/Wyu6Nw1Yro6yF1S+Djg==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=_hTkzDD1zz-xfwdf_-0A:9 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <9a938d66-55b9-c4e4-a5cf-0d655a90fcbd@it.aoyama.ac.jp>
Date: Fri, 10 Jun 2022 12:26:31 -0700
Cc: Carsten Bormann <cabo@tzi.org>, Eliot Lear <lear@cisco.com>, iot-directorate@ietf.org, draft-ietf-rats-eat.all@ietf.org, last-call@ietf.org, rats <rats@ietf.org>, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <42D33BB4-CEBC-41C0-BDA3-947BD015634E@island-resort.com>
References: <165443386776.35361.12898474920348394274@ietfa.amsl.com> <E267AEDE-D1DB-415B-B28F-DD78A517D27A@island-resort.com> <A38F37B7-2E81-451F-86BA-0A041760EB7E@tzi.org> <9E4661C8-DFB7-4BC3-A7B5-150C774917F0@island-resort.com> <8C044EB7-92CF-4306-9025-FD667E1B0F22@tzi.org> <B7C27559-92B6-4426-821B-431A08341C72@island-resort.com> <6CDA1CA0-A59A-4ED7-903F-0B6829F08075@tzi.org> <AC2E17A1-52E7-455F-8959-091D58AA291F@island-resort.com> <9a938d66-55b9-c4e4-a5cf-0d655a90fcbd@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.3445.104.21)
X-CMAE-Envelope: MS4xfG5PbqIvrHrZKwxI58gPM0svBKMdrfmN4xgIb8vyWJ0YdKpf+CzUmRbkOTFaueYO5XOH2SKsVTwOqFvgkucz9umBRbZWjmfdEM1dsSmuwaxQcijvfdvd 0Wep8xJMsqd+AioWL38S7Aw3yXoxPaLFNKbQ5SVrPJyltUu+nI1z1Ltr54fhYEI7mt4aubbTT83LatHhQmcMtBuDPB5AltkMoiZ1jBGseQzwWe8mIrUWz+Ap QM1yTTdK1Jex8kAJZBKXm1QcFpQG2cPjFVDKZaM3wrVDw5j/u0m4z2RcRtFXMmWOwVOHb5RXCDmGpRjo5XupyxqIwVFERqmY3yVujAPxy3WSSqw3wCQC4gOP vBRRd75WQTp+ZZCy6uSfbnKxbp8iYRVtduDb4N53v4XRqi4pLmE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/B-6f8yhEQBL5Vfxt58i2idEYshM>
Subject: Re: [Iot-directorate] [Last-Call] Segmented strings (Re: [Rats] EAT profiles (was Re: Iotdir last call review of draft-ietf-rats-eat-13))
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2022 19:26:35 -0000

Couple of comments below

> On Jun 9, 2022, at 11:50 PM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> 
> Hello Laurence, others,
> 
> On 2022-06-10 04:57, Laurence Lundblade wrote:
>>> On Jun 9, 2022, at 12:30 PM, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> On 2022-06-09, at 21:17, Laurence Lundblade <lgl@island-resort.com> 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