IETF Logo Mail Archive

Re: [DNSOP] [Ext] Call for Adoption: Survey of Domain Verification Techniques using DNS

Paul Hoffman <paul.hoffman@icann.org> Tue, 12 July 2022 22:04 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1DDC15948B for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2022 15:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 a6cmYaFJ0PTq for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2022 15:04:31 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 A857FC159488 for <dnsop@ietf.org>; Tue, 12 Jul 2022 15:04:31 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.17.1.5/8.17.1.5) with ESMTPS id 26CM4TgZ025547 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Tue, 12 Jul 2022 22:04:30 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.26; Tue, 12 Jul 2022 15:04:28 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0986.026; Tue, 12 Jul 2022 15:04:28 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS
Thread-Index: AQHYljtbOfiCe4dceUCW6OOQb521hQ==
Date: Tue, 12 Jul 2022 22:04:28 +0000
Message-ID: <45A36F57-E4F7-4A0B-AA5A-E309A81CAC86@icann.org>
References: <CADyWQ+FD9J-Wqr8rkgSMnb4+x9CRRKm=6cm6LBsw4F161QC4bg@mail.gmail.com> <9386a34e-6b43-4de8-ed19-76dccfcd707f@nthpermutation.com> <34419ad3-e70e-4481-c06f-a92f0b028902@iecc.com> <4aea6458-d003-f719-2ea6-f464b2cc1bf9@gmail.com>
In-Reply-To: <4aea6458-d003-f719-2ea6-f464b2cc1bf9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_6F057C75-5BDB-46DD-BDA4-3E961A391FDD"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-12_12,2022-07-12_01,2022-06-22_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YuYRZcnla1bvsOlgdFafUQF4Opo>
Subject: Re: [DNSOP] [Ext] Call for Adoption: Survey of Domain Verification Techniques using DNS
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 22:04:32 -0000

On Jul 12, 2022, at 2:16 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
> 
>> I agree that the list of implementations should be deleted or summarized in an appendix.
> 
> Well, maybe.  The "Let's Encrypt" example is actually part of the
> acme spec (RFC 8555) and is an IETF product.

It is definitely worth keeping the pointer to the ACME spec without naming Let's Encrypt. That organization might choose to do something different in the future, and it would confuse a reader who found this RFC if it said "Let's Encrypt does this" when they don't.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email