Re: [Acme] various issues with the spec

Fraser Tweedale <frase@frase.id.au> Sun, 14 June 2015 01:23 UTC

Return-Path: <frase@frase.id.au>
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 C7D1D1A912B for <acme@ietfa.amsl.com>; Sat, 13 Jun 2015 18:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.028
X-Spam-Level: ***
X-Spam-Status: No, score=3.028 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, 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 84gFeOW6RmcE for <acme@ietfa.amsl.com>; Sat, 13 Jun 2015 18:22:59 -0700 (PDT)
Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CD91A9112 for <acme@ietf.org>; Sat, 13 Jun 2015 18:22:58 -0700 (PDT)
Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t5E1MsQl047634 for <acme@ietf.org>; Sun, 14 Jun 2015 11:22:54 +1000 (EST) (envelope-from frase@frase.id.au)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t5E1Msxc008304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <acme@ietf.org>; Sun, 14 Jun 2015 11:22:54 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9/Submit) id t5E1HdIs008262 for acme@ietf.org; Sun, 14 Jun 2015 11:17:39 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Sun, 14 Jun 2015 11:17:38 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: acme@ietf.org
Message-ID: <20150614011738.GC79627@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20150614002432.58be28e7@chromobil.localdomain>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Fww6vrH1IDgjuEFx6af4lQqHZao>
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 01:23:00 -0000

On Sun, Jun 14, 2015 at 12:24:32AM +0200, Stefan Bühler wrote:
> On Sat, 13 Jun 2015 21:24:41 +0000
> "Salz, Rich" <rsalz@akamai.com>; wrote:
> > > As it doesn't look like there is anyone interested in them on this
> > > mailing list I'll keep them to myself, or post them to github when
> > > I find the time.
> > 
> > No, please post here.
> 
> Ok, here we go:
> 
> * I don't see how a client would determine the /acme/revoke-cert URI,
>   it isn't part of any Link header as far as I could see. Perhaps it
>   should be part of the Link headers of the registration?
> 
> * Updates should use "PUT" instead of "POST", as they should be
>   idempotent
> 
> * When updating a registration sending empty "contact"/"agreement"
>   should actually reset them (if allowed) compared to not sending them,
>   which just retrieves the currently set values.
> 
>   I.e. posting {"contact":[]} should delete all contact information.
> 
> * All responses to successful updates should contain the same "Link"
>   headers as the creating request did.
> 
> * The "success" status code for updates should be documented. Right now
>   boulder always returns "202 Accepted".
> 
>   For challenges the spec says `The server provides a 200 response
>   including the updated challenge.`; boulder returns 202 anyway.
> 
> * simpleHttps: `The content type of the resource MUST be "text/plain"`
>   versus `4. Verify that the Content-Type header of the response is
>   either absent, or has the value "text/plain"`
> 
>   Is an absent Content-Type header ok or not?
> 
> * 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'.

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

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

Cheers,
Fraser

> I guess that the "dns" challenge type is probably not ready yet; but I
> suggest adding a "nodns" challenge which should be required in all
> combinations which don't include "dns": no any _acme-challenge TXT
> must be present.
> 
> Maybe another type "nodnssec" could also be added, to require DNSSEC in
> all combinations not including "dns" - so DNSSEC domains always have to
> be authorized by "dns" challenge.
> 
> Also I'd like to suggest making "dns" more powerful; for example making
> it possible to authorize accounts by public key and to authorize sub
> domains. Example:
> 
> _acme-challenge.example.com TXT "inherit:1 key-sha256:47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU="
> _acme-challenge.example.com TXT "token:17817c66b60ce2e4012dfad92657527a"
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme