[lamps] kinds of trust relationships in IoT networks (was Re: rollover of CA)

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 September 2021 18:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CFD3A27CE; Fri, 3 Sep 2021 11:25:12 -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, 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 gCOjP4pqnupF; Fri, 3 Sep 2021 11:25:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E033A27CD; Fri, 3 Sep 2021 11:25:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9325C39590; Fri, 3 Sep 2021 14:31:10 -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 fkD2JsjjV2Ik; Fri, 3 Sep 2021 14:31:05 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 42D6C3958E; Fri, 3 Sep 2021 14:31:05 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9D3FEAC; Fri, 3 Sep 2021 14:24:58 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@lear.ch>, SPASM <spasm@ietf.org>, anima@ietf.org, iotops@ietf.org
In-Reply-To: <f49eb436-f3ca-053b-9874-9057420f8cb6@lear.ch>
References: <17240.1630591789@localhost> <CAErg=HH9o8wXgo9RS0GDrn6ZgL7TD3TF25PiUNW7XePML7252w@mail.gmail.com> <CAGgd1Odk-xVmYb8-i-1pCv-n=oeFCnjt-xsCC9mqvGowaLpeZg@mail.gmail.com> <SJ0PR22MB25424D58B3069358F1984B3EE8CF9@SJ0PR22MB2542.namprd22.prod.outlook.com> <SA1PR03MB662685DCB0CDF5BCACBDCEBEEECF9@SA1PR03MB6626.namprd03.prod.outlook.com> <f49eb436-f3ca-053b-9874-9057420f8cb6@lear.ch>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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
reply-to: iotops@ietf.org
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 03 Sep 2021 14:24:58 -0400
Message-ID: <23338.1630693498@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/taI30gyLrZT5rZoaXHJV2ckzLvQ>
Subject: [lamps] kinds of trust relationships in IoT networks (was Re: rollover of CA)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 18:25:14 -0000

Eliot Lear <lear@lear.ch> wrote:
    > I think the issue is that RFC 7030 references RFC 4210.  And
    > enterprises may indeed roll their CAs for a myriad of reasons, not the
    > least of which could be mergers, mishandled private keys, and planned
    > changes,.  So some advice may be needed here, if 4210 isn't the right
    > answer.

It's not that RFC4210 is wrong, it's that it's a bit abstract.

In IoT deployments, there are many slightly different aspects of how things
will be used that affects how one makes it unclear how to concretely do
RFC4210.

These differences are perhaps worth writing down somewhere.

I think that one major category is outbound P2MP (IoT node -> cloud).
A second one is "inbound" P2MP CollectionSystem->Node (often not cloud).
The third one, which many IETF efforts assume, but industry does not commonly
do, is node<-->node.
A fourth one might be where two nodes connect to a cloud/server resource, and
are then put in touch with other using credentials provided by the server,
or perhaps even just keyed by the server.  Most forms of secure multicast are
basically like this.

It's quite likely that some networks do a combination of these for different
purposes.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide