Re: [Acme] scope in dns-account-01 and dns-02 challenge

[Amir Omidi <[e-mail]>]

Accidentally sent this as a private reply earlier.

First, I don't want the BR process to drive the IETF process. I've been
mostly avoiding really thinking about the BRs with this draft. Especially
since participation here feels a lot simpler and democratic than it does at
CA/B.

Regarding my resistance in adding these as two or three separate
challenges: I've felt that the challenge types have become "headline"
names, while the implementation of the challenges are not something most
people care about.

I'm mainly trying to meet the end users where they are. I feel like
dns-account-01 is already going to be pretty confusing. Now making that
have a bit more of the implementation details in the "headline labels"
seems like it's going to confuse folks more.

This is where I think your experience with the Let's Encrypt community
forum can help. Do you feel like my worry here is warranted?

Beyond that, I also partially disagree with:

> but I think there is less need for domain-scoped validations in ACME.

I'm probably pretty much in agreement with you there, but I feel like now
that RFC9444 is a published RFC, it wouldn't make much sense to not build
support for that, where it makes sense, in new challenges. I doubt I'd
personally use that challenge much, and this is where I think the ACME WG
might have more opinions on keeping or discarding the `domain` scope. It
would be a shame if ACME CAs started using the `domain` scope, and didn't
have the functionality for that built into this scoped based challenge.

As for not introducing dns-02, I *could* see a future where the scoped
based challenges become a requirement. I don't think we're even close to
that yet though. In that future, the account URI based ones might be really
annoying to deal with. I also think they'd be annoying to deal with from an
external debug-ability perspective (e.g, someone posts a request on the LE
community forum of "why this not working", and now someone helping them
can't run a simple TXT lookup to answer their question.)

I should really say though, with most of this I don't have a strong
opinion. I'm mostly approaching this from the perspective of a user who
doesn't really know ACME, is already overwhelmed by this entire process,
and just wants to get a certificate to work and be able to answer questions
when their manager asks them "so what is the deal with these certificate
challenges? Which one are we going to use and why?"



On Thu, Mar 21, 2024 at 2:42 PM Jacob Hoffman-Andrews <jsha=
[e-mail]> wrote:

> On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi <amir=
> [e-mail]> wrote:
>
>> I feel like splitting this challenge into three (and potentially more, as
>> extra scopes may or may not be added into the future) might be a little too
>> noisy.
>>
>
> Combined with my other proposals, we only wind up with two total challenge
> types: `dns-account-host-01` and `dns-account-wildcard-01`. I propose to
> get rid of domain scopes and the `dns-02` challenge type.
>
> What do you think about a `scope` field in the authorization resource the
>> server sends creates/communicates with the client? Clients opting into
>> dns02, or dns-account-01 will use this to know exactly what scope the
>> server is expecting from them for their ACME order.
>>
>
> This works, and is closest to your intention with the current draft, where
> the server decides the appropriate scope and the client has to abide by it.
> I do think it will be more annoying to pull into the BRs, since they will
> have to have language that says "This challenge type may be used to issue
> for wildcard domains if the ACME server sent `"scope": "wildcard"`."
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>