From nobody Tue Jul 2 02:15:38 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C790A120047 for ; Tue, 2 Jul 2019 02:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sCyJrzuvd2U for ; Tue, 2 Jul 2019 02:15:35 -0700 (PDT) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D774D120026 for ; Tue, 2 Jul 2019 02:15:34 -0700 (PDT) Received: by mail-ot1-f52.google.com with SMTP id z23so16429078ote.13 for ; Tue, 02 Jul 2019 02:15:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nvFYlxle3qaU5RtyWqJrbMiZ1Rpqa9Lyqnk04UUiAPk=; b=gsLvxYJaDUPBS8KJIvaUC8bJheiarijI8fKTmipCOCNuhZkHfncPuf+RUAIYFzdzT8 PVSez/VmoyAGR1TKlctJQRXNZTafgU9aYv6beXuVuzjocVH4DeThnZzBjXAz5NBj2HeR 3y+t/tw0WFkB6m765NUr8WRsnJ2MzKxY2iWuxDqIHPqu0Ss9+yrb+bEQoIq28dxNTWQh zJKxb7+M2et+uVTGP6oxDdfZvOm0DiAjBAzoQ99AH2jfY4oM21RgXF8yNgFTUxcY+xsa x/QsBndDQdqqN7/ieT4iOH29RtsvgCDdOe8W3ZYKKvDM/bdrc1DyA+Jm0Q/FhTTeP9jG Tlhw== X-Gm-Message-State: APjAAAVMRp/5cPsk+TF5LF9rqnh0q4jziaoX7Zl9515Gnb2YD89vyqAO YTkcolmA6kXcbp5C4A95Yjwbu1TZbT+TJg3rIPVrNZ2c X-Google-Smtp-Source: APXvYqwCk2CZLjWBLrJ+ddI2b2NTQnfzO0sM2lsuOQUmTy0HFLaQaajrZ37g6DnO6B1ezHCaTuucX/QGd/Vwyar25kY= X-Received: by 2002:a9d:67d5:: with SMTP id c21mr23811343otn.243.1562058933882; Tue, 02 Jul 2019 02:15:33 -0700 (PDT) MIME-Version: 1.0 From: Emmanuel Baccelli Date: Tue, 2 Jul 2019 11:15:22 +0200 Message-ID: To: suit@ietf.org Content-Type: multipart/alternative; boundary="000000000000df55e7058caf2f57" Archived-At: Subject: [Suit] RIOT Summit 2019: Call for Contributions X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 09:15:37 -0000 --000000000000df55e7058caf2f57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Apologies for potential cross-posting) ************************************************************************ CALL FOR CONTRIBUTIONS RIOT Summit 2019 September 5-6, 2019 Aalto Design Factory, Helsinki, Finland https://summit.riot-os.org/2019/ ************************************************************************ RIOT is an open source operating system for microcontroller-based IoT devices, https://riot-os.org/ . Initially developed by folks from academia, the RIOT community now consists of companies, makers and hobbyist, distributed all around the world. The RIOT community meets annually f2f at the RIOT Summit, which brings together RIOTers, beginners and experts, as well as people interested in the IoT in general and decision makers who plan to deploy RIOT in the future. The event combines plenary talks, hands-on tutorials, and demos. This year the RIOT Summit will take place at the Aalto Design Factory, Helsinki, Finland. The first speakers have been announced, including a keynote by Jari Arkko. More details are available at https://summit.riot-os.org/2019/ . The organizers of the RIOT Summit call for contributions that relates to RIOT and the Internet of Things. If you want to present a talk, a tutorial or a demo, please consider the Call for Contributions: * https://summit.riot-os.org/2019/call-for-contributions The following companies generously support the RIOT Summit 2019: Cisco, Ericsson, wolfSSL, Z=C3=BChlke. Best regards, the organizers, on behalf of the RIOT community --000000000000df55e7058caf2f57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(Apologies for potential cross-posting)

******************************************************= ******************

CALL FOR CONTRIBUTIONS

RIOT Summit 2019
September 5-6, 2019
Aalto Design Factory, Helsinki, Finland

= https://summit.riot-os.org/201= 9/

*************************************************************= ***********

RIOT is an open source operating system for microcontrol= ler-based IoT devices,
http= s://riot-os.org/ . Initially developed by folks from academia, the
R= IOT community now consists of companies, makers and hobbyist,
distribute= d all around the world.

The RIOT community meets annually f2f at th= e RIOT Summit,
which brings together RIOTers, beginners and experts, as well as people interested in the IoT in general and decision
makers = who plan to deploy RIOT in the future. The event combines plenary
talks,= hands-on tutorials, and demos.

This year the RIOT Summit will take= place at the Aalto Design Factory,
Helsinki, Finland. The first speake= rs have been announced,
including a keynote by Jari Arkko.
More deta= ils are available at https://s= ummit.riot-os.org/2019/ .

The organizers of the RIOT Summit call= for contributions that relates
to RIOT and the Internet of Things. If y= ou want to present a talk,
a tutorial or a demo, please consider the Ca= ll for Contributions:

=C2=A0 * https://summit.riot-os.org/2019/call-for-cont= ributions

The following companies generously support the RIOT Su= mmit 2019:
Cisco, Ericsson, wolfSSL, Z=C3=BChlke.

