From nobody Mon Jun 1 13:02:13 2020 Return-Path: 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 629623A150D for ; Mon, 1 Jun 2020 13:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de 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 ExOwXWOSy_Tb for ; Mon, 1 Jun 2020 13:02:10 -0700 (PDT) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC573A150F for ; Mon, 1 Jun 2020 13:02:10 -0700 (PDT) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 0C0D42400FD for ; Mon, 1 Jun 2020 22:02:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1591041726; bh=Z1moeHChzJJ+OLGKSjf6MUxPJpl+SPdOawSFvjAPdEA=; h=From:Subject:Date:Cc:To:From; b=KCRrSmRJNCgcWRW4jYTLbuCbZTviyKxqgkyMsUgorY0fKVgMgYm4fkKhhdeTuxsXl Vkws21TAcgCYqi0IV6I+dwu+c8bX4FHTs2iRCSlJyP3YctvOrm/6bCOzirmU2cyH3K 3YOR0Y62M1xanemo431I9R+BV4EcRXnZnCR3VdKl/y9evyLK/DWtflHoI+/Qfqj6+t b4Wbu/KW3EB3WwN4a1+5efnswxXf/Q2Qus2Uk8/PaHGIzREF4xJ9OOtkuvpowkKUpk /Ej0br349fVVaDQxg2MzkOd4vWazobGvrHn0qHmz5VKnUzbz4W4zeMXhf19zciMZMB eLMhCkLtoKu2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49bR0F11WGz6tmT; Mon, 1 Jun 2020 22:02:03 +0200 (CEST) From: "Schanzenbach, Martin" Content-Type: multipart/signed; boundary="Apple-Mail=_CCEAAC71-CA28-4907-AF5E-321188698EA3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <95519865-F439-449D-8B09-61776400751D@posteo.de> Date: Mon, 1 Jun 2020 22:02:03 +0200 Cc: Christian Grothoff , Bernd Fix To: secdispatch@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Secdispatch] secdispatch agenda request: draft-schanzen-gns-00 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:02:13 -0000 --Apple-Mail=_CCEAAC71-CA28-4907-AF5E-321188698EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, as part of our project [1] we have produced a specification for the GNU = Name System (GNS) [2,3] alternative name system which we'd like to discuss at Secdispatch. The draft outlines the protocol and wire formats necessary to implement = GNS and is already used to implement a resolver in Go [4] as part of the project as well. Here are the documents: https://datatracker.ietf.org/doc/draft-schanzen-gns/ https://tools.ietf.org/html/draft-schanzen-gns-00 Hopefully, SecDispatch will be able to provide some guidance around = where this work can find a home at IETF. Thank you and best regards Martin [1] https://nlnet.nl/project/GNS/ [2] https://gnunet.org/en/gns.html [3] https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf [2] https://git.gnunet.org/gnunet-go.git/ --Apple-Mail=_CCEAAC71-CA28-4907-AF5E-321188698EA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPREGPBD5jRS9JNFHCwmY74b1m2oFAl7VXrsACgkQCwmY74b1 m2ryTg//ULcBMgGZluvUI4IRAjgNVvtx3wfa6OpfXh0Op9iXMQPHH6/drrvA/8DS 7YHGSei/oZID8m9v9ggK11RKkSZZxFVlYR+6IK3PBqe99T57xfZTJF1uhM4SjMh4 8oxtp1Ds79kYlVguyuUMuSL3Dvya95dHKAa2lsOnRX0+y49/IMhrJF5+sJwg7bbh /c4MkkxnVynJSKChfJoikRMziwYBVwIH5QpM4zuoCOKC5XxJdGdk1a4IMziLDq1r I8NYxqqMEOQRQ0SbXRu4jibBmDdm0ooEe2p+WIlEFBBvRnA3wnJh2pyyhyVSA9HE uN3Dvxcd5u6ATYnmxuPCDLRI1TjxUNzf3zJSdjCHZxX5+SGIjXRIgJthGJPe4dLe uDAV9SDnqStPl8TgMgBuByrrQ1JZUUsbOFFuO0MZ0zGOvubC82d8Q5DzPfobnL1S F6S44RXdVpOZHUPrJ368La6Uk7KuVLAF/ldTL9wVEuefWm179sUz57fioklyW7ly 0UmILdrU2FrRxIk1onk5ppj5pai6Qm1xzH7h+QDVRHJNVJCosK3ImL3bo5YYe+ty 2edAKO29FW6+6BSS4RpSekAT2a3Muq75ighNmLeey8kdMWLWkR64XRcMJhhO+xlp NGtRUjrv/6+XUtxT/yZJ7JSeChOjpPkQdvUEsUF6zEwFXU1Ubu4= =hHCr -----END PGP SIGNATURE----- --Apple-Mail=_CCEAAC71-CA28-4907-AF5E-321188698EA3-- From nobody Wed Jun 10 03:10:21 2020 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8528A3A08B3; Wed, 10 Jun 2020 03:10:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: secdispatch-chairs@ietf.org, secdispatch@ietf.org, rdd@cert.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159178381852.17063.15135542430810728496@ietfa.amsl.com> Date: Wed, 10 Jun 2020 03:10:18 -0700 Archived-At: Subject: [Secdispatch] secdispatch - New Meeting Session Request for IETF 108 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 10:10:19 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the secdispatch working group. --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: cbor core gendispatch httpbis Technology Overlap: saag dispatch ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secevent suit teep tls tokbind trans People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Benjamin Kaduk Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. --------------------------------------------------------- From nobody Wed Jun 10 08:52:14 2020 Return-Path: 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 935703A094E; Wed, 10 Jun 2020 08:51:53 -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 CrMIVIkr-y00; Wed, 10 Jun 2020 08:51:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01E73A093A; Wed, 10 Jun 2020 08:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 30CB138A39; Wed, 10 Jun 2020 11:49:19 -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 a6Dmv5aAHGJi; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5069A38A37; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CF51534; Wed, 10 Jun 2020 11:51:46 -0400 (EDT) From: Michael Richardson to: secdispatch@ietf.org Reply-to: secdispatch@ietf.org CC: anima@ietf.org, spasm@ietf.org, lwip@ietf.org, acme@ietf.org In-Reply-To: <10463.1591763623@localhost> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> 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 Archived-At: Subject: [Secdispatch] IDevID considerations document to secdispatch X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 15:52:00 -0000 --=-=-= Content-Type: text/plain Dear Secdispatch chairs and WG, (and various people in the BCC who are encouraged to forward) EXEC SUM: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ While working on ANIMA's BRSKI enrollment system, and the associated mechanisms that create the ACP, it became clear that there was possibly a wealth of useful advice on operating the Manufacturer and Owner components (the MASA and Registrar). As these thoughts grew, it became clear that there were many non-normative, non-wire-protocol level design considerations. Two documents were originally created: a) draft-richardson-anima-masa-considerations b) draft-richardson-anima-registrar-considerations Both situations involve operation of a certificate authority. On the manufacturer side, this involves the Manufacturer Installed Certificate, the IDevID. There are multiple users of the IDevID and there are many entities building a variety of trust models based upon having that trust model. For instance, the Kumari/Doyle Secure Device Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as BRSKI does. Much of the RATS work requires some kind of known signing key to be built-in, secured deep into a hardware or firmware TPM/enclave. If you want to (asymmetrically) encrypt firmware for SUIT, you may need keys built in too. Many other protocols also depend upon keys to be deployed, but can deal with having them deployed as part of configuration, but as we all experienced, actually getting them deployed can be difficult. As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there seems to be three ways to deploy matching private-key/certificates. a) generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically generate keypair from shared secret, deploy certificate via magic. I don't have good names for these three methods, nor sufficient proof that there isn't a reasonable fourth method. One reason (among many) to have names for these three methods is so that it is possible in Supply Chain Security discussions to be able to easily state the inherent security vested in the device, and to thus #include the risk/threat landscape of devices (particularly MCUs) that are included in designs. I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight profile of CMP (such as is in LAMPS) are reasonable protocols for factory time onboarding, but require very strict profiling to get right. This makes it IETF business. I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally said champion would be describing active experience from a real factory. As publically anchored enterprise (intermediate) CAs seem to be a thing of the past, many have discussed how appropriate it might be for manufacturers to use ACME to provision IDevIDs directly. {In fact, I have running code} There are however many aspects of this effort which might reasonably be considered outside of the IETF perview. Fundamentally, these are PKIX objects that are being provisioned, and it is at the IETF that potential successors to PKIX (CoID, JWTs, etc.) are being developed. One of the major difficulties I have experienced in trying to assemble this document is that current methods are often buried in a Silicon vendor/OEM-board vendor interaction fearing many NDAs. This is particularly acute for method (c). This makes it difficult to ascertain what level of care has been taken with the sensitive symmetric keys, which results in a difficulty to compare audit results across the industry. In order to get better and wider review, as well as detailing the required magic, I've split the MASA considerations document into two pieces. One is BRSKI MASA RFC8366 voucher generation specific, which I intend to leave in the ANIMA WG (should the chairs agree), and the other part which is IDevID generation specific, which I am looking for advice from secdispatch to determine what to do with it. The second document is: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ and it is still rather drafty. I will note that draft-richardson-anima-registrar-considerations also discusses an Operator/Enterprise/Home-router having/operating a CA, (among many other things), and I am undecided whether or not to extract that advice and merge it into idevid-considerations. At this point, I think that it is not of general interest and it is better kept isolated. <%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7hAZIACgkQgItw+93Q 3WUUzAgAkr2uWhXQXc69iIGeKa5xyIYJhwB6k62QcYcoPnWImogUfphZDopQa3n7 DUeU5C64E93u4dP3BfW12tOrjv/cGrWV3nVF81BqKAsT3qHm7sf7kC86yeI2IEMB D2OSq/pe0mfBIFNCT6jgWSNVFvns4GJLxKiWiPuqCJYKIbN2xX0txcOY+EMMrgu0 Wa/sq9DApfP53ZgHm0UK9gXSjuvoWIH6nq40A3T5AZf/JHhAO+gYfQqGQra0M4nH M6ex82L5ucsipq0RgTVFeEBcjcMQ1E7L1QPl7KRAKkW6ogAEt5BgwvWtDjjMSKKd mL0CuAkXOfqSzh3WgNAq14rjr/OQVA== =fgBt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 11 10:53:01 2020 Return-Path: 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 66D573A0CF3; Thu, 11 Jun 2020 10:53:00 -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 zQD86cfZfzOf; Thu, 11 Jun 2020 10:52:57 -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 9BC553A0CF8; Thu, 11 Jun 2020 10:52:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CDAB3897F; Thu, 11 Jun 2020 13:50:26 -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 awk_cRgipQb0; Thu, 11 Jun 2020 13:50:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B6E73897E; Thu, 11 Jun 2020 13:50:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A4BA8486; Thu, 11 Jun 2020 13:52:55 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: spasm@ietf.org, secdispatch@ietf.org In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 17:53:00 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: > The notion of serialNumber in the document, for me, reads as it's not > clear what is the certificate serial number (9-19 bytes in your > document) and the device serial number. There don't have to be the > same. What I have seen commonly used is that the subjectDN field is > used to carry the device serial number, while the certificate serial > number is random, and only used to uniquely identify the certificate > in the PKI (issuer/serial). Your assumption is entirely correct. I wish that certificates hadn't used "serial Number" in it's terminology, as it's really "certificate Identifier", and we have learnt the hard way that it should not be sequential. > In such a case I would assume that the manufacturing execution system > (MES) and it's database controls the device serial number, while the > PKI controls the certificate serial number, and there does not have to > be any synchronization between these two. Agreed. Do I say something different here? I would love to clarify things. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7ib3cACgkQgItw+93Q 3WVhYwgAoxUZnvZ5zjFPTVnsGl/Id+hGHpuV35mBQ7p3ppbdQtgLRijmN7uD6MkO cVDMG9ZxRLTWWWvsj1XY73i9XmtTXwYNDH5nGBkBXrAOihDrtdkuK9TWc+UTlNao Vzm/747oSc2+ST7hcq50dolvaLdzyeXEjBbhsSKJKE6ayYXbncRxsX3fjzK/vm7d URm8uCLPb8isgaQbg9qkXJK4A24u11BFO7EoOSNVXfRQdkIcgMsAjFjzx0wRSZQC pnBcThD7+01DUZcuEckQG6WpTPmFxsvLXzKz73ft/NUeYh9WwXwUpOqFHXTKVQbb grumBJt28U9Ca2svVVNhplcFQZB81Q== =HLE3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 28 13:51:35 2020 Return-Path: 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 5B7653A0F3B; Sun, 28 Jun 2020 13:51:34 -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 r2WNrxdtWPaM; Sun, 28 Jun 2020 13:51:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192873A0F39; Sun, 28 Jun 2020 13:51:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C04A3898C; Sun, 28 Jun 2020 16:48:43 -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 A1X3nlNBCMPW; Sun, 28 Jun 2020 16:48:42 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68F3338988; Sun, 28 Jun 2020 16:48:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9116F137; Sun, 28 Jun 2020 16:51:27 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson , secdispatch@ietf.org cc: spasm@ietf.org In-Reply-To: <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 20:51:34 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain 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) 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. 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. I also feel that I want to leverage the "digital twin" terminology a bit for the third case. I suspect that there might also be some hybrid/fourth case that uses Threshold Modes in Elliptic Curves, draft-hallambaker-threshold-02 and while I think this would be an improvement on the security side of things, I also am concerned that it may make the manufacturing process worse. In particular, the self-generated (_invivo_) key suffers because the device needs to do a write/read operation from the infrastructure. That involves the highest possible latency for interaction with the CA and therefore would slow the assembly line the most. The invitro and shared-secret methods allows the infrastructure to generate a few keys in advance (and get them signed, assigning DN-serialNumber at the same time), and then injecting that key via JTAG at the same time as the firmware. This overlaps the CA interaction with other steps. Tomas Gustavsson wrote: > On 2020-06-11 19:52, Michael Richardson wrote: >> >> Tomas Gustavsson wrote: >>> The notion of serialNumber in the document, for me, reads as it's >>> not clear what is the certificate serial number (9-19 bytes in >>> your document) and the device serial number. There don't have to >>> be the same. What I have seen commonly used is that the subjectDN >>> field is used to carry the device serial number, while the >>> certificate serial number is random, and only used to uniquely >>> identify the certificate in the PKI (issuer/serial). >> >> Your assumption is entirely correct. I wish that certificates >> hadn't used "serial Number" in it's terminology, as it's really >> "certificate Identifier", and we have learnt the hard way that it >> should not be sequential. >> >>> In such a case I would assume that the manufacturing execution >>> system (MES) and it's database controls the device serial number, >>> while the PKI controls the certificate serial number, and there >>> does not have to be any synchronization between these two. >> >> Agreed. Do I say something different here? I would love to clarify >> things. > This section confused me at first read: > ----- > In all cases the serialNumber embedded in the certificate must be > unique across all products produced by the manufacturer. This suggests > some amount of structure to the serialNumber, such that different > intermediate CAs do not need to coordinate when issuing certificates > ----- > At first read I thought about certificate serial number, but now > realize it's the device serial number that is meant. I think that > section can be clarified somewhat. okay, I will do that. I wish I had a good way to distinguish things. "serialNumber" (in that case), is a used in RFC5280 as the field name of the "CertificateSerialNumber", I sure wish we could go back and change the name of the field to be "certificateIdentity" The same document mentions "id-at-serialNumber" and X520SerialNumber! And in section 4.1.2.4 (Issuer) and 4.1.2.6 (Subject), it uses the term "serial number"... and the usual rendering in a DN is that it is "serialNumber" (OID 2.5.4.5, I think it is)! I will call it the "product DN-serialNumber". How does this strike you? > Some additional nitpicking... > I think this section is missing an 's'? Do you mean the title? that it should be: ## Public Key infrastructure for IDevID -> ## Public Key infrastructure for IDevIDs > ----- > The intermediate CA will have a private key, likely kept online, which > is used to sign each generated IDevID. Once the IDevID are created, > the private key is no longer needed and can either be destroyed, or > taken offline. > ----- > In the line preceding this section it talks about "some number of > IDevIDs". Then that the CAs private key can be destroyed after > generating that number if IDevIDs. Hence, just ad an s: > "Once the IDevID are created, the private key is no longer needed and > can either be destroyed, or taken offline." -> > "Once the IDevIDs are created, the private key is no longer needed and > can either be destroyed, or taken offline." I think I found all the missing s, and one case where it should be CAs' rather than CA's. see commit/diff: https://github.com/mcr/idevid-security-considerations/commit/84fa9fad74d9b2d950b061a4fa5bf3fe99443472?short_path=77f5cdf#diff-77f5cdfefb38aca78416645deaa3310e --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl75As8ACgkQgItw+93Q 3WUKKwgAkkb57DzjtQWi+sKUEPTjFm8ak2nX4OM26JBC2eo1xwDVZ8Drny1tIUQZ wk6B06iZcX0wZflYmy11VT/krWsI3P+f7H8tcbMJUsrr/KwQgiBlzNADpIKZYum6 hbtOVjwQCRTpK5aR5qa3DdjQ10vvedA8xrWfw6nRoDoiq2AoPMlx2wM3C+ohuTgh LDFnqgQndK7oMaJOby1isas9nEacqLjRPRCTHLWYttkIe1rtnd6aOmiThmPqSgC2 6VUa5yJhPR9dg2cZZH8sDfBdciD5CNhwnoOfZEzJrqtGj4XK5OhEDF+dYICw1EoS 5wtRZ6qVSxV30NOIXwH3b9FtkfwSkg== =p5Dx -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Jun 29 00:10:36 2020 Return-Path: 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 18C773A090B; Mon, 29 Jun 2020 00:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 rYlzGpBxBwCD; Mon, 29 Jun 2020 00:10:30 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20041.outbound.protection.outlook.com [40.107.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F583A0901; Mon, 29 Jun 2020 00:10:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RY4OZy3nVh6P/zGRu4jlT+qbCmu6EjjnOAilbHDYt8Fia8wjo2yb9jjhxNuJ0YJyrL8YiYmH37cGZ5GC/ISNraOFK7GVtzhdDUQBoje53oZh+4+VLKzcF2JktxBb5CBSNwAdRJZlJykKsQVKz1R1KyXmhzZcVDchcNaNETb/YnGjED/LelSaUAqgvCIsF1k3J2kLb5OzFAmiZeskWOA/cfONmpRgwoEqzVTC+rG2q2S2FzMkV/btM49QjalZ+GNkyBy+bqCEmRZuM5jb75JVh4PA4yN9e1pz/m2ogcN77eH7cCEMSePl4etGKNp5FtMKAZne41NHrMr2kQSw7gJQKA== 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=NUlRfvsB1SVaR2prfoPgY+Lp4bj7Oa1+QL8+1/vft+o=; b=GBlY2p/itzBWmgYGMm33b82yxmvNHF0gs78ChsTHqmivOAhNvtZEO3PlT25+fbm35sTWtZrsRcEkvOtpk9W8FfBm3v54kyNckinfiIZvR7hBBfnrjXi/oWilbv6ApRJkkM42IuVjNHKir0II4EUPFXAFIDapnec4zG0ZmRmkGA2b8pYmjdoi72J3GYh/4r4flr4eh1+ARz+FY8Fzut70d12V+GwrI2+HI0wXwwSJ8I24hviuFpSKfJdPFep0GNo8kOrE405ydp4uzseAxjBZ8y4pTyXrt276XH/Xs5dr8c4WO0v+npeb6W/WrA+Gi6n/E1bPXynGgc9kZchDvFzI7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NUlRfvsB1SVaR2prfoPgY+Lp4bj7Oa1+QL8+1/vft+o=; b=aginh0f0nBBP2VjgPEGUT6P64O03R4GL92HBc0oWHw69ZjJzFc+4VKlcNaNuWdOjsfy6KmaFbXHIwr46PgNZuxpcc1KSJSAhxoO2F5ojsUbUOiUOZEMUyCb5dL+5fqxRjN9C6aldnHO0AclZ3T7xxK5Z8xKSBdhCh336o5SAXQE= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e2::32) by AM0PR10MB2868.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:15d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Mon, 29 Jun 2020 06:54:36 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 06:54:36 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson , "secdispatch@ietf.org" CC: "spasm@ietf.org" , Tomas Gustavsson Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAApgFA Date: Mon, 29 Jun 2020 06:54:36 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> In-Reply-To: <20595.1593377487@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.26.241] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ebdf368-d81c-44cf-825b-08d81bf94936 x-ms-traffictypediagnostic: AM0PR10MB2868: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NLeahZ2/whU/GoG8u9mMqLZg5Tg8cVHwmu4Xhfn6CZhYFTCh6otAweVe8epZyaftk+bBrP27yO1WkyMVjgRonS7X1QI3HEMjUA4izFUF6ASiFgW/oNqax3ZjWEuxauiirJp4cBv/AyEF4C4v4qhEHgk3OeXfkhRPHRnRxCeKfK+O9UXEOjB9NdmbBYMccGDrZsC3RDMiIa0IgWsbEvwZa0CAmu4/MlmyPDLpF3Kdul9M87aVHiR5poy64HRSQLrrNDuJLrKmqgCW0abT1HQ40NvihzF/wCAZjvP3QaC/pM4/69teRS0w5+so0g62lqBKF+rxATLzDwFq8mPKSrq54A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(54906003)(26005)(55236004)(478600001)(71200400001)(83380400001)(33656002)(86362001)(316002)(55016002)(9686003)(64756008)(66446008)(6506007)(2906002)(110136005)(66946007)(76116006)(7696005)(66476007)(4326008)(66556008)(186003)(8936002)(52536014)(8676002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qTbLbRLWV/kWib1nMpL+TxiMMMTwBLKy9Jw4gj57BXXdq06cVSd932vCTx+F868SumMMSD5EUBXI85ko5Xu3XvAHY7uVkVO+NMvcOwksfqYBR937d+bkGilKovQ8NK2QmjYSo4v/CAqhGsW0utp/4rPp1UJ270zXuCyXbmFzZFt2rYN+dn3tdDpt0AdX1iTTOidTBt/LcmSX8DbGAmA0TkINDLXOkBKC+eykWkmY1wUECvN7XB6azHbwaoAW+SiswNPl6MU72s7uPkIit4zx/OwXA21jrdzMUFNGdEC5bElxkugh/+qGZTSY9o4iMP3CkzzK9RfaXupm3OHSSwX3FWYHzSvy0CcsOKrCggITBEwY2bLrA7dW5w/4NWD/BdlyAt7Kjg0zOEVJmF1+Rb0YezLn9CKN3B+ci+zXgqql5UN2dPYSdw2vG3cjo0ovWWiNnFqqNao5WGB3Fz9JgQNA1duP7ZVgi8Eaw3CMNVXiRidibTXI5LaNzfBPi9WvXGJB x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6ebdf368-d81c-44cf-825b-08d81bf94936 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 06:54:36.1051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /SlIaUEOPx2SGR4HjppWc6VqOQqVTABlhV/toYGHFqeuuSIT2mKrSqVNZEZBxFkEZdPpdJjIaCDgimIBQFoToBa8jgoBrEmlHbkl4Ir+NDQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2868 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 07:10:31 -0000 Richard >=20 > In particular, the self-generated (_invivo_) key suffers because the devi= ce > needs to do a write/read operation from the infrastructure. That involve= s the > highest possible latency for interaction with the CA and therefore would = slow > the assembly line the most. We make use of the key-pair generated on the fly on the device and do not s= ee major delay on the manufacturing line due to CA communication. Finally it is a question of how you arrange your manufacturing procedures. = If you experience delay due to waiting for the certificate delivery, you ca= n do other meaningful things in the meantime. >=20 > The invitro and shared-secret methods allows the infrastructure to genera= te a > few keys in advance (and get them signed, assigning DN-serialNumber at th= e > same time), and then injecting that key via JTAG at the same time as the > firmware. This overlaps the CA interaction with other steps. >=20 Finally this method puts higher security burden on the manufacturing infras= tructure to securely handle the pre-generated key pairs. This is why I do n= ot like it, but sometimes it is needed. -- Hendrik=20 From nobody Mon Jun 29 01:05:31 2020 Return-Path: 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 09ADF3A0BD5; Mon, 29 Jun 2020 01:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=JPnIoCWY; dkim=pass (1024-bit key) header.d=primekey.com header.b=JPnIoCWY 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 uTxYNRvDkGT6; Mon, 29 Jun 2020 01:05:23 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D4E3A0BAE; Mon, 29 Jun 2020 01:05:22 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id C99606AA01AD; Mon, 29 Jun 2020 10:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1593417901; bh=U9yK/HrtiQOG2UeMDHjoahKkRMUis3hFHUzPEhgjgLk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JPnIoCWYriSlI1NnrJo4fFTnHVVYKPk0sAXRIhXqjBwCOxeh6g0xoK64PUddvn1Gb By3mM0LVgry3XMFWeJgYy7hjdRzk1GH2bh91mU1izOkDied+7dx68PGqEa9/V5SZkW +RKOkMDsZRcZk5BQM/8nM9+bukTh5Nf2h3DsfI4Y= Received: from [192.168.1.100] (m37-2-193-37.cust.tele2.se [37.2.193.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 88DAE6AA01AB; Mon, 29 Jun 2020 10:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1593417901; bh=U9yK/HrtiQOG2UeMDHjoahKkRMUis3hFHUzPEhgjgLk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JPnIoCWYriSlI1NnrJo4fFTnHVVYKPk0sAXRIhXqjBwCOxeh6g0xoK64PUddvn1Gb By3mM0LVgry3XMFWeJgYy7hjdRzk1GH2bh91mU1izOkDied+7dx68PGqEa9/V5SZkW +RKOkMDsZRcZk5BQM/8nM9+bukTh5Nf2h3DsfI4Y= To: Michael Richardson , secdispatch@ietf.org Cc: spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> Date: Mon, 29 Jun 2020 10:05:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20595.1593377487@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 08:05:26 -0000 Hi, 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 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 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 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. > 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). > I also feel that I want to leverage the "digital twin" terminology > a bit for the third case. > > I suspect that there might also be some hybrid/fourth case that > uses Threshold Modes in Elliptic Curves, > draft-hallambaker-threshold-02 and while I think this would be an > improvement on the security side of things, I also am concerned > that it may make the manufacturing process worse. > > In particular, the self-generated (_invivo_) key suffers because > the device needs to do a write/read operation from the > infrastructure. That involves the highest possible latency for > interaction with the CA and therefore would slow the assembly line > the most. > > The invitro and shared-secret methods allows the infrastructure to > generate a few keys in advance (and get them signed, assigning > DN-serialNumber at the same time), and then injecting that key via > JTAG at the same time as the firmware. This overlaps the CA > interaction with other steps. > > > Tomas Gustavsson wrote: >> On 2020-06-11 19:52, Michael Richardson wrote: >>> >>> Tomas Gustavsson wrote: >>>> The notion of serialNumber in the document, for me, reads as >>>> it's not clear what is the certificate serial number (9-19 >>>> bytes in your document) and the device serial number. There >>>> don't have to be the same. What I have seen commonly used is >>>> that the subjectDN field is used to carry the device serial >>>> number, while the certificate serial number is random, and >>>> only used to uniquely identify the certificate in the PKI >>>> (issuer/serial). >>> >>> Your assumption is entirely correct. I wish that certificates >>> hadn't used "serial Number" in it's terminology, as it's >>> really "certificate Identifier", and we have learnt the hard >>> way that it should not be sequential. >>> >>>> In such a case I would assume that the manufacturing >>>> execution system (MES) and it's database controls the device >>>> serial number, while the PKI controls the certificate serial >>>> number, and there does not have to be any synchronization >>>> between these two. >>> >>> Agreed. Do I say something different here? I would love to >>> clarify things. > >> This section confused me at first read: ----- In all cases the >> serialNumber embedded in the certificate must be unique across >> all products produced by the manufacturer. This suggests some >> amount of structure to the serialNumber, such that different >> intermediate CAs do not need to coordinate when issuing >> certificates ----- > >> At first read I thought about certificate serial number, but now >> realize it's the device serial number that is meant. I think >> that section can be clarified somewhat. > > okay, I will do that. I wish I had a good way to distinguish > things. > > "serialNumber" (in that case), is a used in RFC5280 as the field > name of the "CertificateSerialNumber", I sure wish we could go back > and change the name of the field to be "certificateIdentity" > > The same document mentions "id-at-serialNumber" and > X520SerialNumber! And in section 4.1.2.4 (Issuer) and 4.1.2.6 > (Subject), it uses the term "serial number"... and the usual > rendering in a DN is that it is "serialNumber" (OID 2.5.4.5, I > think it is)! > > I will call it the "product DN-serialNumber". How does this strike > you? For me that is crystal clear. Nice. > >> Some additional nitpicking... I think this section is missing an >> 's'? > > Do you mean the title? that it should be: ## Public Key > infrastructure for IDevID -> ## Public Key infrastructure for > IDevIDs > >> ----- The intermediate CA will have a private key, likely kept >> online, which is used to sign each generated IDevID. Once the >> IDevID are created, the private key is no longer needed and can >> either be destroyed, or taken offline. ----- > >> In the line preceding this section it talks about "some number >> of IDevIDs". Then that the CAs private key can be destroyed >> after generating that number if IDevIDs. Hence, just ad an s: > > > >> "Once the IDevID are created, the private key is no longer needed >> and can either be destroyed, or taken offline." > -> >> "Once the IDevIDs are created, the private key is no longer >> needed and can either be destroyed, or taken offline." > > I think I found all the missing s, and one case where it should be > CAs' rather than CA's. > > see commit/diff: > https://github.com/mcr/idevid-security-considerations/commit/84fa9fad74d9b2d950b061a4fa5bf3fe99443472?short_path=77f5cdf#diff-77f5cdfefb38aca78416645deaa3310e > > > > -- ] Never tell me the odds! | ipv6 > mesh networks [ ] Michael Richardson, Sandelman Software Works > | IoT architect [ ] mcr@sandelman.ca > http://www.sandelman.ca/ | ruby on rails [ > > > >