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

Peter Thomassen <peter@desec.io> Thu, 07 April 2022 14:36 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 C339B3A003F for <acme@ietfa.amsl.com>; Thu, 7 Apr 2022 07:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DvccsS9q7jh for <acme@ietfa.amsl.com>; Thu, 7 Apr 2022 07:36:27 -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 EC5803A003D for <acme@ietf.org>; Thu, 7 Apr 2022 07:36:26 -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:Subject:From:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ak8XU0ImTtvF4/l1gG2h9grO+7/BP4kFeA3z48XYJR0=; b=xiKPG09dPpnWkKjPyXrjRbaOIJ yxZH28hvdvFj0bfNkUgiTGApePuNjCKegq9RRBUhMZCwiepuDhA4k6l0KJnEHVoONa4RI3BaH2+NB HjgkcPRE6FDEpnDIGGeVrdoNV65LI1kKteWnWqs2WjtU68ZKoCr4lnWYxxD9SksqDG4Y3X5esSAxe gKvDbDgftHfpMwgND2VtcHwkU3hca+g964DQiTCP/Df3mnxEZfMRcQ41EqdahmQzGU9yHZyNa7mCz QANeGZWswxtAC0KZvZnGOTsqfIBTVULXlH0WW5LIjHiBgCLpttAmM42xsWIEDwZ7mGSfNcl+YIKhl 7NNvSk4w==;
Received: from ip5f5aec85.dynamic.kabel-deutschland.de ([95.90.236.133] helo=[192.168.1.171]) 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 1ncTFH-0004hL-W2; Thu, 07 Apr 2022 16:36:24 +0200
Message-ID: <99e7080c-8bf3-86ad-65a3-05eb18992632@desec.io>
Date: Thu, 07 Apr 2022 16:36:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
To: acme@ietf.org
Content-Language: en-US
From: Peter Thomassen <peter@desec.io>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/86vFAJmNJtapb2FWJW7BxumKwzM>
Subject: [Acme] draft-ietf-acme-subdomains and public suffixes
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 07 Apr 2022 14:36:32 -0000

Hi,

Perhaps the following has been discussed before (although I wasn't able to find it, then); in that case, please let me know, and we can close the thread.

I read the draft and think it is a good idea and well done.

However, I was wondering: What if there is a public suffix between the subdomain for which a certificate is requested, and the parent domain used for validation?

Let's work through an example. You may be familiar with the (non-official) eu.org registry, which runs several public suffixes under which one can register domain names. These public suffixes appear on the public suffix list (e.g. de.eu.org).

Now, should it be possible for the DNS admin of eu.org to request a certificate for example.de.eu.org (or subdomains thereof) through the mechanism described in the draft, although there is a public suffix in between? (I don't think so.)

If this should be prevented, the corresponding public suffix check needs to be mandatory. (However, I'm not sure if it needs to be in this draft, or in the CA/B guidelines.)

What do you think?

Thanks,
Peter

-- 
https://desec.io/