Re: [Acme] scope in dns-account-01 and dns-02 challenge

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 19 March 2024 16:18 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D75C14F6EC for <acme@ietfa.amsl.com>; Tue, 19 Mar 2024 09:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nII805lkXFms for <acme@ietfa.amsl.com>; Tue, 19 Mar 2024 09:18:36 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566EAC14F68C for <acme@ietf.org>; Tue, 19 Mar 2024 09:18:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0886A46E50 for <acme@ietf.org>; Tue, 19 Mar 2024 18:18:33 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id vLy88I6-XZHG for <acme@ietf.org>; Tue, 19 Mar 2024 18:18:32 +0200 (EET)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B3CD07A for <acme@ietf.org>; Tue, 19 Mar 2024 18:18:31 +0200 (EET)
Date: Tue, 19 Mar 2024 18:18:31 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: acme@ietf.org
Message-ID: <Zfm617vZpw4KX5Ll@LK-Perkele-VII2.locald>
References: <CAN3x4QkK6dFnoo0wfyCBf9_beuQf+Og9+EhoeYvMUbFaoGw8zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAN3x4QkK6dFnoo0wfyCBf9_beuQf+Og9+EhoeYvMUbFaoGw8zw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/8BFKKeBLU6zf-fr3nwG97QpcCjk>
Subject: Re: [Acme] scope in dns-account-01 and dns-02 challenge
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Mar 2024 16:18:38 -0000

On Mon, Mar 18, 2024 at 04:03:07PM -0700, Jacob Hoffman-Andrews wrote:
> Thanks, authors, for the updates in
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00
> .
> 
> Adding a "scope" (host, wildcard, or subdomain) to the DNS record name is
> great. Reading the draft, I think it doesn't specify how the scope for a
> given challenge is decided and communicated. Three ideas:
> 
> 1. Server picks, and tells the client.
> 
> The challenge object contains a "scope" field. The client verifies that the
> indicated scope is one of "host", "wildcard", or "subdomain", and is less
> than the maximal scope the client is willing to validate for. For instance,
> a client might be configured to only accept "host" scope.
> 
> 2. Client picks.
> 
> When the client POSTs to the challenge URL, instead of sending the empty
> object {}, it sends {"scope": "host"}, {"scope": "wildcard"}, or {"scope":
> "domain"}. The server verifies that the request scope is sufficient for the
> authorization object (i.e. "wildcard" or above for an authorization object
> that can be used to issue for a wildcard name), then performs the
> validation.
> 
> 3. Server offers options via challenge types
> 
> We explode out the challenge types from two to six:
> 
> dns-host-02
> dns-wildcard-02
> dns-domain-02
> dns-account-host-01
> dns-account-wildcard-01
> dns-account-domain-01

The client also needs to know the acceptable domains, and needs to
select the domain to use.

I think the simplest way to do that is for CA to tell the client what is
the maximum allowed number of label strips (which might be 0), and then
client to tell the CA the number of label strips to do.

The maximum allowed strip count could be field in challenge object
(if not present, domain authentication is not allowed). And then if
doing domain authentication, client sends the actual strip count (which
may be 0) in the POST to the challenge URL (if not present, this is
host or wildcard authentication).




-Ilari