IETF Logo Mail Archive

Re: [Acme] ACME signature mechanics

Trevor Freeman <trevor.freeman99@icloud.com> Thu, 18 December 2014 18:50 UTC

Return-Path: <trevor.freeman99@icloud.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 658CA1A6FD9 for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 10:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 T7d7WNJaaB7T for <acme@ietfa.amsl.com>; Thu, 18 Dec 2014 10:50:35 -0800 (PST)
Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA481A1B57 for <acme@ietf.org>; Thu, 18 Dec 2014 10:50:35 -0800 (PST)
Received: from Den (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NGS000NDKC76Y10@mr11p24im-asmtp001.me.com> for acme@ietf.org; Thu, 18 Dec 2014 18:50:34 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-18_06:2014-12-18,2014-12-18,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412180179
From: Trevor Freeman <trevor.freeman99@icloud.com>
To: 'Phillip Hallam-Baker' <phill@hallambaker.com>, 'Anders Rundgren' <anders.rundgren.net@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> <CAMm+Lwifqgt9e_i=froACzGW3bsY05KBiJJFBRJrqJcZrEqN8A@mail.gmail.com>
In-reply-to: <CAMm+Lwifqgt9e_i=froACzGW3bsY05KBiJJFBRJrqJcZrEqN8A@mail.gmail.com>
Date: Thu, 18 Dec 2014 10:50:30 -0800
Message-id: <009d01d01af3$8013a2d0$803ae870$@icloud.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_009E_01D01AB0.71F17440"
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQKP4NJlmAveeRXosKJTRtRnsZde3wH5Z8HOAZKX1t0Cmu8+3QIalcPVAimVL9sDJZsK6gG7JfCEmpvBfJA=
Content-language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/y00dskosA621L9wiiy8uaGgehXo
Cc: 'Richard Barnes' <rlb@ipv.sx>, acme@ietf.org, 'Martin Thomson' <martin.thomson@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 18:50:38 -0000

 

 

From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 18, 2014 4:34 AM
To: Anders Rundgren
Cc: Richard Barnes; Martin Thomson; acme@ietf.org; Trevor Freeman
Subject: Re: [Acme] ACME signature mechanics

 

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.

[TF] Strange, I have worked with similar constraints with cloud based services and this model worked just fine.

 

 

 

+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.

[TF] If you trust the proxy enough to terminal the TLS then you trust it enough to pass a flag to indicate authentication succeeded

Have you considered what value the POP on a pkcs#10 actually delivers? It does not show the subject submitting the request is the same as the one in control of the key pair. It just proves to the CA the key pair is functional. 

 

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