Re: [Acme] Final thoughts on draft-ietf-acme-acme-05

Ilari Liusvaara <> Sun, 12 March 2017 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68368129503 for <>; Sun, 12 Mar 2017 13:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QLanhPT3hzmh for <>; Sun, 12 Mar 2017 13:11:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F0AFE12941C for <>; Sun, 12 Mar 2017 13:11:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFDA21E72B; Sun, 12 Mar 2017 22:11:08 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 3PwFPrZFtg6J; Sun, 12 Mar 2017 22:11:08 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7FCB22310; Sun, 12 Mar 2017 22:11:08 +0200 (EET)
Date: Sun, 12 Mar 2017 22:11:01 +0200
From: Ilari Liusvaara <>
To: Jacob Hoffman-Andrews <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc:, Hugo Landau <>
Subject: Re: [Acme] Final thoughts on draft-ietf-acme-acme-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Mar 2017 20:11:13 -0000

On Sun, Mar 12, 2017 at 12:11:19PM -0700, Jacob Hoffman-Andrews wrote:
> Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I
> think most of your comments have been addressed in merged or active PRs.
> On 02/07/2017 09:15 PM, Hugo Landau wrote:
> > Finally, I may as well mention wildcard domains again. I don't really
> > get the aversion to standardizing this. I previously proposed that these
> > be validated by n verification requests from a server to
> > randomly-generated, unguessable labels substituting for a wildcard. This
> > adequately proves that a wildcard is actually configured and that the
> > service located by it is under account control. These would be blind;
> > the hostnames used for the requests wouldn't be shown in the
> > authorization or challenge objects, so the client wouldn't know what
> > names would be used until the verification request comes in. Arguably,
> > though, even this is overkill, and just creating authorization objects
> > for unblinded, randomly generated names substituting for the wildcard
> > would suffice. (In fact, as far as I can tell, nothing in the current
> > spec actually prohibits doing this.)
> >
> > There are real applications for wildcard domains. For example, the
> > ability to create unlimited numbers of secure origins has real value to
> > some classes of web application.
> Yep, I also think it would be nice to standardize wildcard issuance!
> Richard's introduction of the "new-order" flow was intended to make
> wildcard issuance at least possible, but there's still a big question
> mark about what authorizations a server *should* create. To some extent
> that is up to server policy, but I think it's worthwhile to recommend on
> option.
> Note that the CA/Browser Forum Ballot 169 validation rules indicated
> that validating the base domain is sufficient to issue a wildcard
> certificate, so we could just echo that. But my feeling of the group is
> that folks would like to define a standard way of validating wildcards
> that is better than that baseline.

Actually, AFAICT, Ballot 169 rules say something stronger for
connection-based methods: Wildcards are validated via base domain.
And all ACME methods are connection-based. So from viewpoint of ACME,
wildcards are validated by contacting the name identified by stripping
the '*.' from beginning.

And when it comes to interaction with PSL, the resulting name can be
'PRIVATE' but not 'ICANN'. 

One pretty obvious thing is strongly splitting challenge responses, so
that there is no way wildcard and non-wildcard challenge responses can
be mixed up (I think TLS-SNI is the hardest here, as DNS and HTTP are
just dumb textual fields)...