Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

Fraser Tweedale <frase@frase.id.au> Fri, 07 July 2023 00:40 UTC

Return-Path: <frase@frase.id.au>
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 6B540C15199F for <acme@ietfa.amsl.com>; Thu, 6 Jul 2023 17:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 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] autolearn=unavailable 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 2_DgGpAxqaxt for <acme@ietfa.amsl.com>; Thu, 6 Jul 2023 17:40:09 -0700 (PDT)
Received: from smtp02.aussiebb.com.au (smtp02.aussiebb.com.au [IPv6:2403:5800:3:25::1002]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8701C15109F for <acme@ietf.org>; Thu, 6 Jul 2023 17:40:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp02.aussiebb.com.au (Postfix) with ESMTP id 5C68A100574 for <acme@ietf.org>; Fri, 7 Jul 2023 10:40:05 +1000 (AEST)
X-Virus-Scanned: Debian amavisd-new at smtp02.aussiebb.com.au
Received: from smtp02.aussiebb.com.au ([127.0.0.1]) by localhost (smtp02.aussiebb.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2HuSj69cUIO for <acme@ietf.org>; Fri, 7 Jul 2023 10:40:05 +1000 (AEST)
Received: by smtp02.aussiebb.com.au (Postfix, from userid 116) id 0B5CC10229A; Fri, 7 Jul 2023 10:40:04 +1000 (AEST)
Received: from bacardi.hollandpark.frase.id.au (unknown [100.103.3.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp02.aussiebb.com.au (Postfix) with ESMTPS id 6F3FA100840; Fri, 7 Jul 2023 10:40:03 +1000 (AEST)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.17.1/8.17.1) with ESMTPS id 3670e2fp008602 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 7 Jul 2023 10:40:02 +1000 (AEST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.17.1/8.17.1/Submit) id 3670e24u008601; Fri, 7 Jul 2023 10:40:02 +1000 (AEST) (envelope-from frase@frase.id.au)
Date: Fri, 07 Jul 2023 10:40:02 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Paul van Brouwershaven <Paul.vanBrouwershaven=40entrust.com@dmarc.ietf.org>
Cc: Richard Barnes <rlb@ipv.sx>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, "acme@ietf.org" <acme@ietf.org>
Message-ID: <ZKde4llTB-dpA3Kj@bacardi.hollandpark.frase.id.au>
References: <168865435873.61106.2850041921157081937@ietfa.amsl.com> <CH0PR11MB5739FDB26BF675925C449AA69F2CA@CH0PR11MB5739.namprd11.prod.outlook.com> <CAL02cgSH1XM0krpYuCVP1VNpZ8EpprHog1+-oeQkN0a5bX8vHA@mail.gmail.com> <LV2PR11MB5975C3F165D41FBA2BEED912F82CA@LV2PR11MB5975.namprd11.prod.outlook.com> <ZKdW965KnS_C1P6n@bacardi.hollandpark.frase.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZKdW965KnS_C1P6n@bacardi.hollandpark.frase.id.au>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/iTyriOjEbZHotcvS_ds2F_qMz6w>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
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: Fri, 07 Jul 2023 00:40:14 -0000

On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote:
> - The main problem solved in my draft was: "in this /network
>   environment/, what ACME servers can/should I use?"  The CAA-based
>   proposal answers a different question: "for this /domain/, what
>   ACME server should I use?"  But (a) why would a domain owner need
>   to control this, and (b) it doesn't actually solve the problem
>   stated in the abstract:
> 
>   > This often leaves domain owners at the mercy of their hosting
>   > provider as to which Certification Authorities (CAs) can be used.
> 
>   The hosting provider can still control which ACME servers can be
>   reached, regardless of the preferences expressed via CAA records.
> 

With respect to (a) - never mind.  I thought about it some more and
the answer is obvious.  Where a CA authorization (i.e. restriction)
exists in the form of a CAA record, it is useful to be able to
direct a client to the authorized issuer(s) for the affected
domain(s).

I see that your draft solves a real problem.  But it does not help
much in enterprise environments, where the question is often "find
me /some/ ACME server that I can reach/use, or which the
administrators prefer".  Two different problems, two complementary
approaches.

Thanks,
Fraser