Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 July 2020 23:31 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2F3A0805; Tue, 21 Jul 2020 16:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ4iYh3n1pnc; Tue, 21 Jul 2020 16:31:44 -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 C8A2D3A0802; Tue, 21 Jul 2020 16:31:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C691E38A26; Tue, 21 Jul 2020 19:11:16 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bD7QivpLNRCA; Tue, 21 Jul 2020 19:11:15 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BF4F38A20; Tue, 21 Jul 2020 19:11:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9F63A8; Tue, 21 Jul 2020 19:31:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tomas Gustavsson <tomas.gustavsson@primekey.com>, secdispatch@ietf.org, spasm@ietf.org
In-Reply-To: <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com>
References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <f7cdd360-7ab7-28f6-86b9-9f8c4ae04aaf@primekey.com> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 19:31:40 -0400
Message-ID: <22303.1595374300@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/qHAF9PDV23kWH_penXSvmWSusSM>
Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 23:31:46 -0000
Tomas Gustavsson <tomas.gustavsson@primekey.com> wrote: > On 2020-06-28 22:51, Michael Richardson wrote: >> >> Thank you again for reviewing the document! >> >> I know that primekey is involved in creating Birth Certificates for >> many product lines. (Your website's term, not mine, but a good >> one) > It wasn't my (ours) terminology unfortunately :-). We found it > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have > the same concept, but calling Vendor certificate. I think birth > certificate is a little better, as it's more generic than specifying a > vendor relationship. I do like the birth concept, and I am thinking if changing the document name to include it would make sense. Perhaps someone with expertise in attachment parenting can provide some interesting words about how trust anchors are installed. >> I wonder if you can comment on which of the three methods you >> support? Do you have any suggestions on names for the three >> methods? To me, just getting three good names is 90% of the value >> of this document. > We support: > 2.1.1. On-device private key generation > Standard CSR-submitted-to-CA process I have named this: a) _device-generated_ / _mechanically-transfered_ b) _device-generated_ / _network-transfered_ I know that you are blown away by my imagination here. Perhaps someone can feed this through a mechanical translator, run it English->German->Mandarin->Swahili->English, and see what comes back. I think that it's useful for the entity that needs to examine the risk for the process to distinguish the two transfer methods. > 2.1.2. Off-device private key generation > Typically CA-generates-keystore process. Some protocols, i.e. > CMP/RFC4210 have standard support for encrypting the private key sent > back to the client I have named this: a) _factory-generated_ / _mechanically-transfered_ Like a serial console connection, or a JTAG flash writer. for b) _factory-generated_/ _network-transfered_ yes, but what key would you use? :-) The device has nothing.... So I think that it really has to always be used in the factory with a physically secure network connection. > 2.1.3. Key setup based on 256-bit secret seed > We haven't seen this. Albeit, it's not so much related to the PKI > part, so it can still be supported/used if the certificate issuance is > done using a CSR process to the CA. I have named this: device/factory-co-generated I had not seen this either. Laurence Lundblade, formerly of Qualcomm says that it's a thing. While the interface to the CA could still be via CSR, the CSR is generated by the OEM, possibly not in the factory at all. The private key can be generated, used to sign a CSR and create a certificate, and then destroyed. This can occur completely asynchronously to the manufacturing process. It can occur in advance, in which case the certificate can be loaded via a (pipelined) write operation to the device, which will generate the same private key. It can also occur after the device has been built and provisioned. The device might never actually have it's certificate internally: the onboarding infrastructure could retrieve it from the OEM when the device first shows up. Or the device could retrieve it when it first boots up as part of the QA process. But, ultimately, what's happening is that >> Thinking about "birth" concept, I am trying to think if this helps >> with terms. Invivo <- self-generated private key, with >> enrollment. Invitro <- private key generated in test-tub, deployed >> to device. > Good idea to have naming for these. I like the idea. I don't have any > immediate ideas. Are there any naming from TMP/SE vendors/standards > that can be re-used? (I'm not very familiar with those specs myself). -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Secdispatch] IDevID considerations document to s… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Brockhaus, Hendrik
- Re: [Secdispatch] [lamps] IDevID considerations d… Tomas Gustavsson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Tomas Gustavsson
- Re: [Secdispatch] [lamps] IDevID considerations d… Brockhaus, Hendrik
- Re: [Secdispatch] [lamps] IDevID considerations d… Brockhaus, Hendrik
- Re: [Secdispatch] [lamps] IDevID considerations d… Brockhaus, Hendrik
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Michael Richardson
- Re: [Secdispatch] [lamps] IDevID considerations d… Phillip Hallam-Baker