[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) 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 =-