Re: [Iot-onboarding] EST CACerts and Pinned Domain Certificate
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 23 March 2020 19:25 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 CE4703A0CCC;
Mon, 23 Mar 2020 12:25:34 -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 Re4hZc1re-kc; Mon, 23 Mar 2020 12:25:27 -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 7AF2A3A09A3;
Mon, 23 Mar 2020 12:25:26 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247])
by tuna.sandelman.ca (Postfix) with ESMTP id 0438A38982;
Mon, 23 Mar 2020 15:24:01 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1])
by sandelman.ca (Postfix) with ESMTP id B746016D;
Mon, 23 Mar 2020 15:25:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>, iot-onboarding@ietf.org
CC: anima@ietf.org
In-Reply-To: <CAHiu4JO93swur42mT7rjhGTouVhefjjXftHJi=4Bnpk=t_aV-Q@mail.gmail.com>
References: <CAHiu4JO93swur42mT7rjhGTouVhefjjXftHJi=4Bnpk=t_aV-Q@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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: Mon, 23 Mar 2020 15:25:23 -0400
Message-ID: <30498.1584991523@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/9vTLiPFfGLQuinK01Z_xZn7IRqc>
Subject: Re: [Iot-onboarding] EST CACerts and Pinned Domain Certificate
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: Mon, 23 Mar 2020 19:25:35 -0000
M. Ranganathan <mranga@gmail.com> wrote: > Consider an integrated BRSKI-EST server. The pledge bootstraps and gets the > pinned domain certificate. Then the pledge queries EST for the ca-certs. Is > it correct to require that the pinned domain cert must be present in the > CACerts collection returned by the EST server when the pledge does a > cacerts query (but can include additional certificates) ? No, I don't think that the specific cert needs to be in the cacert set. 1) It makes sense that a trust anchor(s) returned ought to validate the pinned domain cert. This is because a certificate renewal operation needs to connect to the EST server correctly. Obviously, in a very degenerate case, there is only the one owner certificate, and it is used for everything. section 3.3 of draft-richardson-anima-registrar-considerations suggests that, and I include the text at the bottom. 2) The pinned-domain cert is validated by the pledge using the voucher. It does not need to be validatable via the cacerts for BRSKI-EST to work, provided that the TLS connection is never broken. (If the TLS connection is broken, then the enrollment should restart. We considered many ways around this, but I think in the end, we decided not to do this. HTTP/1.1+ persistent connections or die) === 3.3. Home Network Home networks and small offices that use residential class equipment are the most challenging situation. The three-tier PKI architecture is not justified because the ability to keep the root CA offline has no operational value. The home network registrar should be initialized with a single key pair used as the certificate authority. Secret splitting is useful in order to save the generated key with a few neighbours. It is recommended that the entire PKI system database (including CA private key) be encrypted with a symmetric key and the results made available regularly for download to a variety of devices. The symmetric key is split among the neighbours. The most difficult part of the Home Network PKI and Registrar is where to locate it. Generally it should be located on a device that is fully owned by the home user. This is sometimes the Home Router, but in a lot of situations the Home Router is the ISP's CPE router. If the home has a Network Attached Storage (NAS) system, then running it there is probably better. A compromise for CPE devices owned by the ISP that can run containers is for the Registrar to be located on detachable storage that is inserted into the CPE. The detachable storage is owned by the home owner, and can be removed from the CPE device if it is replaced. More experience will be necessary in order to determine if this is a workable solution. -- Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Iot-onboarding] EST CACerts and Pinned Domain Ce… M. Ranganathan
- Re: [Iot-onboarding] EST CACerts and Pinned Domai… Eliot Lear
- Re: [Iot-onboarding] EST CACerts and Pinned Domai… Michael Richardson
- Re: [Iot-onboarding] [Anima] EST CACerts and Pinn… Esko Dijk
- Re: [Iot-onboarding] [Anima] EST CACerts and Pinn… Eliot Lear
- Re: [Iot-onboarding] [Anima] EST CACerts and Pinn… Esko Dijk