IETF Logo Mail Archive

Re: [core] FW: New Version Notification for draft-fossati-core-parametrized-cf-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 11 June 2022 14:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14A6C14F740 for <core@ietfa.amsl.com>; Sat, 11 Jun 2022 07:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.709
X-Spam-Level:
X-Spam-Status: No, score=-6.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=sandelman.ca
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 tV23oqe0hwAO for <core@ietfa.amsl.com>; Sat, 11 Jun 2022 07:23:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 A8D65C14F729 for <core@ietf.org>; Sat, 11 Jun 2022 07:23:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BB2439437; Sat, 11 Jun 2022 10:38:48 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EwnixJgx8dLm; Sat, 11 Jun 2022 10:38:43 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D775393BE; Sat, 11 Jun 2022 10:38:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1654958323; bh=CrKD0LIUaePTvpsdVt+U1lMlubH+EEWsRTPPKoTkrr4=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=9O8uDTDA1Yv4XKiSaqtRgThlr0JKSTbXathb5MkIdlMWHuJtSefeH5tAyqAHSR4h4 0ALJRYo4/adIjACJ+lBW9LRpawjO5L47pxi8scdH5CBCpWrbsG0dFJ7zXyEzJi82d/ 0b9EHmiaaBAsY+eWjqxz0w3faTTAO6rVVDPJjg4T+8dcq3VJQZKjdyZz7woRyfkWMF Ir7Ca/os7upyxKEKLQhOMNlkWCLXhnIrSgWht54lqmP+0a19vNcyUliS4JsKkgVk+t QaSZlosVoUb/AYgkppaH7iZHH45pyYdm8RBHv1c0mAdme81sL16Z3tHSBcIax5jOHO LK9Ucf9DBW3ig==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DEDCF73D; Sat, 11 Jun 2022 10:23:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Thomas Fossati <Thomas.Fossati@arm.com>
cc: "core@ietf.org" <core@ietf.org>, Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <DB9PR08MB6524DE08842682FDBA2360279CA69@DB9PR08MB6524.eurprd08.prod.outlook.com>
References: <165487268698.43433.9781458392174640102@ietfa.amsl.com> <DB9PR08MB6524DE08842682FDBA2360279CA69@DB9PR08MB6524.eurprd08.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 11 Jun 2022 10:23:12 -0400
Message-ID: <2581.1654957392@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/gqBR8wbdRw3T9TkIjYSMox2_iQg>
Subject: Re: [core] FW: New Version Notification for draft-fossati-core-parametrized-cf-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jun 2022 14:23:24 -0000

Thomas Fossati <Thomas.Fossati@arm.com> wrote:
    > We have sketched this draft as a proof of concept and would be really
    > interested in your opinion as it touches on some of CoAP building blocks
    > for content identification and negotiation.

    > A bit of context to (hopefully) help you understand the reasoning behind
    > the choices made in the proposal:

    > * EAT media types [1] are parametrised on a "profile", and we expect
    > these profiles to be many.

okay, so you made me read your draft.
Conceptually, it seems fine, but do we really need it, is the ask.

There is an assumption you've made that EAT will be carried over CoAP.
I think that it will be carried over CoAPS, possibly over a DTLS-keyed OSCORE
or an EDHOC-keyed OSCORE.
I bring this up because it opens new places in which to specify the expected
profile.  For instance, ALPN.   Is that a good place? I don't know yet.

    > * Content formats scale linearly with the number of profiles: each time
    > a new EAT profile is defined, a new content format needs minting.
    > * This (potentially) creates pressure on the C-F registry.  Note that

I can't see there being as many as 100 profiles.
I think that if we get to 16, that it is probably already a disaster.
So, I think, assuming that C-F is a good way to signal profiles, that we
should just burn the C-F.

I think that a particular Attester will implement a single profile.
Given how deep some Attesting Environments are buried, it is unlikely that
they will get upgrades very often.  It will be the job of the Verifier to
adapt, so the profile could be carried as an OID in a PKIX certificate for
the Attester, for instance.  (Where symmetric keys are used, as an attribute
on the key)


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email