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

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 22 June 2022 03:51 UTC

Return-Path: <anders.rundgren.net@gmail.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 9FAE0C14CF1A; Tue, 21 Jun 2022 20:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.981
X-Spam-Level:
X-Spam-Status: No, score=-3.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 YsXSHqhY3qJK; Tue, 21 Jun 2022 20:51:32 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E56CC14CF06; Tue, 21 Jun 2022 20:51:32 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id j5-20020a05600c1c0500b0039c5dbbfa48so10292621wms.5; Tue, 21 Jun 2022 20:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=KcDmb5pZqC5+b92C/uJcxTHzo7hblw9NZhuGll7TBWg=; b=LbT8SNNyULB6aUOE06g4GS7hVw0X50u8gLzcmP+yiIwOjZj0rhrs6rSxxMd/fWW2zM YqsxCnGtW5Xhcx6v453RLwgsUODzsiZoehl78d985pP/7t49wlZGd357fB76XTdjxlqf YTsbtGj3EF8cEVBWb8pQoEqkQBoGC955kENn6PfVIId7geJ16DX3TO1jZivViD2olOGX blp5nTnActvvVC36ZRHQ8JhXJHfiPBheu4TfF4vLRZFztCHUrBp3hh82xLJIY+E3W9Gc wbgNqJ3k1tvpMtjubXGQxj1X6Opra+Vv/XceHTeO2qexaLEEji5WnJ16oX2XAb7wj7Lb 1lYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=KcDmb5pZqC5+b92C/uJcxTHzo7hblw9NZhuGll7TBWg=; b=Txk+adaKGolPvir9ilBtJaZnv9eLkR7CzaTt2PSMTwvD0DfYtVLMGaBsSLOZyb1Jhn ur5qypUv+O1zUhJAwxPisvvq9diRwwvX0UUBFbHkoKHO+OHB/05Oz8eEq4J+8uGFoW18 vwOnTfDFbkWv+qT09YGtMx0pXmqvbAuX3b67xvZOjQND0bN6OZiL6x+xrTVT0hORyrh+ RYATrNzYUme5L7oV3s2MhXod01WTOFtu41F55c7D+02+FZJY9XdXHd6wC0lR6vBLAWBW NwFphWujOoCEajlz8mO/8YR4GrczXH4NVJYRAN8MvS5VNU5Tf1H1oxRUj8kPPlt/Uszy bfFg==
X-Gm-Message-State: AOAM533MdgGgwEueSWS8cja4xXfUyEIm40vkGbRS8Ey/03ahe62+q9HY gXsgk21HlJNWRiU09cNimf8=
X-Google-Smtp-Source: ABdhPJyhkfAIGiR0zwh256ypeWgAQTWej3wQwwsz1+1LRvU4yH1r7IHo5nIzgdmK2HievAPohfZOvg==
X-Received: by 2002:a05:600c:a42:b0:39c:9086:8a34 with SMTP id c2-20020a05600c0a4200b0039c90868a34mr43355007wmq.169.1655869889410; Tue, 21 Jun 2022 20:51:29 -0700 (PDT)
Received: from [192.168.43.244] (239.107.23.93.rev.sfr.net. [93.23.107.239]) by smtp.googlemail.com with ESMTPSA id n68-20020a1c2747000000b0039c5a765388sm19787963wmn.28.2022.06.21.20.51.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jun 2022 20:51:28 -0700 (PDT)
Message-ID: <982fb5b1-cf2d-6c8d-aea8-d7a87ca0c300@gmail.com>
Date: Wed, 22 Jun 2022 05:51:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Laurence Lundblade <lgl@island-resort.com>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
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
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> <42D33BB4-CEBC-41C0-BDA3-947BD015634E@island-resort.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <42D33BB4-CEBC-41C0-BDA3-947BD015634E@island-resort.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/X8lYft9T1pedy514LWn8SmcYvsM>
Subject: Re: [Iot-directorate] [Rats] [Last-Call] Segmented strings (Re: 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: Wed, 22 Jun 2022 03:51:32 -0000

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@ietf.org
> https://www.ietf.org/mailman/listinfo/rats