On Mon, Jan 13, 2025 at 9:55 AM Shumon Huque <shu...@gmail.com> wrote:
> Hi Paul,
>
> Thanks for your comments.
>
> At the last DNSOP meeting in Dublin, I already made some remarks at the
> mic that the draft is in need of some cleanup and reorganization. A lot of
> the content has grown by accretion in response to various feedback and it
> is probably indeed time to do a cleanup pass.
>
> The authors had already planned to meet later this month on this topic.
> They are now also considering your specific suggestions, and will pull you
> into some of those conversations.
>
There have been a bunch of conversations about this off list, amongst the
authors, and with the chairs, Paul H, and others. I wanted to give
the working group a quick update on current status. A new revision of the
draft will be published soon, but I'll quickly summarize the planned
changes here ...
Mainly we plan to simplify the text in the document so that it is more
comprehensible to its really intended audience: application providers that
want to verify domain control, without being bogged down with too many
technical details of the DNS that they may have difficulty understanding.
In that vein,
* We will move some of the more technical esoterica into the appendix.
* Start upfront with the recommended way to do DCV:
-- describe the TXT record based DCV method, using underscored
application labels only.
-- describe the use of CNAMEs only to enable delegated DCV (where the
CNAME points to a DCV TXT record in a zone under the control of the party
being delegated to). We will remove other text about CNAME-only validation
which is a bit confusing.
-- describe support for multiple intermediaries: account specific and
provider specific challenges (with the intermediary specific label
prepended to the application specific DCV record name), as these are
already being used in the field, and the CAB forum has adopted our
recommendation in their most recent ballot for account specific challenges.
(Note that Paul H had proposed to remove the use of CNAME and of
multi-intermediary specific labels entirely, but after some back and forth,
I think I've persuaded him that these need to be retained. I can elaborate
further for others if needed).
* Remove the entire appendix that describes all the ways existing providers
are doing DCV (That was very useful in the early days when the draft was
doing a detailed survey of what was out there, but now that it's a BCP,
seems out of place, and makes the document unnecessarily long).
* Move Domain Boundaries/PSL considerations to an appendix (because it
doesn't apply to most applications).
* Remove the "Meta-data for expiry" in the DCV token, in the interests of
simplicity, and because there are other ways application
providers communicate expiration today.
* Remove the "Scope of Validation/Scope Indication" section. This was the
idea of adding -{host,wildcard,domain}-challenge strings into the DCV
token. We still think this is a good idea, but are contemplating putting
this proposal in another draft that we take to ACME and work out the
details there.
Shumon.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
