Re: [Acme] ACME signature mechanics

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 08 December 2014 07:15 UTC

Return-Path: <James.H.Manger@team.telstra.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 17C851A6FD4 for <acme@ietfa.amsl.com>; Sun, 7 Dec 2014 23:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.799
X-Spam-Level: *
X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] 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 5dtfikHiwou3 for <acme@ietfa.amsl.com>; Sun, 7 Dec 2014 23:15:43 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9D71A6FCC for <acme@ietf.org>; Sun, 7 Dec 2014 23:15:42 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.07,537,1413205200"; d="scan'208,217";a="244415310"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 18:01:22 +1100
X-IronPort-AV: E=McAfee;i="5600,1067,7645"; a="319179452"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 18:15:37 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 8 Dec 2014 18:15:36 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Richard Barnes <rlb@ipv.sx>
Date: Mon, 08 Dec 2014 18:15:35 +1100
Thread-Topic: [Acme] ACME signature mechanics
Thread-Index: AdAStHwHzfxL5PPwRgSpi3Ok2vOPrgAAV8zw
Message-ID: <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> <CAL02cgRnJmB4Ea9D38vZhnS4_aRACkieZnPvDaF2AtDTaB8jXA@mail.gmail.com>
In-Reply-To: <CAL02cgRnJmB4Ea9D38vZhnS4_aRACkieZnPvDaF2AtDTaB8jXA@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E127D52051C8WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/kdKNWaUVJL2v-sIB8BfeDqX47V8
Cc: "acme@ietf.org" <acme@ietf.org>
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: Mon, 08 Dec 2014 07:15:44 -0000

2. Appending ‘path’ to ‘.well-known/acme-challenge’ as part of a simpleHttps challenge (section 6.1) looks dangerous if not done carefully. What if ‘path’ is “../../user/alice/whatever”?

Suggestion: I would be tempted to say: “take the ‘path’ string value, UTF-8 encode it, base64url-encode those bytes, then append to ‘.well-known/acme-challenge’”.

> Good point.  It seems like a simpler solution would just be to require that the "path" value meet a certain ABNF, e.g., the URL-safe base64 alphabet.  The only reason that the client provides the path is to let it avoid collisions if it has multiple validations in progress, so there's not a need for it to be especially expressive.

That might be simpler, but it relies on clients doing input validation on ‘path’. Telling the client to B64 whatever it gets might be just a smidgen safer.

--
James Manger