Dear All,

Thank you for the discussion at IETF 117. This email intends to follow up
on some points that were brought up during the meeting last week.

Just a reminder that the main motivation behind this draft (
https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-challenge/) is
to make domain validation delegation to more than a single entity possible.
This allows DNS validation challenges to rise to the flexibility offered by
both HTTP-01 and TLS-ALPN-01 challenges. This flexibility is necessary to
make ACME adoption possible for larger integrators that already have an
established domain and are deployed in a diverse set of environments.

For this discussion let's assume that we have:

ACME Account with the KID of: https://example.com/acme/chall/i00MGYwLWIx

Domain being validated: www.example.org


Draft proposed format:

_acme-challenge_ujmmovf2vn55tgye.www.example.org

This format is easy to integrate with existing ACME clients that also
automate DNS changes. It requires minimal changes on the zone operator side
and can easily be deployed alongside DNS-01.

This format also allows this challenge to be used today. That means any CA
can adopt this challenge today (even while it is in draft form) and solve
the multi-delegated domain validation problem.


My understanding (please correct me if I've misunderstood & misinterpreted)
of the proposal in the meeting was to add the account DNS label to the left
of _acme-challenge:

ujmmovf2vn55tgye._acme-challenge.www.example.org

The benefit of this proposal is that it conforms better to how DNS
hierarchies are designed. It has a clear separation of the _acme-challenge
zone. It also might be a potential solution to
https://github.com/aaomidi/draft-ietf-acme-dns-account-challenge/issues/13#issuecomment-1376612268

The downsides of this proposal is that it would require the BRs to be
updated before this challenge can be used, and that it's more complicated
to integrate this with existing ACME clients.

>From my perspective, the proposal makes adoption of this challenge by end
users a bit more difficult without many tangible benefits.

Are there any benefits that I'm missing or other alternatives? Does the
working group have a strong feeling on either the current format or the
proposed format?

On Fri, Jun 23, 2023 at 4:27 PM Michael Richardson <[email protected]>
wrote:

>
> Amir Omidi <[email protected]> wrote:
>     > After some deliberation on this, I think we're erring on the side of
>     > DNS-ACCOUNT-01 rather than DNS-02. Speaking to a few people
> privately,
>     > there is a concern that DNS-02 implies a deprecation of DNS-01 which
> is
>     > not the intention of this draft. This unintentional implication may
> be
>     > detrimental to the adoption of ACME.
>
> Wise.
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to