Re: [Acme] Assisted-DNS challenge type

Niklas Keller <> Tue, 23 January 2018 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88DEF120726 for <>; Tue, 23 Jan 2018 00:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9IvTw00hmane for <>; Tue, 23 Jan 2018 00:09:52 -0800 (PST)
Received: from ( [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB8C012421A for <>; Tue, 23 Jan 2018 00:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1516694989; s=strato-dkim-0002;; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:References: In-Reply-To:X-RZG-CLASS-ID:X-RZG-AUTH; bh=w6COkAHfeNARqBjHFyjFbAV5JphcAEKGgy9iZiiVcVo=; b=Vcz1YlbOBOa/hDboSNZV6/gqTrglG2OoU8EKVHgCFGuHh/3RNZTn9zNGI4vHke1o6i QwIuvmxm+8qGnNyjT/VNFjCwMTux24TbX/BEwly7oL463hSxUXDCnqH0tpWzb1AdXwFl JkzovqskJx+7IH3U9WTCGQCqQ0sIyVQ7q6XqnwGZompasxG0jKgdBntKL31Aam1Z9HgV zYz8yOUHL+xDcRQCob1dYvlNgYbga/Vpenuesn7xOOPpC4BHaJlls82ar8xulsExGi6r RMzNEy0te/Y8/6LgUxLlGwmkKaMxqYo39Mf3bLPDtHk7Ryv0nJ9CEqtFFBxmbks93he6 Wqfw==
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mlsGbEv0XHBzMIJSS+jKTzde5mDb8Db2nURiuwcA==
Received: by with SMTP id t201so3951572ywf.1 for <>; Tue, 23 Jan 2018 00:09:49 -0800 (PST)
X-Gm-Message-State: AKwxyte7SROIGNch/6rlQngtTdTVDgOiNhEUF+Z94mA0JP+ANTJNEAwp 78+Iqgksvq1V8ydtPcFMycu9H9dGxWc6l8HUJ3M=
X-Google-Smtp-Source: AH8x226me/zYjtI+bquq67FAUSZqFSczYQw9If2bUv4tNUJbyHAnmyp+I/Irr57lx7anpd/8MpUQ1TuvElSW4JULcJM=
X-Received: by with SMTP id r140mr1550984ywg.442.1516694988663; Tue, 23 Jan 2018 00:09:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 23 Jan 2018 00:09:48 -0800 (PST)
In-Reply-To: <20180123070934.GA6737@LK-Perkele-VII>
References: <> <20180123070934.GA6737@LK-Perkele-VII>
From: Niklas Keller <>
Date: Tue, 23 Jan 2018 09:09:48 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Ilari Liusvaara <>
Cc: Jacob Hoffman-Andrews <>, "" <>
Content-Type: multipart/alternative; boundary="94eb2c0b7a520831a005636d1253"
Archived-At: <>
Subject: Re: [Acme] Assisted-DNS challenge type
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jan 2018 08:09:55 -0000

2018-01-23 8:09 GMT+01:00 Ilari Liusvaara <>:

> On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews wrote:
> >
> > To fix that, the CA could assist the user by providing narrowly-scoped
> > DNS hosting: It would serve only TXT records used in validating DNS
> > challenges. The CA instruct subscribers to delegate the _acme-challenge
> > subdomain to a subdomain of the CA's hosted DNS domain. For instance, if
> > a subscriber has account number 1234, the CA would say: Please deploy a
> > CNAME record like so:
> >
> >
> > The assisted-dns-01 challenge would then be validated like dns-01,
> > except: As the first step in validation, the CA would deploy the
> > expected TXT value at Then the CA would
> > continue to look up "TXT" In a way,
> > fetching final TXT record would be a formality: the CA could in theory
> > stop once it saw the CNAME pointed at the right location, though most
> > likely abiding by the terms of the BRs would require following the
> > formal lookup steps.
> >
> > This challenge has the big advantage that subscribers only need to do a
> > one-time CNAME setup, and renewals can be reliably automated without
> > requiring that renewing systems have permission to update DNS. In
> > effect, the CNAME record would act like a long-term delegation
> > permitting the CA to issue continuously for the base domain.
> I came up with very similar method when trying to figure out how the
> Amazon Certificate Manager DNS challenge works. It has similar
> "standing authentication" property, and yet needs to comply with the
> BRs.

This seems very much like a circumvention of the BRs. Either this
circumvention should be forbidden, because it effectively doesn't re-prove
ownership, or the BRs can be changed to allow permanent authorization for
accounts, then we don't need the CA to host anything like that.

We could then allow e.g. an account key thumbprint to authorize a specific
account key to request certificates. Using the account key would allow that
key to request those certificates from any ACME supporting CA, not just
one. A binding could be introduced, but I guess CAA already solves that.

Regards, Niklas