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= 40letsencrypt....@dmarc.ietf.org> wrote: > On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi <amir= > 40aaomidi....@dmarc.ietf.org> 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
