Re: [Iot-onboarding] FW: New Version Notification for draft-friel-anima-brski-cloud-00.txt

Michael Richardson <> Wed, 11 September 2019 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D6C01209BF for <>; Wed, 11 Sep 2019 08:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ejx3ol-D4-W for <>; Wed, 11 Sep 2019 08:32:20 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE7341209C6 for <>; Wed, 11 Sep 2019 08:32:19 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 296431F459; Wed, 11 Sep 2019 15:32:17 +0000 (UTC)
Received: by (Postfix, from userid 179) id DE9F648C6; Wed, 11 Sep 2019 16:32:54 +0100 (WEST)
From: Michael Richardson <>
To: "Owen Friel \(ofriel\)" <>
cc: "iot-onboarding\" <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to "Owen Friel (ofriel)" <> message dated "Tue, 10 Sep 2019 20:09:05 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 11 Sep 2019 16:32:54 +0100
Message-ID: <>
Archived-At: <>
Subject: Re: [Iot-onboarding] FW: New Version Notification for draft-friel-anima-brski-cloud-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2019 15:32:23 -0000

Owen Friel (ofriel) <> wrote:
    > FYI, as discussed earlier on the thread, published first cut of the default BRSKI cloud registrar draft.

Thanks for starting this document.  I will send pull requests once I know
where you put it...

I think that there are a few high-level things that need to be clearer.
0) Why isn't is RFC8572 (SZTP) needs to be clearer.

1) what does it mean to onboard to the cloud only.  While it is nice for the
   IETF to make a standard for a manufacturer to interoperate with itself,
   we should recognize that we don't need to.  This is basically how every
   single home-IoT device that calls home works today.

2) we should clarify some reasons why the device can not find the local
   registrar.  One reason is that it's not local. I.e. a device being
   bootstrapped at some other location.

3) the device already has network connectivity.  Probably from a wire!!!
   (maybe from an open WiFi though)
   It's not core enterprise/ISP routing/switching equipment.

4) there is probably a significant difference between a 301 redirect before
   the voucher request and one that occurs after a voucher is issued.
   A redirect before request would be based upon the TLS Client Certificate
   A redirect that occured during the voucher-request would be curious, and
   I'm not sure what purpose it would serve, so I want to ignore this.
   A redirect in the form a voucher, is a different thing, pointing the
   pledge to an EST server with which to continue.
   In fact, I would suggest that these are two MAJOR different modes, and
   might even be different documents/protocols.  The argument for not being
   separate is that it might be on a per-device basis that it makes the

5) I think that this mechanism can never work without some amount of
   supply-chain integration, otherwise the cloud MASA has no idea who the
   correct customer is.  This is also implies that it doesn't work for the
   various "HomeDepot" retail situations.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [