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

Carl Wallace <carl@redhoundsoftware.com> Wed, 12 July 2023 20:03 UTC

Return-Path: <carl@redhoundsoftware.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 02FD9C151066 for <acme@ietfa.amsl.com>; Wed, 12 Jul 2023 13:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 i2M1roqIZSMb for <acme@ietfa.amsl.com>; Wed, 12 Jul 2023 13:03:00 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 415E1C14CE2B for <acme@ietf.org>; Wed, 12 Jul 2023 13:03:00 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3a3df1ee4a3so3841265b6e.3 for <acme@ietf.org>; Wed, 12 Jul 2023 13:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; t=1689192179; x=1691784179; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:from:to:cc:subject:date:message-id:reply-to; bh=rjD6zoV2CZjAfxqCjdE947HSAj7uIHMqSSjL71dVcWQ=; b=HdaVCsbIbKci5X6g1hSpvUV/yRiXDpCbB1vMiFQJdTgk+g82mGt6fscEBPLa00mOBO 10j4ov8JhTJQp2cUNBJcA+lVGm3Lct2Gd2hS86CP472C4OrXKg2LVAeY/ybeMPC3khr9 yU4PjXzYVm2kTZ4H6eL0xG8V5AAGOq/nNoxG0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689192179; x=1691784179; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rjD6zoV2CZjAfxqCjdE947HSAj7uIHMqSSjL71dVcWQ=; b=cqAuCcar/oWGw87wQb7tA3wr5PWTq/fYFmgboefgEYPSJ7BqmNLWJ623vR/qxm3Xyt Fq0bdiSZjTf40rZJen66eAaN0ej/QaxyGn6umKxRezt1Bk4fXIJ15XzHYYcoZV2kTPBk LJAxRFMymVM5FTyshR/oI93mTXzUncKQTMRqODnhuCkaOjmUxB3A5vydHL2lbXh5dTtO OxPZPEO6jcOsd/XeswMhy5BLqXNtH+wsc5vRrlFBZixXaYjOt1UOiR8H+mqp6sZxAFo4 uFRo/s/uO9H5NkOC2+UD+1Dh+4bHl7RIHeHI7C22M3PfC3czY22lT76b+NCzbm/60F4F qm9A==
X-Gm-Message-State: ABy/qLbf+zwLoWT8uraFQ9BNR/L4M0EjmqHIf5fE8a8Oa/hR9evS/6g5 L3OBAvGV8tK6CfTMa4JWQnptcQ==
X-Google-Smtp-Source: APBJJlE4PAyv4xSI/wcjmHRafoiD+63tm8PE9OH6oPjw/atpwTtdF3qYPTXsXN9lGQDVA/6pNTH4Qg==
X-Received: by 2002:a05:6808:ecf:b0:3a1:dc0d:f31f with SMTP id q15-20020a0568080ecf00b003a1dc0df31fmr19416935oiv.3.1689192178920; Wed, 12 Jul 2023 13:02:58 -0700 (PDT)
Received: from [192.168.2.16] (pool-96-255-232-167.washdc.fios.verizon.net. [96.255.232.167]) by smtp.gmail.com with ESMTPSA id u1-20020ac80501000000b003f6c9f8f0a8sm2469545qtg.68.2023.07.12.13.02.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2023 13:02:58 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.75.23070901
Date: Wed, 12 Jul 2023 16:02:57 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, "acme@ietf.org" <acme@ietf.org>
Message-ID: <0BE16C61-3091-4CB1-B2BD-911D43499A36@redhoundsoftware.com>
Thread-Topic: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
References: <BB39F277-C855-4BE2-9E1D-F0792F87C7D0@redhoundsoftware.com> <LV2PR11MB5975A1AF940F81E6F3CB7B97F836A@LV2PR11MB5975.namprd11.prod.outlook.com> <LV2PR11MB59751210E50ADE0F9EA69549F836A@LV2PR11MB5975.namprd11.prod.outlook.com>
In-Reply-To: <LV2PR11MB59751210E50ADE0F9EA69549F836A@LV2PR11MB5975.namprd11.prod.outlook.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3772022578_2708221453"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/VIRQ_0DXL66e3J4LCrgx7WW5mJY>
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: Wed, 12 Jul 2023 20:03:04 -0000

The example is good, but it doesn’t quite get at the issue. I think the problematic text is “if no common CA is found.” In the example, there is a common CA, there are just different priorities. It does help clarify the “as few domains” part though. Maybe something like “if all domains do not prefer the same CA, the ACME client tries…” would be more clear.

 

From: Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
Date: Wednesday, July 12, 2023 at 2:30 PM
To: Carl Wallace <carl@redhoundsoftware.com>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

 

>> - In 5.1, what does 3.b mean? Can you add an example?
> I will try to add an example here.

 

Does this example help to clarify the intend of 3.b?

https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-selecting-a-common-ca-throu

 

The other changes have also been incorporated.

 

From: Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
Sent: Wednesday, July 12, 2023 18:16
To: Carl Wallace <carl@redhoundsoftware.com>; Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; acme@ietf.org <acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt 

 

Thanks for your detailed review!

- Why is the draft informational and not standards track?

Most people I spoke to, while discussing the idea, thought that it would need to be information, but if people here feel that this needs to be changed to standards track, I'm fine with that too. I'm relatively new to the drafting process.

- Why does absence turn the feature on? Wouldn't this invite sending spurious requests for ACME information to CAs configured before this draft existed that do not support ACME?

The reason is that with the move to shorter live certificates, automation will become essential. If we default to off, we will likely only see CAA records with this option enabled.



The benefit of these spurious requests is that it would give a clear signal to these CAs that they might need to adopt ACME and/or auto discovery, something that is also pushed by the root programs.



If an account binding is required (which is the case for most commercial CAs) the user will be asked to establish this binding, but no certificates will be issued until the account binding is established. When no account binding is required, the certificate will automatically be replaced by the authorized CA.



See also the security considerations in section 8.1.

- Is a boolean the right type for discovery or should it be a string that indicates the protocol that is the target of auto-discovery?

The protocol is already indicated by the property (i.e., issue, issuewild, vmc, issuemail, etc.)

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth a few words since the usage here is different.

Yes they do, section 5 states "The ACME client initiates a DNS lookup to retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA lookups need to be performed.

- In the next to last example in 3.2, why does EV without priority go first?

It should not, we updated the logic later, I will get this corrected by including a priority here as well.

- In 5.1, you might want to replace the long paragraph with bullets.

This is fixed on GitHub and will be included in the next release.

- In 5.1, what does 3.b mean? Can you add an example?

I will try to add an example here.

- You should expand QWAC on first use and maybe add an informational reference.

Yes, I will add the meaning of the abbreviations and maybe a reference there.



Thanks,



Paul



From: Carl Wallace <carl@redhoundsoftware.com>
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; acme@ietf.org <acme@ietf.org>
Cc: Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt 

 

This looks like a useful addition. Here are a few comments and questions:

- Why is the draft informational and not standards track?

- Why does absence turn the feature on? Wouldn't this invite sending spurious requests for ACME information to CAs configured before this draft existed that do not support ACME? 

- Is a boolean the right type for discovery or should it be a string that indicates the protocol that is the target of auto-discovery?

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth a few words since the usage here is different.

- In the next to last example in 3.2, why does EV without priority go first?

- In 5.1, you might want to replace the long paragraph with bullets. 

- In 5.1, what does 3.b mean? Can you add an example?

- You should expand QWAC on first use and maybe add an informational reference. 


On 7/6/23, 10:54 AM, "Acme on behalf of Mike Ounsworth" <acme-bounces@ietf.org <mailto:acme-bounces@ietf.org> on behalf of Mike.Ounsworth=40entrust.com@dmarc.ietf.org <mailto:40entrust.com@dmarc.ietf.org>> wrote:


Hi ACME!


This is new business that we would like to add to the agenda for 117.


Thanks,
---
Mike Ounsworth & Paul van Brouwershaven


-----Original Message-----
From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth <Mike.Ounsworth@entrust.com <mailto:Mike.Ounsworth@entrust.com>>; Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com <mailto:Paul.vanBrouwershaven@entrust.com>>
Subject: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt


WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.


______________________________________________________________________


A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
has been successfully submitted by Paul van Brouwershaven and posted to the IETF repository.


Name: draft-vanbrouwershaven-acme-auto-discovery
Revision: 00
Title: Auto-discovery mechanism for ACME client configuration
Document date: 2023-07-06
Group: Individual Submission
Pages: 16
URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_TyALA0c$  <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_TyALA0c$ >
Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_ZJirVYA$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_ZJirVYA$ >
Html: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_TfosM1M$  <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_TfosM1M$ >
Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_WIL7M14$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_WIL7M14$ >




Abstract:
A significant impediment to the widespread adoption of the Automated
Certificate Management Environment (ACME) [RFC8555] is that ACME
clients need to be pre-configured with the URL of the ACME server to
be used. This often leaves domain owners at the mercy of their
hosting provider as to which Certification Authorities (CAs) can be
used. This specification provides a mechanism to bootstrap ACME
client configuration from a domain's DNS CAA Resource Record
[RFC8659], thus giving control of which CA(s) to use back to the
domain owner.


Specifically, this document specifies two new extensions to the DNS
CAA Resource Record: the "discovery" and "priority" parameters.
Additionally, it registers the URI "/.well-known/acme" at which all
compliant ACME servers will host their ACME directory object. By
retrieving instructions for the ACME client from the authorized
CA(s), this mechanism allows for the domain owner to configure
multiple CAs in either load-balanced or fallback prioritizations
which improves user preferences and increases diversity in
certificate issuers.








The IETF Secretariat




Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_F-p648Y$  <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!a4X0nrc1_QemkMo4Rt42Ki79RTnygcbMk0rum9pgO9MatIOC543E09zHtIByD45cb1tDPUXikl8nTN2z2czGowi_F-p648Y$ >