Re: [Acme] ACME signature mechanics
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 18 December 2014 13:18 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645781A88C7 for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 05:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 BRr2-W4WXRkU for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 05:17:59 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42A31A88C6 for <acme@ietf.org>; Thu, 18 Dec 2014 05:17:58 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id gq15so981637lab.18 for <acme@ietf.org>; Thu, 18 Dec 2014 05:17:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+USD/3JWpVxk3MXaKEwy0bRvWavkRmi151vTANcrmy8=; b=pGe+AOcPW5iMy6gEyIqZ1sO8xtrBiie3xaZ6oyUotDuZmPxNoacs4T/mptO59j79vo u8qP4RHq0lfoL8Ee93jaczMd+9JJ2ure2Y/vtg4Gjq+Qdz/NSHdG/TjTi0hU3UeBRWnp 2OUNIFa5fifVmvwZ3Q7HWpsRTNVMcjG1r/zxBjisd/23OzM16iypkIsCnwDAAw04k+SI r5ywYlm21mdYf9Ovn+IQNMLjMOdteWlk/j4jVnmJuZnXIHpxvXAP70aI+DfXvLUIC2Rh qWILriOcNSGs0fQXNBiTYTMmVCee5JxcLlnB+C5iNwZtjPveCVpSapMHH0De4AMRfjPY TIgQ==
MIME-Version: 1.0
X-Received: by 10.112.119.201 with SMTP id kw9mr2129739lbb.99.1418908677334; Thu, 18 Dec 2014 05:17:57 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 05:17:57 -0800 (PST)
In-Reply-To: <5492CF1B.7010508@gmx.net>
References: <548FF9E3.1020703@gmail.com> <CAL02cgT9iYqtX2Ui5XQYnj=yeF_QnSkKn-jE0D5d56WMzB5bBg@mail.gmail.com> <CAMm+LwjwG0dPTkByu5WZ_ev3xNxAMwunoc-A_VK4sKPSZXRYDw@mail.gmail.com> <006c01d01a33$2b086890$811939b0$@icloud.com> <CABkgnnWGQarDzpx-3f488OF2w3eyTV1iUr4GWyND+_avRHNZ6w@mail.gmail.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> <CAMm+Lwifqgt9e_i=froACzGW3bsY05KBiJJFBRJrqJcZrEqN8A@mail.gmail.com> <5492CF1B.7010508@gmx.net>
Date: Thu, 18 Dec 2014 08:17:57 -0500
X-Google-Sender-Auth: ep9m_E_AsEHZk62z1AxWX5XoPDQ
Message-ID: <CAMm+LwgL0j-FjsUv4NSonvHcjJLpSB8JUbNNGmRvyqi37B+K7g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="047d7bae49daae6b28050a7d6b75"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/weHZLdG4Y6io_wFtPLKVy0ssra0
Cc: Richard Barnes <rlb@ipv.sx>, Trevor Freeman <trevor.freeman99@icloud.com>, "acme@ietf.org" <acme@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Anders Rundgren <anders.rundgren.net@gmail.com>
Subject: Re: [Acme] ACME signature mechanics
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 13:18:05 -0000
On Thu, Dec 18, 2014 at 7:56 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > > Hi Phillip, > > this statement caught my attention: > > On 12/18/2014 01:33 PM, Phillip Hallam-Baker wrote: > > Minimal TLS stacks for embedded devices don't typically do client auth. > > See 'minimal'. > > It depends what devices you are talking about, for what purpose they use > TLS/DTLS, and what the overall design pattern of the device is. > > With the work we are doing in other working groups, such as DICE, we are > trying to give guidance on how to use TLS/DTLS for use with Internet of > Things (=small embedded devices) in an effort to bring more > (standardized) security protocols into those devices. > > With that work we are heavily relying on mutual authentication at the > DTLS/TLS level. > > Ciao > Hannes > > PS: I also don't think that the discussion on this list is relevant to > embedded devices. > Why not? Support for embedded devices and the cloud is the main forcing function here. We already have mechanisms that support automated certificate management, there are dozens. There is little need for these when a customer only has one cert and no need for standardization unless the customer has multiple CAs which is very rare except for the very largest customers. The best justification for making ACME an IETF standard as opposed to LetsEncrypt going off and doing their own thing like every CA to date is that we want to move to an environment where every device uses TLS all the time. Internet of Things and Cloud computing are the two forcing factors that make a standardized, automated issue scheme essential. I want to be able to unpack my Nest thermostat, plug it in and have it grab a certificate from my local cert issue point as part of the mechanism by which I grant it access to my home network. This is an application layer protocol. It should have authentication at the application layer. The reason TLS client auth isn't very useful is that client authentication is an application layer concern, not a transport layer concern.
- [Acme] ACME signature mechanics Manger, James
- Re: [Acme] ACME signature mechanics Richard Barnes
- Re: [Acme] ACME signature mechanics Manger, James
- Re: [Acme] ACME signature mechanics Richard Barnes
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Richard Barnes
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Nico Williams
- Re: [Acme] ACME signature mechanics Nico Williams
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Nico Williams
- [Acme] Integrated with CSR. Re: ACME signature me… Anders Rundgren
- Re: [Acme] ACME signature mechanics Trevor Freeman
- Re: [Acme] ACME signature mechanics Martin Thomson
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Nico Williams
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Nico Williams
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Trevor Freeman
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Hannes Tschofenig
- Re: [Acme] ACME signature mechanics Hannes Tschofenig
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Hannes Tschofenig
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Trevor Freeman
- Re: [Acme] ACME signature mechanics Phillip Hallam-Baker
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Anders Rundgren
- Re: [Acme] ACME signature mechanics Martin Thomson
- Re: [Acme] ACME signature mechanics Anders Rundgren