Re: [Iot-onboarding] what can pinned-domain-cert actually pin?

"Owen Friel (ofriel)" <ofriel@cisco.com> Wed, 28 August 2019 09:08 UTC

Return-Path: <ofriel@cisco.com>
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 A4762120033 for <iot-onboarding@ietfa.amsl.com>; Wed, 28 Aug 2019 02:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=X3ma9Kjp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=X09NIc8F
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 2PvUo_u3wtX1 for <iot-onboarding@ietfa.amsl.com>; Wed, 28 Aug 2019 02:08:26 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E69120018 for <iot-onboarding@ietf.org>; Wed, 28 Aug 2019 02:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9385; q=dns/txt; s=iport; t=1566983306; x=1568192906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yH7T9X1T6GYRuiOkkqq9EV5wZaV7wxvr+gSgnlQ2/x4=; b=X3ma9KjpFhOHjf4/O4eDF1nm2jN/1hBBm9Z/42hdWTTYjjjVuMoiGh+Q Di5B5YhXvxZokHXpRXpXJeITjbUzqpyaBb62zcqeSp9Jt/GK3erS2ER0m DpAfAoddYA3MwfJasxBE/aKh3sQXJx/XwhCfo75hKv8VolWW9d3aB5QS0 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AAlVz9xAp9hwLY8g57aklUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwCABIRGZd/4sNJK1dCRwBAQEEAQE?= =?us-ascii?q?HBAEBgWeBRVADbVYgBAsqh2gDinQagkKVBYJkglIDVAkBAQEMAQEYCwoCAQG?= =?us-ascii?q?BS4J0AoJMIzgTAgoBAQQBAQECAQYEbYUuDIVKAQEBAgEBAQEQLgEBDBkHCwE?= =?us-ascii?q?LBAIBCBEDAQEBAQwbBycKARQJCAIEAQ0FCAwHAgQBgwE0gTYDDg8BDp9rAoE?= =?us-ascii?q?4iGGCJYJ7AQEFgTNRA4MBGIIWAwaBNIVhhXgeGIFAP4ERRoJMPoF5aAEBAYE?= =?us-ascii?q?2AwEEDBiDO4ImjHOHZV2WQgkCgh6FWoERjXyCMpYlijODOYE2hjmQPQIEAgQ?= =?us-ascii?q?FAg4BAQWBZyGBWHAVGiGCbIJCCwEXg0+FFIU/cgEBDwKBFoszAQENFweCJQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.64,440,1559520000"; d="scan'208";a="315262996"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Aug 2019 09:08:25 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x7S98OOZ013912 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Aug 2019 09:08:25 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 04:08:24 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 05:08:23 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 28 Aug 2019 04:08:23 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HkdasFgW1lnnzVXrRpGm7lS+uoQhYrVua24hrXKr34xbLVoHqc/rBx1x6/Nj/jpgWO8Re+nw+0yHr2XfaR0GPra5VO72BEVdawg5Fe0MwmQmfHuB1xPWlbaEoMHg13wlyT/2fZ1cLFd40Vp3VznOo1flDyEdZ7+ieWwgru/YJgOSKSaE1XXRUJt32VasZe6hb2BwRmXXeqkURXm6bVaSy2Ss6/EitH4+5MqrB7jtAhoKOzs5k8hnd1rJ6QVhPbGSFRmJE3PC038gx45E1AiZAJ3e1t57eWCvu2Ea+36VGdUycChUmcAQ9UfYiVhvs0BYScWMOgDujn+Em/YxV+mBHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yH7T9X1T6GYRuiOkkqq9EV5wZaV7wxvr+gSgnlQ2/x4=; b=hx0i0RCmvqB/9uom7xm+UfLaFJvm7Sam83CEeup4x4k4DWwA0n6eOnsRsK2eDNHqu38GkIzwacdwt04ELiSP9tJVwtxMewDZyaAo9Q+x+jOgbuDjdXk1InYHKj6UC8yzJSUTH9rOVEKwP2w5z8sGhV8hwRgnowW4U/fdQqa5YqMGX9aXcppxqIrhOL7FduthidHoJTyTIuPN2BXYmbVNT8x+/L/Tl86gZMHLGJiFjOKBs59S4Il8ZylwmxMc01uR/7T5woOBoffcSR6bLT2XvU6Zb3008/2mw6uVbDiCFiQPpuOelMQ0v+OAyWQvukUNXfGRMfYW9NErLMcNnS4VSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yH7T9X1T6GYRuiOkkqq9EV5wZaV7wxvr+gSgnlQ2/x4=; b=X09NIc8Fv5eLv5zC4el5AN8a7U42j8O1FwKTlZsl68+MNxfbu6J5inW2ZKenUgkh4DsBlgDEv2mroiIaqTfFTQjeVTySQpmPyrLsDpyA7fKlrd8HAyiqVQYv9grt+5fNu6pMluoTqmzcLX4rTax+uCi5CMbB5ZttmJI4SBk4kOI=
Received: from CY4PR1101MB2278.namprd11.prod.outlook.com (10.172.76.13) by CY4PR1101MB2167.namprd11.prod.outlook.com (10.172.77.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16; Wed, 28 Aug 2019 09:08:22 +0000
Received: from CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::9098:374:9205:d0c4]) by CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::9098:374:9205:d0c4%5]) with mapi id 15.20.2199.021; Wed, 28 Aug 2019 09:08:22 +0000
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
Thread-Topic: [Iot-onboarding] what can pinned-domain-cert actually pin?
Thread-Index: AQHVXPTdRdfIG1V6k0+L04J9EcMpEqcPVJEAgADrXPA=
Date: Wed, 28 Aug 2019 09:08:21 +0000
Message-ID: <CY4PR1101MB22782817AA5A55C3812A3EEFDBA30@CY4PR1101MB2278.namprd11.prod.outlook.com>
References: <2693.1566923418@localhost> <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@email.amazonses.com>
In-Reply-To: <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com;
x-originating-ip: [2001:420:4041:1250:997c:8517:b410:fbfc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c74b77ad-2356-4fe1-cb46-08d72b9746be
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR1101MB2167;
x-ms-traffictypediagnostic: CY4PR1101MB2167:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <CY4PR1101MB21678F547DF3E5680CEDF385DBA30@CY4PR1101MB2167.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 014304E855
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(396003)(376002)(39860400002)(366004)(51444003)(13464003)(199004)(189003)(478600001)(76176011)(186003)(6306002)(305945005)(2906002)(6436002)(99286004)(55016002)(966005)(74316002)(316002)(4326008)(102836004)(25786009)(8936002)(76116006)(6506007)(53546011)(71200400001)(71190400001)(66574012)(229853002)(14454004)(110136005)(6116002)(53936002)(8676002)(86362001)(46003)(81166006)(81156014)(5660300002)(256004)(33656002)(7696005)(9686003)(14444005)(66556008)(11346002)(64756008)(66446008)(66476007)(66946007)(446003)(476003)(52536014)(6246003)(486006)(7736002)(24704002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2167; H:CY4PR1101MB2278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: HP26NkISAf9MAevc+egCgSM5LUwm0udvPTQ8nJnItQOyTnMMNIlEiEZb0BeMNqYG/G0ZCcj2W8yGNq8hpHx61iRbcOX0jPEyMPkt/Oq6qmU1E5tmpVP8Zsk6ejRrFCKyqyhUTDGphfM0TrxH1/ozpLgCuUWgJ6W8XP9O4RSIJeX1mM0KXu046iW4iYjN1Ql+csgnJU39WF2Z2njwu82RYkybqlm2hnRntfxyDh9KuN35ivjwDpMU0uM6/dp4FXB1kjfL7nMx4+VkBlkiHT6iQD1/YH6MkjiWcfBaQmhJmLaE9KfREoI1xqwVxiQn/QyoQu/Cm4QXkWO9cmyn4vUzDrqs/vsLQydFgOgSz+IvtjxgAvwXKdnAlP5BVP3dSt50v0CZxW+FlmTKQOQg8T5BMN8iYUv789Hu9O/WaTIquOI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c74b77ad-2356-4fe1-cb46-08d72b9746be
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 09:08:22.1370 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: maqyPrz2AezAzHIkFo5AGa7mdRw5N9sy8Af5+dZTDXIgobojuoeJyde+mapLyHRQR2g4lM7k9mxIusG1EBw1Mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2167
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/6cZAfd1zOzcP96fnUY7O7HTvanc>
Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
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: Wed, 28 Aug 2019 09:08:29 -0000


> -----Original Message-----
> From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf Of Kent
> Watsen
> Sent: 27 August 2019 19:43
> To: Michael Richardson <mcr+ietf@sandelman.ca>
> Cc: iot-onboarding@ietf.org
> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
> 
> 
> In SZTP, pinned-domain-cert is the long-lived TA to a potentially short-lived
> "Owner Certificate".  In theory, the root of the pinned-domain-cert PKI could
> be a public CA but, in practice (because public CAs don't issue long-lived
> certs), it means that a private PKI needs to be used.  Due to the nature of
> these PKIs NOT being used to secure TLS-based services, the need for
> a public root TA isn't there, so no big deal.

What do you mean by long-lived? Public CAs can issue EE certs with expiration times up to 825 days as per https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf. When thinking about pinned nonceless vouchers for thing onboarding, that's still pretty long. If pinning the EE cert, then the voucher is valid until the EE cert expires (assuming of course that the non-bootstrapped thing has an accurate trusted view of time). If the public CA root is pinned, then that 825 day limit doesn't matter as the public CA root will be long lived. E.g. Lets Encrypt ISRG Root X1 root expires in 2035, but if pinning that then we have the DNS-ID issue.

With the advent of Lets Encrypt, and cheap GoDaddy certs, we can expect more operators to use public CAs for everything, including AAA and RA identity certs. Operators already deploy public CA certs on AAAs for guest access and public hotspots.

I really don't understand the statement that "it means that a private PKI needs to be used". I think that the current RFC8366 Voucher format forces a private CAs to be used for practical operational reasons, but there is no reason outside of that why an operator MUST use a private CA for their AAA, RA and/or bootstrap server identity.

> 
> The "private CA roll-over" scenario you mention is side-stepped by enabling
> the Owner Certificate to itself be a partial chain (i.e., total-chain = partial-
> root-chain + partial-owner-cert-chain), hence the partial-root-chain part can
> be protected by some offline HSM while signing (e.g., annually) some
> middle-level CAs that are used to sign the actual Owner Cert EE cert.

That still doesn't address the admittedly infrequent root CA change. E.g. if an operator wants to change the offline HSM from an RSA to an EC signature cert.

And if an operator wants to use a public CA, having multiple pinned-domain-cert entries allows an operator to change public CA providers (e.g. from LetsEncrypt to GoDaddy or vice-versa) without killing all existing nonceless vouchers.

Extending the Voucher to allow (i) multiple pinned-domain-cert entries which are independent roots, not just a root and a chain of intermediates and (ii) optionally specify a DNS-ID(s) seems like it gives operators the flexibility of making a public vs. private CA provider choice.

> 
> Separately in SZTP, there is the notion the device dynamically (during
> bootstrap) receiving the TA for a bootstrap server it it being redirected to.  In
> this case, the bootstrap servers are presenting a TLS-based service
> (specifically, HTTPS), and so EE certs MAY have a public root TA.  It was
> discussed at one point that the TA cert may expire and thus wouldn't it be
> better to enable the TA to be expressed as a 2-tuple [ <long-lived TA cert
> (MAY be a public CA)>, <name of some 'subject' matter in the TA-issued CA
> cert>].  But this became complicated and, instead, we opted for introducing
> alerts/alarms for when certificates are nearing expiration.
> 
> Part of what made it complicated is that one can imagine an organization
> obtaining a single top-level organization-wide commercial CA certificate that
> it uses for a variety of reasons, only one of which is to sign vouchers.  Thus, in
> such cases, the 2-tuple becomes a 3-tuple (and perhaps even an N-tuple),
> e.g.:  [ <long-lived TA cert (MAY be a public CA)>, <name of some 'subject'
> matter in the TA-issued CA cert>, <name of some 'subject' matter in the
> voucher-issuer's cert>].

CA/Browser Forum does not allow public CAs to issue intermediate CAs to anyone. If you do that, your root CA will be blacklisted by the industry. So I don't think that's a real world problem.

> 
> Related, though not exactly, I regret that RFC 8366 states that the pinned-
> domain-cert value is a single X.509 cert, as opposed to a potential chain of
> certs.  One reason is so as to simplify support for path-validations, as not all
> libraries support partial-chain validation.
> 
> Kent
> 
> 
> 
> On Aug 27, 2019, at 12:30 PM, Michael Richardson
> <mailto:mcr+ietf@sandelman.ca> wrote:
> 
> 
> There has been some private conversation about what kinds of things an
> RFC8366 voucher can pin.  The discussion was about the utility of pinning an
> EE certificate that comes from LetsEncrypt (LE), or some commercial CA such
> as Verisign or Goddy, etc.
> 
> This was also in the context of a long-lived nonceless voucher.
> Pinning the CA of a 90-day LE EE voucher is meaningless without also
> including a DNS-ID.  My take on this is that this is a new kind of voucher, as it
> requires significantly more logic in the pledge to evaluate things.
> 
> It has come up that even with a private CA, that there is a problem if the
> private CA is pinned, and the CA rolls over.  In particular, even for vouchers
> with validities of more than a few days, if the private CA should roll over
> during that period, there is a problem.
> 
> RFC8649 seems to offer an additional way out for this.
> I doubt that CAs will let one include this extension, but if they did it might
> also help with the above problem.
> 
> 
> From: mailto:rfc-editor@rfc-editor.org
> Subject: RFC 8649 on Hash Of Root Key Certificate Extension
> Date: August 26, 2019 at 3:04:40 PM EDT
> To: mailto:ietf-announce@ietf.org, mailto:rfc-dist@rfc-editor.org
> Cc: mailto:spasm@ietf.org, mailto:drafts-update-ref@iana.org, mailto:rfc-
> editor@rfc-editor.org
> Reply-To: mailto:ietf@ietf.org
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 8649
> 
>        Title:      Hash Of Root Key Certificate Extension
>        Author:     R. Housley
>        Status:     Informational
>        Stream:     IETF
>        Date:       August 2019
>        Mailbox:    mailto:housley@vigilsec.com
>        Pages:      10
>        Characters: 22410
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt
> 
>        URL:        https://www.rfc-editor.org/info/rfc8649
> 
>        DOI:        10.17487/RFC8649
> 
> This document specifies the Hash Of Root Key certificate extension.
> This certificate extension is carried in the self-signed certificate for a trust
> anchor, which is often called a Root Certification Authority (CA)
> certificate.  This certificate extension unambiguously identifies the next
> public key that will be used at some point in the future as the next Root CA
> certificate, eventually replacing the current one.
> 
> This document is a product of the Limited Additional Mechanisms for PKIX
> and SMIME Working Group of the IETF.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet
> community.
> It does not specify an Internet standard of any kind. Distribution of this
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search For
> downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the author of
> the RFC in question, or to mailto:rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for unlimited
> distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> mailto:IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> 
> 
> --
> Michael Richardson <mailto:mcr+IETF@sandelman.ca>, Sandelman Software
> Works -= IPv6 IoT consulting =-
> 
> 
> 
> --
> Iot-onboarding mailing list
> mailto:Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding