IETF Logo Mail Archive

Re: [Acme] ACME signature mechanics

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 18 December 2014 12:33 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 4B78B1A888A for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 04:33:59 -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 PJqV2sjJypG4 for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 04:33:58 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A591A883B for <acme@ietf.org>; Thu, 18 Dec 2014 04:33:57 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id hv19so895680lab.14 for <acme@ietf.org>; Thu, 18 Dec 2014 04:33:56 -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=3TkppCx7stZ4P7/L4pzPMz/ZKlDHbjN6XkjJ9PFbMjI=; b=Zwj5BQCIqPkKb2dcDu2jWdx4Q1WxH5dZUAjEbzzDJGjWw5Gz/Fu4KzxhQ0NUtuHN99 DlZgq1ARb/3Eat/Ct9/4MUC9hIGbU7JbhP2REIRyXW4+JmP4mqFNxA7XOr4k3a4oXtke dpL5LijDB51P4lwriXsQKPHwc3CGUJFWrB71Epvs4FnG+/ylQvfK/O41JkTfRSvBEQcL 1mp01mRFz/SK5sZzf2+iguqYuJSI5VtItBU13mxvHYD8NKFx5EZ5XHcTGKKB879F2WPr QTBkSUL4VM4XYB+8goy8yFuvXt77xSsbg53fUsjrNhjj8WZneuZmD8Q2KLqnBrd3kOwl 1MBw==
MIME-Version: 1.0
X-Received: by 10.112.27.133 with SMTP id t5mr1989204lbg.45.1418906036328; Thu, 18 Dec 2014 04:33:56 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 04:33:56 -0800 (PST)
In-Reply-To: <54928827.9030009@gmail.com>
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>
Date: Thu, 18 Dec 2014 07:33:56 -0500
X-Google-Sender-Auth: 4BGP6x95h5wZVi0WR5Cw3ooN6CM
Message-ID: <CAMm+Lwifqgt9e_i=froACzGW3bsY05KBiJJFBRJrqJcZrEqN8A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Content-Type: multipart/alternative; boundary="001a1133b04a43e108050a7cceac"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/m3cvKDpEYXZn_YGwhXNM90kQ7Mo
Cc: Richard Barnes <rlb@ipv.sx>, Martin Thomson <martin.thomson@gmail.com>, "acme@ietf.org" <acme@ietf.org>, Trevor Freeman <trevor.freeman99@icloud.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 12:33:59 -0000

On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:
>
> Having worked with Europe's EAC (e-passport biometric data protection PKI),
> which works as described below, I would strongly recommend NOT using HTTPS
> client-certificate authentication because it doesn't fit a normal
> installation
> with an external security-proxy.


+1

Part of the objective here should be to put the end customer in control by
running their own issue point that is a proxy to a CA or another proxy.
Binding the authentication to the transport means that the proof of
possession can only be verified by the proxy which breaks the model.

On top of which, it is really yucky to implement. The less time spent
traveling unimplemented, unexplored and un-debugged code paths, the better.


Minimal TLS stacks for embedded devices don't typically do client auth. See
'minimal'.

v2.23.0 | Report a Bug | By Email