Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG

Kent Watsen <> Wed, 11 September 2019 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832CE1201CE; Wed, 11 Sep 2019 13:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Widleb_DkGZC; Wed, 11 Sep 2019 13:30:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C9D7120227; Wed, 11 Sep 2019 13:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1568233818; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7u2eWyazOweOCfOYUgpmJoHsbzizX/KNYrth4oMcGTE=; b=j7VKl+l6ipinxvLViFoPc4KYeVfXGeK2pPkF7SVKm9dW3Pg9x/z3Z0C6bWWPL51h fyurw24LOsoVvOu2Qid2txIcvK4x3F/G4FEXN+E/qUljwJU+eMm4hZrmM7vOm6THKHD 1O/US1ZvaHAMK6BOv7kN5MmKLJ3/oRNnEX3Vhh18=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FB7F2BD-5215-4745-AD0F-445272E481C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 11 Sep 2019 20:30:18 +0000
In-Reply-To: <>
Cc: Michael Richardson <>, "" <>, "" <>
To: Mohit Sethi M <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.11-
Archived-At: <>
Subject: Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
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 20:30:22 -0000

Hi Mohit,

> Could you explain the high-level differences between BRSKI and SZTP for those like me who are not extremely familiar. 
> I know there are probably many differences. For example, I see that the SZTP spec says that devices can receive initial bootstrap information over DNS or from a bootstrap server. 
> What I am trying to understand is what does a device start from (shared-secret/ephemeral key pair/manufacturer certificate), and what does it end with? Do we need both SZTP and BRSKI?
Top of mind.

- SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMMENDED), alternate credentials possible.  Optional list of TA certs for validating SZTP servers.  Optional list of TA certs for validating vouchers.
- BRSKI: IDevID MUST.  List of TA certs for validating vouchers MUST.

Normal Operations:
- SZTP: many modes here, some doesn't require networking.  Vouchers only needed when TLS can't be used or trusted.   Vouchers, when used, are primarily long-lived, but MAY be ephemeral (e.g., nonced).  Primarily with strong ownership verification, but weaker forms are possible.
- BRSKI: singular mode (pledge looks for a Registrar).  Vouchers are always used and are primarily conceived to be ephemeral (nonced) with a MASA that maintains a log; long-lived Vouchers and strong ownership-verification are possible.

- SZTP: a "payload" that could be as small as a script or as large as instructions for updating the OS image + setting an initial configuration.
- BRSKI: a domain certificate.  Additional mechanisms needed to get device into a managed state (this is what some of the other ANIMA drafts are for)

I think I got the BRSKI parts right, but hope folks will chime in if anything is misrepresented or underrepresented.