Ryan, I'm not really following this conversation. Probably my mental model of dns-01 challenges is lacking. The word "window" does not appear in RFC8555 or acme-subdomains, so that's your word, I think.
Ryan Sleevi <ryan-i...@sleevi.com> wrote:
> Further, if we assume that say there are ten domain labels, but the server
> is only willing to maintain state for five (as a window), then it’s not
> clear how the client can request the server sends the first five rather
> than the last five. Having the client advertise its capabilities let’s the
> client choose the window, and if the server rejects all of them, the
client
> at least can try again with a different window (e.g. the last five
> labels).
I don't really understand this at all.
I think that we are discussing so.me.comp.lex.example.
The client has control over lex.example, but and can prove it with dns-01 TXT
record placed at _acme-challenge.lex.example. Why does it matter whether it
is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
or an.other.comp.lex.example??
One thing that just occured to me is whether or not there is any value in the
dns-01 challenge remaining in the DNS after the authorization.
What I'm thinking is that the CA could offload some of it's state for the
client to store for it.
> That’s why my slight preference was to have the client advertise.
> Processing after validation seemed preferable to processing prior to
> validation, and it also seemed useful to let the client advertise
> capabilities directly to let the server reduce any stored state.
> However, I
> can equally imagine an asinine implementation of client-advertise that
> requests a cert for “www.example.com” but let’s the client set the ADN as
“
> example.net” and, post-validation of example.net, fails to check that “
> example.net” matches “example.com”. Or does something equally silly like
> allowing “prefix.example” to authorize “not-actually-a-prefix.example”.
I can't see how any of these things are anything other than serious bugs.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
