Re: [Acme] various issues with the spec
Stefan Bühler <acme@stbuehler.de> Sun, 14 June 2015 10:31 UTC
Return-Path: <acme@stbuehler.de>
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 E918F1B2C69 for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 03:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.339
X-Spam-Level: *
X-Spam-Status: No, score=1.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vuYT11d9hjr1 for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 03:31:25 -0700 (PDT)
Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF40F1B2C66 for <acme@ietf.org>; Sun, 14 Jun 2015 03:31:24 -0700 (PDT)
Received: from chromobil.localdomain (unknown [IPv6:2a02:8070:a18c:cc00:baca:3aff:fed7:a10a]) by mail.stbuehler.de (Postfix) with ESMTPSA id A2C7BB800B8 for <acme@ietf.org>; Sun, 14 Jun 2015 10:31:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1434277882; bh=7hiokNG9RZF16Dv7Q+Z5wlu/Zgi6Cyg8mUu1xO8rAEg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=kB43Vdgjee4JiszlxVODMHdgNmgXDxSk7+8AQFJkJvWXg49v0X1BmlN4b5EmE33Ht n3mzDhi79JJgyISmwh4ep1B3LOWTeCX+gIT9Ml7tL7fZEQpD6aVmcIQ7u08sLg8dQ4 VixBuOKb5zY+PQF+GznrvPzkAXTxivjF9/3logEI=
Date: Sun, 14 Jun 2015 12:31:21 +0200
From: Stefan Bühler <acme@stbuehler.de>
To: acme@ietf.org
Message-ID: <20150614123121.3284a919@chromobil.localdomain>
In-Reply-To: <20150614070136.GE79627@bacardi.hollandpark.frase.id.au>
References: <20150609221325.63935a29@chromobil.localdomain> <20150613232121.51f292af@chromobil.localdomain> <7ed545b29d5149ebba5582dfec9777f5@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150614002432.58be28e7@chromobil.localdomain> <20150614011738.GC79627@bacardi.hollandpark.frase.id.au> <20150614080646.38a87686@chromobil.localdomain> <20150614070136.GE79627@bacardi.hollandpark.frase.id.au>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/zoLxOBxOo0DtN4sBKvCn2QqKfTE>
Subject: Re: [Acme] various issues with the spec
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: Sun, 14 Jun 2015 10:31:27 -0000
On Sun, 14 Jun 2015 17:01:37 +1000 Fraser Tweedale <frase@frase.id.au> wrote: > On Sun, Jun 14, 2015 at 08:06:46AM +0200, Stefan Bühler wrote: > > On Sun, 14 Jun 2015 11:17:38 +1000 > > Fraser Tweedale <frase@frase.id.au> wrote: > > > > > On Sun, Jun 14, 2015 at 12:24:32AM +0200, Stefan Bühler wrote: > > > > * dvsni: Please don't require the domain name which is being > > > > validated to be part of subjectAltName; configuring such > > > > certificate might break a working setup in production, when it > > > > "wins" over an already present and valid certificate for the > > > > domain. > > > > > > > No, this certificate is only presented for the host > > > `<nonce>.acme.invalid'. > > > > You are thinking of a setup where you configure explicitly which > > certificate is used for which SNI value. But gnutls for example has > > a nice feature where you can just give it all your certificates, > > and it will pick the matching one automatically. > > > Do you propose that the certificate *not* bear the domain name being > validated in *either* the Subject DN or subjectAltName extension? Yes, neither set in the common name nor in subjectAltName; I think gnutls would find both. Just for the record, I'd be fine with adding a subjectAltName like `DNS:<dnsname>.acme.invalid', so the domain name is at least present in some form (although I don't know what to gain from it). > This probably does not affect the protocol, but I think is nice to > include it anyway for the sake of being explicit. Can you identify > any existing server software which would is incompatible with ACME > dvsni due to the validation certificate bearing the name being > validated? I happen to know such webserver: lighttpd 2 (not released yet); see http://doc.lighttpd.net/lighttpd2/mod_gnutls.html > > > > * dvsni: `The public key is the public key for the key pair > > > > being authorized`. I hope this was just an accident, this would > > > > be *really* wrong to require. > > > > > > > Why would this be wrong? Remember that this certificate is > > > generated as part of, and intented for use only as part of the > > > authorization workflow. It has no bearing on certificates > > > eventually issued for the domain name being authorized. > > > > I don't want my webserver to see my account private key, ever. Am I > > really the first guy to have a problem with that? > > > > > > * dvsni: Don't require it to be a self-signed certificate - what > > > > does it matter who signed it? > > > > > > > It must be signed by the account key as evidence that the entity > > > performing the authorization controls the account key. > > > > What exactly is the attack scenario here if this is not checked? > > Person A playing MITM to give control over domain B to account C, > > and account C started the authorization but didn't actually want it > > to succeed? > > > > If you really require such evidence, perhaps it could be required to > > have the certificate signed by the account key instead of being > > self-signed. > > You've convinced me on these latter points - the certificate should > be signed by the account key but the key could be a different key > (i.e. not a self-signed cert) - and this means that the web server > need not have access to the account private key. Ok. regards, Stefan
- [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Salz, Rich
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec hallam
- Re: [Acme] various issues with the spec Fraser Tweedale
- Re: [Acme] idempotent requests (various issues wi… Stefan Bühler
- Re: [Acme] various issues with the spec Fraser Tweedale
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Phillip Hallam-Baker