IETF Logo Mail Archive

Re: [Iot-onboarding] OPC and BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 08 August 2019 15:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D9120225 for <iot-onboarding@ietfa.amsl.com>; Thu, 8 Aug 2019 08:53:26 -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 Jbk1PzzaCsiB for <iot-onboarding@ietfa.amsl.com>; Thu, 8 Aug 2019 08:53:24 -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 545D2120224 for <iot-onboarding@ietf.org>; Thu, 8 Aug 2019 08:53:24 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 880E33818F; Thu, 8 Aug 2019 11:52:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C6D9CCC; Thu, 8 Aug 2019 11:53:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
In-Reply-To: <BYAPR08MB49034BA15C283F5248B42017FAD70@BYAPR08MB4903.namprd08.prod.outlook.com>
References: <BYAPR08MB4903F02A37ED9AE092A59B8EFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <BYAPR08MB49037C509717B409DE7B570BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> <BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <BYAPR08MB4903E91A2E9FC117755443C1FAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <F5504CAE-85B7-43AF-B743-1E234A4B320E@cisco.com> <BYAPR08MB4903C95973435BA06FC3C080FAD40@BYAPR08MB4903.namprd08.prod.outlook.com> <B5B28896-C211-41BF-AB51-0C6FDC72E44F@cisco.com> <0100016c6d9b4c92-77a6c841-c195-4323-b467-169c4bfabdee-000000@email.amazonses.com> <70a91551-dc40-966b-0f3d-f12fc41d58b7@lounge.org> <BYAPR08MB49034BA15C283F5248B42017FAD70@BYAPR08MB4903.namprd08.prod.outlook.com>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 08 Aug 2019 11:53:22 -0400
Message-ID: <6094.1565279602@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/GUvK1saVGjJXmNirNZ2gScgYYH0>
Subject: Re: [Iot-onboarding] OPC and BRSKI
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 15:53:27 -0000

Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:
    dan> I'm not sure how relevant this is to OPC (I have not found the
    dan> relevant documents
    dan> the OPC website) but I just want to point out that voucher-less
    dan> provisioning does
    dan> not have to rely solely on blind trust or TOFU.

    > What we are looking for from the MASA is a framework that will provide
    > the Operator with a "whitelist" of Device Certificates before any
    > Device is plugged into the Network.

We refer to this list as being part of "Sales Channel Integration".

If the manufacturer knows who it sold each device to, then it can provide
vouchers only to those owners; the operator does not need to know.

The alternative is that the manufacturer communicates the identity (serial
number) of each device to the operator as part of an electronic sales
invoice.  How this occurs is not in scope for BRSKI (I hope that OASIS or
some other entity has a protocol), but it means that the operator can know
which device belongs prior talking to the MASA.

    > The OPC UA enabled Registrar would know what Devices are allowed when
    > they attempt to register.
    > (IOW - the registrar does not simply rely on the Manufacturer CA).

I'm not sure there is a lot of difference in trust between receiving a list
(upfront) from the manufacturer as part of the sales invoice, and receiving
the list incrementally in the form of vouchers.  They are different
processes, and there are different opportunities for humans to confirm.
Clearly if the list is on paper, then a human has to enter the list, and
this is something I think we should aim to avoid as it is error prone.

--
]               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    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email