Re: [Acme] ACME signature mechanics

Richard Barnes <rlb@ipv.sx> Mon, 08 December 2014 07:45 UTC

Return-Path: <rlb@ipv.sx>
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 37DA91A6FF5 for <acme@ietfa.amsl.com>; Sun, 7 Dec 2014 23:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 SnxGl7JkYS4U for <acme@ietfa.amsl.com>; Sun, 7 Dec 2014 23:45:09 -0800 (PST)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807B01A6FE1 for <acme@ietf.org>; Sun, 7 Dec 2014 23:45:09 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id le20so1935677vcb.12 for <acme@ietf.org>; Sun, 07 Dec 2014 23:45:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EztPufirnZixZrDegLdTMbJSgn7MJKmouooOZaTZ/9I=; b=bM6npG0qP5moPjXE7nYGdEiqvfO84pN2kWKupwdQf8fZzKfPvU5WJ1BL7nVHoJUaHE 73GRnFi4hvReu3jjmaORC5cxchFhAPoh8dvx7o2Rrqn5HAdWavkSjVKpiEFbDOH/tYCO cGC4kll+X1Dr6alwNiiml7DcXr1wPix1V/HnH8nkT0qaDHPc8RAwyHWAt80Qkwit1aoC QOB3A+QSB0QO1tS4npw4gbh+k2Fabu60gC79CdYUvu1Z9JfMpcqeAKP+/GB5rPmX1cO7 ZDjbYE4bV9M67CZPEtulS8DbT1RUSwkcXmaf1kHSiBvkRvoI6aUXBqxaeR7+XY+chru8 doyA==
X-Gm-Message-State: ALoCoQkIBgVp10K6+0Iu3q0q0Kds39jP8CSLChHFG7dxs4qUhhlTzt6v8PCZ+T4TpkutstAHMMo2
MIME-Version: 1.0
X-Received: by 10.221.66.143 with SMTP id xq15mr23956697vcb.35.1418024708691; Sun, 07 Dec 2014 23:45:08 -0800 (PST)
Received: by 10.31.139.9 with HTTP; Sun, 7 Dec 2014 23:45:08 -0800 (PST)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> <CAL02cgRnJmB4Ea9D38vZhnS4_aRACkieZnPvDaF2AtDTaB8jXA@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com>
Date: Sun, 07 Dec 2014 23:45:08 -0800
Message-ID: <CAL02cgQg+x8QT3182LrvspNerHSr+srT_W6cR7ct8fGXiJYEpA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary="001a113608d20b68e10509af9bfd"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/aMhg-ijjhUBUtZEdS6p6mRuVkg4
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:45:11 -0000

On Sun, Dec 7, 2014 at 11:15 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:

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

Relies on *servers* doing input validation; the client chooses the path.
And if the server isn't validating its inputs, we have bigger problems :)
Since not checking other inputs can lead to the issuance of bad certs.

--Richard



> --
>
> James Manger
>