Best regards,
the organizers, on behalf of the RIOT community<= br>
--000000000000df55e7058caf2f57-- From nobody Tue Jul 2 07:15:23 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416491200B6 for ; Tue, 2 Jul 2019 07:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W68s37Md00Wa for ; Tue, 2 Jul 2019 07:15:19 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCE6120041 for ; Tue, 2 Jul 2019 07:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DCC7BE2044; Tue, 2 Jul 2019 10:15:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31643-03; Tue, 2 Jul 2019 10:15:12 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 178BFE2040; Tue, 2 Jul 2019 10:15:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1562076912; bh=iielasGU5xa7UNgT7VhSAoL4KWmBQ3lsDYpUCTRr/74=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=KL9eMg6Xo/cP2/65fQkNGdhthJKVgl3pPi/A1lZmME8GmDpCqNpSBJ7JTchOmOXI2 B4+P1PhM9/iS0cr1TMIo3+eNdeJpX9wPJAazpJF2GndvaucsJtv6gbP5P8k0j+oSwW kb2bC3HTOMyeMkJwmZUeRO5/+uSJ2/MIPvS/+ogo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x62EF6tJ015241; Tue, 2 Jul 2019 10:15:06 -0400 From: Derek Atkins To: Janos Follath Cc: "suit\@ietf.org" References: Date: Tue, 02 Jul 2019 10:15:06 -0400 In-Reply-To: (Janos Follath's message of "Tue, 4 Jun 2019 13:35:02 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Suit] draft-atkins-suit-cose-walnutdsa X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 14:15:21 -0000 Dean Janos, Sorry for the delay in responding; I've been on the road for most of June and it's taking me a while to catch up on the ~10,000 emails that piled up while I was (mostly) offline. We have customers who are looking to use this technology today, so we would like to do it in a standard way that others could understand. Personally, I'm fine with an Informational (instead of Standards-track) publication if that would make people happier. Even so, the RFC Editor would still require approval from this WG as it is within their (the WG's) area. There is no rule requiring the CFRG to approve informational documents. Thanks, -derek Janos Follath writes: > Dear Derek, > > I think that before standardising a new cryptographic scheme in IETF it > would be prudent to have it approved by CFRG first, I believe this > might even be a rule. > > If I remember correctly, then the Hash-based signature proposals have gone > through some kind of an approval process. Has the CFRG approved WalnutDSA > too? > > Regards, > Janos > >> [Suit] draft-atkins-suit-cose-walnutdsa > >> > >> Derek Atkins >> Tue, 14 May 2019 13:05 UTC > >> >> Hi everyone, >> >> I have submitted a new draft on how to use WalnutDSA in COSE, targeting >> SUIT as a viable use-case. WalnutDSA is in use for a secure boot >> solution now; specifying how to use it in a standard way would help >> others leverage the technology (or at least ensure there are no >> conflicts with others). >> >> I have tried to follow the framework of the Hash-based signature >> integration (with Russ' approval). >> >> -derek >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Jul 2 08:24:03 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A0D1202D0; Tue, 2 Jul 2019 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCoXOX0RQAnI; Tue, 2 Jul 2019 08:23:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C7B1202AF; Tue, 2 Jul 2019 08:22:51 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E102380BE; Tue, 2 Jul 2019 11:20:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3BD50BE6; Tue, 2 Jul 2019 11:22:49 -0400 (EDT) From: Michael Richardson To: Derek Atkins , cose@ietf.org cc: "suit\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [Suit] draft-atkins-suit-cose-walnutdsa X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:24:01 -0000 --=-=-= Content-Type: text/plain Derek, looking at the IANA Considerations of draft-atkins-suit-cose-walnutdsa, it seems that you need a number in: 1) COSE Algorithms -- registry 2) COSE Key Types -- registry and several in the 3) COSE Key Type Parameters -- registry https://www.iana.org/assignments/cose/cose.xhtml#algorithms For the first, you can have: Integer values greater than 65535 Expert Review And the other two are Expert Review anyway, no specification required! You are even listed as one of the experts for COSE Key Types :-) {If my reading is correct, you can also use strings longer than 2-bytes without registration with IANA, but that has an operational (maintaining legacy code) and bytes-on-the-wire impact should you be allocated a shorter code later on} You could also ask for early allocation via the COSE WG, but that probably requires the document to be adopted first! That's what I would do: just ask for the values via Expert Review, and live for now, with the a five-bye (encoded) COSE Algorithm code, if your market need is urgent. Derek Atkins wrote: > We have customers who are looking to use this technology today, so we > would like to do it in a standard way that others could understand. > Personally, I'm fine with an Informational (instead of Standards-track) > publication if that would make people happier. Even so, the RFC Editor > would still require approval from this WG as it is within their (the > WG's) area. yes, if you went ISE, which would still take awhile. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0bdsgACgkQgItw+93Q 3WUTgAf9HYHgpEvhnT8vMBzP9YVoR44j0KFMH51o0vjCSKaCzGij0/z/xt0FnkeJ 9RzclmRFpMUEQcKJX5KCorFzgzujlcQyJfAEaCc91x17SoOjHRp/i2O9T/ya3X0S iCnL01ZoT8FiP5sR0dA3LBSiDx2EHrpa3AJjQUCcwYsMgRbZmNOm6kZuSCvcTfPh 4F0a1cJ9smMkWn6OgHYSLdTEjbxih+Ary9qi4StWZW2BnX50mKfP5+YmEAuuGbI7 dWJdC0sqvV0+7Z5UGG4nrQOxiUjL5MbnKETtgioXTOBRRC4DmWy5yqurC0LRaxA1 mbd0OavKyfHvopG630G960KWadNZ3g== =DtOF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 2 12:38:41 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96881206F9 for ; Tue, 2 Jul 2019 12:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YccyO2xAuysP for ; Tue, 2 Jul 2019 12:38:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31228120701 for ; Tue, 2 Jul 2019 12:38:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C8CD1380BE for ; Tue, 2 Jul 2019 15:36:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E4C15BD8 for ; Tue, 2 Jul 2019 15:38:18 -0400 (EDT) From: Michael Richardson To: "suit\@ietf.org" In-reply-to: <7DB0F916-D455-435D-B58B-3C919376918F@arm.com> References: <12354.1560790046@dooku.sandelman.ca> <9314229C-01E8-4CCC-8EFD-4F5715072C30@arm.com> <30900.1560890785@dooku.sandelman.ca> <12665.1560903963@dooku.sandelman.ca> <7DB0F916-D455-435D-B58B-3C919376918F@arm.com> Comments: In-reply-to Brendan Moran message dated "Thu, 20 Jun 2019 13:53:29 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr 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 Archived-At: Subject: Re: [Suit] Call for adoption on manifest draft X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:38:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1) I think we should adopt. Brendan Moran wrote: > I believe that the behavioural (or procedural) approach has many > benefits, but I want to stress that this is not about solving some > arbitrarily complex problem; it=E2=80=99s about compact encoding, mee= ting the > requirements we have, and enabling precisely defined device behaviour. I wonder if we could uplevel the "commands" a bit? > First, I have three observations about firmware update: > 1. To eliminate a source of user error, simplify management, etc., we > can=E2=80=99t have many similar formats, there needs to be just one. = 2. Making > a parser small and easy to validate requires a simple format, with few > unique structures and low nesting depth. 3. Almost all user stories > and security requirements are implemented with a small number of > fundamental operations. I agree with these goals. I think that you have done a good job of eliminating nesting (stack depth) = by allowing the manifest to be processed multiple times, with antecendent conditions causing already executed steps to be skipped/elided. > simple to process. This should mean that we are able to achieve parser > simplicity goals for a constrained device without sacrificing > capabilities needed only on larger devices. I'm having difficulties understanding how the less complex devices would ha= ve less complex parsers. What I see is that simpler devices will have shorter SUIT_Directive. > 6. Extensible I'd like to suggest that we consider an way for a boot firmware manufacturer (1) to indicate what things are supported on a particular device, such that= a device manufacturer (2-Author) would know which directives are valid, and s= o that a network operator (3) can know what's possible. Just to fill in numbered blanks above, I think we are missing some terminology: (1) - would be the entity that built the Manifest parser, etc. I perceive that in your ecosystem, this is you (ARM). I don't know what to call this role. (2) - this is the Author as per suit-architecture. (3) - the network operator does not seem to be in the suit-architecture as a term. > 7. Comprehensible by an intermediate system In particular, I am concerned about an audit function that (3) might wish to perform. Being able to support such an activity is one of the reasons we want a standard format. And it is here that Extensible and proceedural causes a problem. > There are two classes of metadata used in firmware update, with two > very different sets of constraints. A. The metadata consumed by a > constrained node in order to consume the firmware update. B. The > metadata used by an intermediate system to make decisions about the > update > A) has to be small and easy to parse and process and B) has to be easy > to reason about. In previous drafts, these have been the same. I now > think this is detrimental to the constrained node. I take your point. > However, there are > challenges posed by dividing metadata into consumer and intermediate > metadata. I think we can resolve these issues in one of two ways: > either by using tooling to extract relevant data from the =E2=80=9Cby= te code=E2=80=9D > of the behavioural manifest, or by encoding two sets of metadata using > severable sections, as previously discussed=E2=80=94this will be the = default > with encrypted or partially encrypted manifests anyway. Fair enough. "Encryption" by encoding as byte-code/VLIW is as opaque to hum= ans as encryption by AES128 :-) > If the suit-wg chooses to pursue the behavioural manifest approach, I > think we should focus on tooling to extract information. I don=E2=80= =99t > believe it=E2=80=99s complex to implement, and I=E2=80=99ll endeavour= to prove > that. However, there is certainly some value in being able to encode > data for an intermediate system in a severable section. Since this has > costs in manifest size, I think the best way to do this is to add a > JSON blob as one possible element in the already severable text > section. My concern is that the extraction is not the truth, but rather a (falliable, spoofable) interpretation of what is there. That the potential is there to slip something past the audit stage. That the encodings are now complex enough that we wind up writing an assembly language for it. > However, I think there is one more consideration: implied > behaviour. When a manifest is sent to a device, it is an instruction = to > do something. I think this makes procedural information a much better > match. If the content of that manifest is purely declarative, then the > behaviour of the device is implied. Fair enough. You are saying that there will always be proceedural code. It's between the the implied (and secret) proceedural code in the SUIT-interpreter, vs the explicit (and auditable) proceedural code in the manifest. I take this point strongly! > should do. As long as each information element is isolated, this is > achievable, but if information elements interact, this quickly leads = to > a combinatorial explosion in the specification. I think that this is the part that you are concerned mostly about. I'm not convinced that many (or all) combinations really will make sense. I'd like to have a system (via i.e. "IANA Considerations") that lets new combinations come into play. I think, lacking the experiences you have, that a device from a particular *Author* will generally do upgrades in two or three ways at most. Even a device with N images that needed loaded probably doesn't have N! combinations. This is not the same view from a SoC vendor, where you have to support a mu= ch larger number of Authors. > If the behaviour of the > device for any arbitrary combination of information elements is not > explicit in the specification, then the specification will be open to > interpretation, which will inevitably yield surprising results. For a > security-critical system, like firmware update, the last thing we want > is surprising results. I agree that surprising results are a bad thing. But, can you give me an example of a device with an arbitrary combination of information elements? The only way to I can get there is to assume something like an Android device where the APKs (Apps) are in scope, and I was pretty sure we already said that was out-of-scope. > target. They do present two challenges: interpretation on intermediate > systems and construction by an unskilled (in behavioural manifests) > user. I think that we can solve these challenges and I think that the > interpretation challenge, at least, is less complex than it > appears. > I=E2=80=99m willing to trade complexity on intermediate/authoring > systems for simplicity on a constrained node. What remains to be seen > is whether the suit-wg agrees with my approach or not. To be clear, this is not blocking issue for me. I think that we can improve the descriptions of the directives better. We will need some examples. Are you open to the idea that some of the constructions (sequences of directives) that we might make for the examples might be better as primitiv= es? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0bsqoACgkQgItw+93Q 3WXRmgf/bdnZg6bR32iehv07diK7E9KzrwE2uP1NYZh/+60+lPpjAxh4n8QHwfym BkJrJQfTJEkijiDiX+t3f6Gqf5mF1Thymlx7d0zcNMOJERZ1UxoHb9Krmt8P+Ad2 V+mFWI1VtwxHaH3gj3Z5yXpuVrJZBc42x81LS1N+G0zwF0WhhoJAFxkKOwc84P8Z 7c9NGmewVF5tEcQcSItl4KftyGqrQTENEJ2AMaDYsq/vMU0NqDasMgohDQjOLcUS /H6IvmAcpZap+SddqnGGs/vfOuOfAxZaC5TmOAuZc2hVB2swwHcTlUIAhtrkh/Qu ZggL4lCv2aWOuUlvdr3lPMJ5oscCIg== =PPAk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 3 02:19:13 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5266D120183; Wed, 3 Jul 2019 02:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kai3rO3L9aY; Wed, 3 Jul 2019 02:18:57 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9721201E7; Wed, 3 Jul 2019 02:18:56 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45dwXH2gKyzyXq; Wed, 3 Jul 2019 11:18:55 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 583838332.787861-e2f23fd48e075876f7bf1cfe336364d8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 3 Jul 2019 11:18:55 +0200 To: suit , teep@ietf.org, din@irtf.org, rats@ietf.org, lake@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Suit] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 09:18:59 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF105. Remember that, even though this will now go to the printers, there is still some potential for changes. Conflicts that meet the eye: COSE/TEEP stays; ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. LAKE and LOOPS have been disentangled, thank you. I have put in some side meetings, but that picture may still change (and I don't understand the timezone logic of that system, so it may be all wrong). All times are EDT (Eastern Daylight Time) =3D=3D UTC -4 hours. (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, July 19, 2019 -- OMA/T2TRG Work Meeting - @ Ericsson Montreal Office (St-Laurent) SATURDAY/SUNDAY, July 20/21, 2019 -- Hackathon (including various interops) - Centre Ville SUNDAY, July 21, 2019 -- Sun 1700-1900 Welcome Reception - Place du Canada -- Sun 1800-2000 Hot RFC Lightning Talks - Viger MONDAY, July 22, 2019 1000-1200 Morning Session I Van Horne SEC acme Automated Certificate Management = Environment WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Laurier TSV loops Local Optimizations on Path Segments BOF 1330-1530 Afternoon Session I St-Catherine INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Place du Canada SEC secdispatch Security Dispatch WG Van Horne TSV taps Transport Services WG 1550-1750 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG St-Catherine OPS v6ops IPv6 Operations WG Van Horne SEC *** lake Lightweight Authenticated Key Exchange = BOF 1810-1910 Afternoon Session III Laurier ART dispatch Dispatch WG - Joint with ARTAREA TUESDAY, July 23, 2019 0830-0945 Side Meetings / Open Time C2 (21st Floor) IoT Onboarding and MUD (0900..1030?) Place du Canada IETF tdd Technology Deep Dive - How NICs Work = Today 1000-1200 Morning Session I St-Catherine ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG - 1000-1130 St-Catherine INT ipwave IP Wireless Access in Vehicular = Environments WG - 1130-1200 Notre Dame IRTF icnrg Information-Centric Networking Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG Van Horne SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Centre Ville OPS anima Autonomic Networking Integrated Model = and Approach WG 1520-1650 Afternoon Session II Duluth INT intarea Internet Area Working Group WG Place du Canada IRTF irtfopen IRTF Open Meeting Van Horne SEC oauth Web Authorization Protocol WG Collier CoRAL side meeting (1500..1700?) 1710-1810 Afternoon Session III Duluth ART *** core Constrained RESTful Environments WG Laurier INT 6man IPv6 Maintenance WG Place du Canada SEC tls Transport Layer Security WG WEDNESDAY, July 24, 2019 1000-1200 Morning Session I Van Horne IRTF*** dinrg Decentralized Internet Infrastructure St-Catherine RTG *** roll Routing Over Low power and Lossy = networks WG Viger SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1530 Afternoon Session I Place du Canada GEN netrqmts IETF Meeting Network = Requirements BOF Laurier IRTF pearg Privacy Enhancements and Assessments = Research Group Viger IRTF*** t2trg Thing-to-Thing St-Catherine RTG bier Bit Indexed Explicit Replication WG Centre Ville RTG detnet Deterministic Networking WG 1550-1650 Afternoon Session II St-Catherine RTG babel Babel routing protocol WG Centre Ville RTG detnet Deterministic Networking WG Van Horne SEC *** rats Remote ATtestation ProcedureS WG THURSDAY, July 25, 2019 1000-1200 Morning Session I Duluth ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Laurier TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Viger IRTF coinrg Computing in the Network Proposed = Research Group Laurier IRTF panrg Path Aware Networking RG Place du Canada SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT 6man IPv6 Maintenance WG Place du Canada IRTF cfrg Crypto Forum Van Horne RTG rift Routing In Fat Trees WG St-Catherine SEC *** rats Remote ATtestation ProcedureS WG Centre Ville TSV tsvarea Transport Area Open Meeting 1740-1910 Afternoon Session III Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** ace Authentication and Authorization for = Constrained Environments WG Place du Canada SEC mls Messaging Layer Security WG St-Catherine TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 26, 2019 1000-1200 Morning Session I Notre Dame ART ice Interactive Connectivity Establishment = WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Laurier SEC mls Messaging Layer Security WG Duluth SEC oauth Web Authorization Protocol WG 1220-1350 Afternoon Session I Van Horne SEC *** cose CBOR Object Signing and Encryption WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG Place du Canada TSV tsvwg Transport Area Working Group WG From nobody Mon Jul 8 14:45:45 2019 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2D120240; Mon, 8 Jul 2019 14:45:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: suit@ietf.org Message-ID: <156262233425.976.984283200414205844@ietfa.amsl.com> Date: Mon, 08 Jul 2019 14:45:34 -0700 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-information-model-03.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 21:45:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : Firmware Updates for Internet of Things Devices - An Information Model for Manifests Authors : Brendan Moran Hannes Tschofenig Henk Birkholz Filename : draft-ietf-suit-information-model-03.txt Pages : 36 Date : 2019-07-08 Abstract: Vulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such an update mechanism to fix vulnerabilities, to update configuration settings, as well as adding new functionality is recommended by security experts. One component of such a firmware update is a concise and machine- processable meta-data document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-information-model-03 https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-suit-information-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 24 10:44:27 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01298120630 for ; Wed, 24 Jul 2019 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=uPUd4OQw; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=VbvAT0Ol Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO3t9DeFbAbP for ; Wed, 24 Jul 2019 10:44:18 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130053.outbound.protection.outlook.com [40.107.13.53]) (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 7E13112062E for ; Wed, 24 Jul 2019 10:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=avENIPhkQ9Pd/XquBbKNTkQe/PsbvwOp8XyCTr1wrSs=; b=uPUd4OQwyGk5I27zPcqrGWZuUjK3s5P8ERuB0tfwPWJ8P9sigbUbw4OWMN4tW9W71P4UiGpmvXn94W5ah+uO8twU+Bm6L1vjwnI1SC3Joim+ZLKHhw++lm8c0C/k6MAf3Z/RuycDs9XCb0JJ2/Sm4YepsQytNPCrJAOIiB8gr1U= Received: from VI1PR08CA0249.eurprd08.prod.outlook.com (2603:10a6:803:dc::22) by AM6PR08MB4950.eurprd08.prod.outlook.com (2603:10a6:20b:e1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 17:44:14 +0000 Received: from DB5EUR03FT011.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::208) by VI1PR08CA0249.outlook.office365.com (2603:10a6:803:dc::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.12 via Frontend Transport; Wed, 24 Jul 2019 17:44:13 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=temperror action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT011.mail.protection.outlook.com (10.152.20.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Wed, 24 Jul 2019 17:44:12 +0000 Received: ("Tessian outbound 6d016ca6b65d:v26"); Wed, 24 Jul 2019 17:44:12 +0000 X-CR-MTA-TID: 64aa7808 Received: from dfd9631cbd30.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.0.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id CC4337C5-852B-4885-B87B-F5044C3A1BBE.1; Wed, 24 Jul 2019 17:44:07 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp2059.outbound.protection.outlook.com [104.47.0.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dfd9631cbd30.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 24 Jul 2019 17:44:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uzpg7qCugvlNarz3djBRCogh72wx//ZDctT7xPbSAuRbvnxScpI8N+UzLsJY3DydM0bSmIaHDnS1rwBXvaoFv7WfJHlg41CEhPK1aW/7PCHHAUkBtV2gcIF7M9ZPeBBNfcR1Xu8ICfrqhJo4ZTrSD9oAV9FEoiA1NiwDHkNNKzO0JvHZw5BzAIIfps5A57n17coX2py7rBTy0l9Nfd80QJV2E86VwPkdBNeJoaHUJv46oM3LvO8oK6sGzA4IregDbRtPKahEW9hS7Fy1k1JLHOeJp7pubFEgIz64iwaP+DIwdCGDPzjQEU+fLMYes6OEBtR68praGm1u8lKxucAPBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoHqMJPXw1yXsxxCikvXKe+mXuYh2U0/w3tdvzVy7XU=; b=VXD/wHprlEImQJScQUXbbOgrE0PY7rdI/QwEPZirqJXdj1ScnjjZn/qobE/UD4m2K2AsvJ+Nc6agrVOSDqIl4ii3Fte+r2MdONmRhBelDXI9xxnITNBrBPPDp/2r9FERGoRSFolRNPWjjNXaV21R2Cv7P5mj0vmMA2dYKdHF3NV3usFYcTQA+2VMz+VBBdiW5XbEnSMeysYngC6zzdazqvdHfRl/GKIcwwhoVFgrGddTmCLmEfEGgoJGcIqdAZv8VQp1daEWtEUY5xo33KqA9x+Nz6HWnXDNogzmYbWSHjKDwQBfghBmOgAUNoB2DYgMAipB3BwCXfEzcAqN+gxGJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=arm.com;dmarc=pass action=none header.from=arm.com;dkim=pass header.d=arm.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoHqMJPXw1yXsxxCikvXKe+mXuYh2U0/w3tdvzVy7XU=; b=VbvAT0Ol7yCnmFVylPScRjd9td9A8zhlWDVE1ndkCJ2sQXbBfgohQgl6jNk+JQ8Vaq8XmVRSeQMZ2VNdH3BDat+0B9bPwIjv3QgYtxhgOErFjQSaLaqCALmgjj4rVoeJkRJWOjvKRg1tbRYTNrA7joxEBTuxl4fXRgHGs5CijFA= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.244.88) by VI1PR08MB3502.eurprd08.prod.outlook.com (20.177.60.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 24 Jul 2019 17:44:06 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::e8f0:b69b:7f7a:c486]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::e8f0:b69b:7f7a:c486%3]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 17:44:06 +0000 From: Hannes Tschofenig To: "suit@ietf.org" Thread-Topic: Firmware Update Paper Thread-Index: AdVCMRfQE3vhkyfhQmmfI5GkmMK4PA== Date: Wed, 24 Jul 2019 17:44:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 810b8200-6fde-425c-9084-f508429fe444.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [31.133.155.5] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: ace93cc0-90b6-4a52-2889-08d7105e8a3f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VI1PR08MB3502; X-MS-TrafficTypeDiagnostic: VI1PR08MB3502:|AM6PR08MB4950: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:3826;OLM:3826; x-forefront-prvs: 0108A997B2 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(136003)(366004)(396003)(346002)(189003)(199004)(33656002)(81156014)(6916009)(966005)(71190400001)(71200400001)(86362001)(52536014)(478600001)(53936002)(5660300002)(102836004)(7696005)(186003)(6436002)(26005)(76116006)(6506007)(6116002)(790700001)(81166006)(5640700003)(3480700005)(2501003)(66476007)(66446008)(64756008)(3846002)(66556008)(66946007)(1730700003)(256004)(8936002)(2420400007)(2906002)(66066001)(316002)(25786009)(8676002)(7736002)(7110500001)(15650500001)(558084003)(9686003)(74316002)(606006)(7116003)(14454004)(486006)(99286004)(476003)(2351001)(236005)(6306002)(55016002)(68736007)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3502; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: n9zT6CK+9n+kA9cpZ8it2miTUFQnQrujq9tObvWtdgHctoozpVCFf2+Swj9DYRugFAhQbt+b5j3GP+4MDBG5XVTitz9xJRUUc7IKQOEfjn58tzYi/W9EqTEGXXuV1CUBnClAm8SBCxnfVVoJErH5ERXoT5skN5YTB6k1VNSttK/DH0w2rb/GI2dm5pxgb6gflNOnodKH+D/FdEzCcrvFqADue40BJMs8Pi1EUYWx2pICHW43mcD/5wEdHECra89HI6m+1ODwQ/WlzzOyla+qtEq6UcIlC71iqsEWPr/EcV9MRClt+7zR4nFWdZkuePrl3MOh3lraBdwJA2Q1c4vXMl+yBEXo7YQzLTEASZl56Vkl9oydsLYf2VW8MkIQ6vCEoBRHSrhbr/G76pt+zR1S13piotKgRVPexZZCtI6RSIA= Content-Type: multipart/alternative; boundary="_000_VI1PR08MB53600B1D1A194F49B67B90DFFAC60VI1PR08MB5360eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3502 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT011.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(396003)(2980300002)(189003)(199004)(40434004)(14444005)(52536014)(5024004)(2906002)(966005)(3846002)(6116002)(790700001)(16586007)(26826003)(478600001)(316002)(606006)(8936002)(1730700003)(81156014)(14454004)(74316002)(70206006)(7736002)(81166006)(70586007)(22756006)(99286004)(15650500001)(2351001)(2420400007)(486006)(8676002)(63350400001)(5660300002)(236005)(186003)(26005)(336012)(6306002)(5640700003)(9686003)(7696005)(6916009)(55016002)(7116003)(3480700005)(102836004)(54896002)(63370400001)(2501003)(126002)(476003)(61614004)(25786009)(33656002)(66066001)(86362001)(6506007)(76130400001)(356004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4950; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: cb53ef80-4b7e-4239-aeea-08d7105e8669 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(710020)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR08MB4950; X-Forefront-PRVS: 0108A997B2 X-Microsoft-Antispam-Message-Info: 9Yo7JB5aJXVQ3bxEtUBjOBqw4nQQ+rnXGYxq9+pWZf+qqezbnE/uJ4QUMHdSVAydNeB6kCZSxJKEgJOVjXBZg6gUbpeECLjgS6QN1l/ABm29CXDFL0MekoH/dIMb7Ns5Bul/ChqZ4KNlpEnv5Cun6eVKtwKRUdIxmF14GrYpt2+uvNB/ovqP8OGBC2E8SplVY/D+/2pNq6IFADpHLh+FaJYFtvdGEbsAWeXla9mWBGD1u/WmCWJAlqW/9yg05Wa1r49HqwYEHRhd+Bb3nOqmdp9IdqGnNAxa1zdavqngZrfiAzkuMChmnbTR+QxVi/sN5ppNuO0EXGRMYay9onC1rWYd7QDmR+Q1jRUD8lt1PF8d0owMVFwnKb6EnDxEI68yEeoaix6785Vno+X1hSIc/01PvEChsXRHwrtHs/1Uhkk= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2019 17:44:12.8049 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ace93cc0-90b6-4a52-2889-08d7105e8a3f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4950 Archived-At: Subject: [Suit] Firmware Update Paper X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:44:26 -0000 --_000_VI1PR08MB53600B1D1A194F49B67B90DFFAC60VI1PR08MB5360eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are some numbers (because the question came up today in the meeting). Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A= Reality Check" https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D8725488 IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB53600B1D1A194F49B67B90DFFAC60VI1PR08MB5360eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are some numbers (because the question came up = today in the meeting).

 

Secure Firmware Updates for Constrained IoT Devices = Using Open Standards: A Reality Check”

https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber= =3D8725488

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB53600B1D1A194F49B67B90DFFAC60VI1PR08MB5360eurp_-- From nobody Wed Jul 31 08:12:44 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601212006D; Wed, 31 Jul 2019 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYBwy8qiP7lP; Wed, 31 Jul 2019 08:12:34 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4B412004F; Wed, 31 Jul 2019 08:12:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 85570E2044; Wed, 31 Jul 2019 11:12:32 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24378-01; Wed, 31 Jul 2019 11:12:26 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 66969E2040; Wed, 31 Jul 2019 11:12:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1564585946; bh=GsOlVcbMjQpRtrpnT7KlkNLRq8lETed1zOmUf5cND0A=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=JUUc3yal8byLa38LSNRD4869qHimZ0g7+zk1IAn4jvy1qlePolXMNfWbHY8g+0w6r fjL7ubA4fvrBRIUdsopuEfBXZ4h+scGI9gLv+cAbAo99CXw5jsz5e5EihrXLgTKnWN YfYNQhq8bJoz8pDnywPu/KuhRcUmykuip6Shr8jY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x6VFCK40022565; Wed, 31 Jul 2019 11:12:20 -0400 From: Derek Atkins To: Michael Richardson Cc: cose@ietf.org, "suit\@ietf.org" References: <835.1562080969@localhost> Date: Wed, 31 Jul 2019 11:12:19 -0400 In-Reply-To: <835.1562080969@localhost> (Michael Richardson's message of "Tue, 02 Jul 2019 11:22:49 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Suit] [COSE] draft-atkins-suit-cose-walnutdsa X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 15:12:36 -0000 Michael, Again, sorry for the delay in responding. I've had a lot of $DAYJOB deadlines which have taken over and some things have fallen through the cracks. Too many balls in the air, so to speak. Comments are inline below.. Michael Richardson writes: > Derek, looking at the IANA Considerations of > draft-atkins-suit-cose-walnutdsa, it seems that you need a number in: > > 1) COSE Algorithms -- registry > 2) COSE Key Types -- registry > > and several in the > 3) COSE Key Type Parameters -- registry Correct. > https://www.iana.org/assignments/cose/cose.xhtml#algorithms > > For the first, you can have: > Integer values greater than 65535 Expert Review > > And the other two are Expert Review anyway, no specification required! > You are even listed as one of the experts for COSE Key Types :-) Yes, I know I am one of the experts for these registries. However, I feel I must recuse myself from approval of these. > {If my reading is correct, you can also use strings longer than 2-bytes > without registration with IANA, but that has an operational (maintaining > legacy code) and bytes-on-the-wire impact should you be allocated a shorter > code later on} Yes, which is another reason I'd rather get something right. > You could also ask for early allocation via the COSE WG, but that probably > requires the document to be adopted first! Does it? Or does the WG just need to approve of the document going through any of the publication processes? > That's what I would do: just ask for the values via Expert Review, and live > for now, with the a five-bye (encoded) COSE Algorithm code, if your market > need is urgent. Yes, I could just request the entries in the registry. However, I am trying to be a good netizen; I want to have a document that people can look at to understand what the registry items mean. > Derek Atkins wrote: > > We have customers who are looking to use this technology today, so we > > would like to do it in a standard way that others could understand. > > Personally, I'm fine with an Informational (instead of Standards-track) > > publication if that would make people happier. Even so, the RFC Editor > > would still require approval from this WG as it is within their (the > > WG's) area. > > yes, if you went ISE, which would still take awhile. I am fine going through the ISE, however I suspect that the IESG in their conflict review would then go and ask this WG about it. So I wanted to bring it up here, first. What is your definition of "awhile"? Thanks, > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 31 12:38:19 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC73E120077; Wed, 31 Jul 2019 12:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L70PDDT6tZB4; Wed, 31 Jul 2019 12:38:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD6112008D; Wed, 31 Jul 2019 12:38:07 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B1BD2380BE; Wed, 31 Jul 2019 15:37:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D7781205; Wed, 31 Jul 2019 15:38:05 -0400 (EDT) From: Michael Richardson To: Derek Atkins cc: "suit\@ietf.org" , cose@ietf.org In-Reply-To: References: <835.1562080969@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [Suit] [COSE] draft-atkins-suit-cose-walnutdsa X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 19:38:11 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Derek Atkins wrote: >> And the other two are Expert Review anyway, no specification require= d! >> You are even listed as one of the experts for COSE Key Types :-) > Yes, I know I am one of the experts for these registries. However, I > feel I must recuse myself from approval of these. Yes, obviously, but the point is that you will know how to ask nicely :-) >> You could also ask for early allocation via the COSE WG, but that >> probably requires the document to be adopted first! > Does it? Or does the WG just need to approve of the document going > through any of the publication processes? If the document isn't adopted, then I don't think the WG chairs can ask the AD to approve. I think that adoption is the only required step; your document could take awhile to progress. IANA will check back on progress f= or the early allocation, to make sure the document is still of interest. >> That's what I would do: just ask for the values via Expert Review, a= nd >> live for now, with the a five-bye (encoded) COSE Algorithm code, if >> your market need is urgent. > Yes, I could just request the entries in the registry. However, I am > trying to be a good netizen; I want to have a document that people can > look at to understand what the registry items mean. While you don't have to provide a specification for Expert Review, I think that if you *do* that it will get recorded. If you later on get a 1-byte code allocated then, it's code complexity, but it's not too terrible, I thi= nk. At some point, your constrained devices will only use the 1-byte code, and your non-constrained devices will continue to be tolerant of both. >> Derek Atkins wrote: > We have customers who are >> looking to use this technology today, so we > would like to do it in= a >> standard way that others could understand. > Personally, I'm fine >> with an Informational (instead of Standards-track) > publication if >> that would make people happier. Even so, the RFC Editor > would sti= ll >> require approval from this WG as it is within their (the > WG's) are= a. >>=20 >> yes, if you went ISE, which would still take awhile. > I am fine going through the ISE, however I suspect that the IESG in > their conflict review would then go and ask this WG about it. So I > wanted to bring it up here, first. What is your definition of > "awhile"? Given the conflict review and the typical length of the RFC editor Producti= on queue, I would say you are looking at a year before AUTH48, but the early allocation could occur much sooner. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1B7h0ACgkQgItw+93Q 3WW3tgf9FuNUNIdWx/IUWiCxn32wSF8aRELCxYKKepNvF3Gdcypd+JYxbeUtOIAP NfabCEKBpcY0DpUcYIGRwMDq2OQMQya8nZVpQBCcNFIIVUFTOqJXTR0C4+l/D4+q F3rnt5nqbkGUDh1ceV58ixItb+e1xEWyABO8xs/SIalKIGWFXfN/77Ol+Q5SoK5M wJhFE1CXl8DuW2Dvrbff/SzJ3rXqSDLJEDKHCf6atKoc4m4h6fD4REbYTKMReRhM 048piKfpw+vj1GIYEYh5wGKiXw8Pmid+NcT6DVIbNCe6jqxRxDvmcR21RSdqamVd 2QF1eRRp+2fKkMQttCNtF45k2FJvHw== =oBly -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 31 17:11:11 2019 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4311200FF; Wed, 31 Jul 2019 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOLNT8zxN2-A; Wed, 31 Jul 2019 17:11:08 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D69E2120043; Wed, 31 Jul 2019 17:11:07 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x710B3BF009876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 20:11:05 -0400 Date: Wed, 31 Jul 2019 19:11:02 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: Derek Atkins , "suit@ietf.org" , cose@ietf.org Message-ID: <20190801001102.GS1006@kduck.mit.edu> References: <835.1562080969@localhost> <28628.1564601885@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28628.1564601885@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Suit] [COSE] draft-atkins-suit-cose-walnutdsa X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 00:11:10 -0000 On Wed, Jul 31, 2019 at 03:38:05PM -0400, Michael Richardson wrote: > > Derek Atkins wrote: > >> And the other two are Expert Review anyway, no specification required! > >> You are even listed as one of the experts for COSE Key Types :-) > > > Yes, I know I am one of the experts for these registries. However, I > > feel I must recuse myself from approval of these. > > Yes, obviously, but the point is that you will know how to ask nicely :-) > > >> You could also ask for early allocation via the COSE WG, but that > >> probably requires the document to be adopted first! > > > Does it? Or does the WG just need to approve of the document going > > through any of the publication processes? > > If the document isn't adopted, then I don't think the WG chairs can ask the > AD to approve. I think that adoption is the only required step; your > document could take awhile to progress. IANA will check back on progress for I think so, too. > the early allocation, to make sure the document is still of interest. Yes, a one-year extension with just the chairs' approval and subsequent ones with the IESG's approval. > >> That's what I would do: just ask for the values via Expert Review, and > >> live for now, with the a five-bye (encoded) COSE Algorithm code, if > >> your market need is urgent. > > > Yes, I could just request the entries in the registry. However, I am > > trying to be a good netizen; I want to have a document that people can > > look at to understand what the registry items mean. > > While you don't have to provide a specification for Expert Review, I think > that if you *do* that it will get recorded. If you later on get a 1-byte I think so, too. > code allocated then, it's code complexity, but it's not too terrible, I think. > At some point, your constrained devices will only use the 1-byte code, > and your non-constrained devices will continue to be tolerant of both. > > >> Derek Atkins wrote: > We have customers who are > >> looking to use this technology today, so we > would like to do it in a > >> standard way that others could understand. > Personally, I'm fine > >> with an Informational (instead of Standards-track) > publication if > >> that would make people happier. Even so, the RFC Editor > would still > >> require approval from this WG as it is within their (the > WG's) area. > >> > >> yes, if you went ISE, which would still take awhile. > > > I am fine going through the ISE, however I suspect that the IESG in > > their conflict review would then go and ask this WG about it. So I My understanding is that Adrian will be asking that even before the document gets far enough to need an IESG conflict review. > > wanted to bring it up here, first. What is your definition of > > "awhile"? > > Given the conflict review and the typical length of the RFC editor Production > queue, I would say you are looking at a year before AUTH48, but the early > allocation could occur much sooner. Adrian has been pressing the IESG to adhere better to the 4-week timeline for conflict review responses (modulo IETF meetings, etc.), but given the xmlv3 cutover and C238 breaking loose, it does seem reasonable to expect things to get backed up a bit. -Ben