[Ace] CA generated keys (was Re: EST over CoAP)
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 May 2018 22:51 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51512D95F for <ace@ietfa.amsl.com>; Wed, 16 May 2018 15:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 WiYF7lDed_FN for <ace@ietfa.amsl.com>; Wed, 16 May 2018 15:51:18 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D406126CBF for <ace@ietf.org>; Wed, 16 May 2018 15:51:18 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [209.171.88.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 546041F906; Wed, 16 May 2018 22:51:13 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C079B137D; Wed, 16 May 2018 23:50:52 +0100 (BST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Michael StJohns <mstjohns@comcast.net>
cc: ace@ietf.org
In-reply-to: <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net>
References: <VI1PR0801MB21122D93F906F952E5E85C87FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <a4d27053f1d2431abee07d2597e14972@XCH-ALN-010.cisco.com> <VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <30117.1526309628@localhost> <VI1PR0801MB21125E90F6D045A50DC52E40FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <53811ca9-0727-414a-4d77-e0f73d8c469a@comcast.net>
Comments: In-reply-to Michael StJohns <mstjohns@comcast.net> message dated "Mon, 14 May 2018 16:50:03 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 16 May 2018 18:50:52 -0400
Message-ID: <17239.1526511052@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/71P7r6ud2I2HPx93lsHYrpG8RbQ>
Subject: [Ace] CA generated keys (was Re: EST over CoAP)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2018 22:51:21 -0000
Michael StJohns <mstjohns@comcast.net> wrote: > Basically, the argument I'm hearing again is that we have to have > common protocols that work with the least capable devices in the same > way that they work with more capable devices. Which then is taken to > mean that we have to limit the security of said protocols to what's > available with those most limited devices. This is not really what's going on here. The argument is whether device generate private keys should be supported in the constrained version of EST. The RA/CA (RFC5280 terms) side of things in generally assumed not be seriously contrained. (I expect to install a CA on an openwrt based Turris home router, but that's equivalent to a 15 year old laptop, and hardly counts as constrained) There is no reason why a RA/CA(%) can't support server-side key generation according to RFC7030 section 4.4 as well as permitting capable devices to generate their own keys. Having the CA generate keys seemed to be all the rage at some point. I was never clear if this was because desktop OSes couldn't be trusted to do it properly, or because end-users wanted their private key as part of their mobile profile, or because of the implicit escrow that it permitted. (Remember splitting signing and encrypting keys...) Panos' situation is, I understand, that he has customers with an extensive deployment of devices in the field. They currently use a proprietary enrollment and key distribution system. They want to "upgrade" to CoAP-EST, but clearly there are some concerns about local key generation. I don't know why exactly, but I suspect it has to with the validation (FIPS140) of the libraries available on that platform: perhaps they are not validated to create their own keys...(yet?) But they can be field upgraded in an unattended fashion to use a standard protocol, as long as they don't have to do new crypto tricks *today*. (%)- In smaller/self-contained systems, the Registration Authority (RA) is often co-located (part of, implemented by the same system) with the Certificate Authority. I actually don't know if the RA or CA generates the private key. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Michael StJohns
- Re: [Ace] EST over CoAP Mohit Sethi
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Mohit Sethi
- Re: [Ace] EST over CoAP Hannes Tschofenig
- [Ace] CA generated keys (was Re: EST over CoAP) Michael Richardson