Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI

Michael Richardson <> Mon, 12 August 2019 06:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C811120975; Sun, 11 Aug 2019 23:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Avlp6hzzxapk; Sun, 11 Aug 2019 23:09:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3A361208D4; Sun, 11 Aug 2019 09:49:21 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by (Postfix) with ESMTP id CCF56380BE; Sun, 11 Aug 2019 12:48:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id A5491A51; Sun, 11 Aug 2019 12:49:19 -0400 (EDT)
From: Michael Richardson <>
To: "Randy Armstrong (OPC)" <>
cc: "" <>, "" <>
In-Reply-To: <>
References: <> <> <> <> <11781.1565189957@localhost> <> <> <4671.1565279232@localhost> <> <> <19592.1565471757@localhost> <> <15583.1565485709@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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 11 Aug 2019 12:49:19 -0400
Message-ID: <7075.1565542159@localhost>
Archived-At: <>
Subject: Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Aug 2019 06:10:19 -0000

Randy Armstrong (OPC) <> wrote:
    > 1) As it stands today BRSKI is pull model only and the push model is
    > out of scope but I don't see why that has to be the case once you allow
    > for different protocols between the Device and the Registrar. With our
    > proposed OPC mapping we would define a Registrar that supports both
    > models. Is this of any interest to the IETF or would it be an OPC only
    > thing?

There are a number of reasons to think a push model is also workable.
I'm unclear if OPC needs to onboard devices into a wireless network or if
everything is wired.  This matters because the new device has to announce
its presence to the Registrar for push to work.

For instance, you could take a look at:

which is an old version of the constrained-BRSKI mechanism.
Section 3, (3.2) explains how the Registrar would reach out to the
Pledge using the 6tisch 6p protocol (when it ran over IPv6).

    > 2) Perhaps the most value from BRSKI comes not from the MASA per se but
    > the voucher format (i.e. a digitally signed document with a standard
    > format). We could meet a lot of our requirements if we had a voucher
    > which has a list of nonce-less or bearer vouchers shipped to a
    > particular location for use by a particular end user. We could create
    > workflows where the manufacturer/distributor has to create this
    > document when devices are delivered. The document could be delivered
    > via the MASA or via some other B2B exchange or even on a USB
    > stick. However it is delivered it can then be read by the Registrar and
    > use it to build a whitelist of Devices allowed on the network.

RFC 8572 -- Secure Zero Touch Provisioning (SZTP)
may suit you better. It also uses RFC8366 vouchers.

    > I am also thinking that this voucher would be a good application for
    > block chain where instead of a bearer voucher we define a mechanism
    > where the owner the device could append a "block" to the original
    > voucher which authorizes the transfer to new owner.

We considered distributed ledgers for the audit log.
In all distributed ledgers, you have to ask:
  1) are there mutually distrusting parties?
  2) what do they need to agree upon?
  3) what is the incentive for a third party to validate the chain?

What you have described above, however, is just a certificate chain.
No Block Required.

Describes an early notion of how vouchers work, and notice how it delegates
at each step.  Subsequent sales just extend the chain.  We didn't go this
way because:
  1) it mandates sales channel integration, and we think that this will be
     rare at the beginning.
  2) any party in the chain can issue a new sale certificate, effectively
     stealing the device from the current owner.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-