IETF Logo Mail Archive

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

Peter Thomassen <peter@desec.io> Mon, 16 May 2022 11:47 UTC

Return-Path: <peter@desec.io>
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 8663DC180A93 for <acme@ietfa.amsl.com>; Mon, 16 May 2022 04:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.755
X-Spam-Level:
X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 93ogLs8GaHjT for <acme@ietfa.amsl.com>; Mon, 16 May 2022 04:47:38 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DFDC180A91 for <acme@ietf.org>; Mon, 16 May 2022 04:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bUumNNTDWu7Dh7foAtux43jKrs1njYZaqJ1wfK/0114=; b=EC8B8GE9S9zKPu4VI2S1jb4rcd ZeuORSI95npiaUlbII/BMWVXJh95qQErXLdPiG724bDtHubC6SBl9JROt4HXM2Ee78cUWdzniBTq9 thZPIVpc9G8PC8DT28LEiNGiPXt3QqurZNFkRX4pFp0woZ8oexwV6XbBs6b8mq5mV34nNl/QZAzjO MW7J3o9Z+0DkAwCYGWg2T/EKHWlPpWILdd8DwVUPHWU444rYBrqAH3mnDxNozSbDfQQUJN29key2r Ed0ouSWivMSkYoq4RW7Rs0mBvtBo8z070J0US4vxBRy+6+NTgdjOOj82gU77dATAazwy0T0sBh/yz 3JTUY2xw==;
Received: from [2a00:20:600d:9efd:b88:33c8:1bce:66fc] by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1nqZCH-00031E-VJ; Mon, 16 May 2022 13:47:34 +0200
Message-ID: <0bc0e8e6-5314-4190-88b1-31839dbc3cf9@desec.io>
Date: Mon, 16 May 2022 13:47:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: IETF ACME <acme@ietf.org>
References: <99e7080c-8bf3-86ad-65a3-05eb18992632@desec.io> <CAErg=HEzWf+j31D+ko9c0kVkdmRTY5sK8F5UwCmBM+qH=Cgnfg@mail.gmail.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <CAErg=HEzWf+j31D+ko9c0kVkdmRTY5sK8F5UwCmBM+qH=Cgnfg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/jVHZVr9F4qNldKJHMSsN-FmXSNY>
Subject: Re: [Acme] draft-ietf-acme-subdomains and public suffixes
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.34
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: Mon, 16 May 2022 11:47:42 -0000

Ryan,

On 4/7/22 20:26, Ryan Sleevi wrote:
> Given that public suffices are an unfortunate fiction invented by browsers, it'd be doubly unfortunate to codify it in an IETF doc.

FWIW, the notion is already codified in RFC 7489 (Section 3.2) and RFC 9091 (in the title, albeit experimental).

> So, in practice, a CA using this spec and conforming to the CA/Browser Forum BRs will refuse to issue such a certificate.

Great.

> However, this is a convenient fiction in separation: the DNS admin of eu.org <http://eu.org> can, at any time, remove de.eu.org <http://de.eu.org> from the public suffix list, as they are the parent authority. In that sense, they have the full technical capability to cause issuance.

Sure. However, if the relevant part of the DNS space is, at the time of certificate issuance, separated into different realms of authority (e.g., as indicated by a PSL entry), then IMO an issuance protocol that allowed skipping the corresponding check is broken.

But as you said, the "CA-side protocol" (CAB Forum BRs) already has provisions. I just didn't know whether these would also apply to the new "ACME subdomains" protocol extension; your message implies that they do.

IMO, authorization of changes to separation indicators such as the PSL is out of scope for the issuance protocol.

> The requirement of public suffix separation is _primarily_ a holdover from when every validation method was treated equally by CAs (e.g. the use of HTTP to approve a wildcard domain, without demonstrating DNS-based control). With the new separations that restrict such broadening,

Which?

~Peter

-- 
https://desec.io/

v2.23.0 | Report a Bug | By Email