Re: [Acme] various issues with the spec

Phillip Hallam-Baker <phill@hallambaker.com> Sun, 14 June 2015 11:09 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 8E8D01B2CAF for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 04:09:32 -0700 (PDT)
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 d_WvWZ9pOeCY for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 04:09:30 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A7A1B2CBB for <acme@ietf.org>; Sun, 14 Jun 2015 04:09:30 -0700 (PDT)
Received: by lagh1 with SMTP id h1so790629lag.0 for <acme@ietf.org>; Sun, 14 Jun 2015 04:09:28 -0700 (PDT)
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=Xi8Yr20f8D82rWm8t98yA2fkZZWmUg672OLM7nYCS2M=; b=MdVpXzzwEPwA/P7o/zeq4pSdlEAAaoBJaXR3G70sb02BGEhjs3RSpAf/q51CR036kL xvC0ZwonFOYsufMi1OuwG+Ey54Wz5QaeEkKQKTqcxT2BzijbXPVMRUdKinzlXnXggxMy cb+DL4rkK1i28xo5DKQ2WSY++vmLaVZJHfNikTm+qKsLLHRo7zaU5mIvD1fjnjFkZpHs kFyPhTfN/ajg17yOrna5KcIzYRM4qoN3uUm0ZFAy9jcxP5o7p6uk2sN266tLr5ev02/V VE7C5TCdVloLdTFFxSfw9vWeSNMBZpwJexHyO26cNfiCpBNEtgiGfb7ug9le2SuFDj6t rXSA==
MIME-Version: 1.0
X-Received: by 10.112.185.100 with SMTP id fb4mr22905061lbc.79.1434280168639; Sun, 14 Jun 2015 04:09:28 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Sun, 14 Jun 2015 04:09:28 -0700 (PDT)
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>
Date: Sun, 14 Jun 2015 07:09:28 -0400
X-Google-Sender-Auth: WgoSKLaChwZQ550S_xgjHxGhWZs
Message-ID: <CAMm+Lwhj22UG0MeETPeVd8k_ZPzcjFRSC8wGn8W8pTZTtJQfPQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Fraser Tweedale <frase@frase.id.au>
Content-Type: multipart/alternative; boundary=001a11c3ca22f5d3dd0518785fe1
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/AGX_33H4c5S85vKcHmRJmNjIJp0>
Cc: "acme@ietf.org" <acme@ietf.org>, =?UTF-8?Q?Stefan_B=C3=BChler?= <acme@stbuehler.de>
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 11:09:33 -0000

As a meta point, this discussion is incomprehensible. The objective is to
produce a comprehensible spec.

We should agree terms of art for the actors, certs etc. and use them
consistently.


On Sun, Jun 14, 2015 at 3:01 AM, 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?
>
> 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?
>
> > > > * 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.
> >
> > regards,
> > Stefan
>
> 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.
>
> Cheers,
> Fraser
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>