Aaron Gable <[email protected]> wrote: > That said, it is not clear to me that this draft enables truly novel > behavior. I believe that the desired result -- authorization for a single > parent domain, but issuance only for specific subdomains -- is possible > using current mechanisms: > 1) Create a NewOrder for *.example.com > 2) Complete the necessary challenge to prove control over example.com > 3) Don't bother finalizing the order > 4) Create a NewOrder for foo.example.com > 5) The ACME Server notices the wildcard authorization for example.com, > attaches that to the new order, and sets the order's state to "valid"
This seems to make the ACME server keep a bunch of state itself (across
multiple HTTPS/TLS connections), while I suspect that most of us would like
the client to be responsible for keeping that authorization around.
Would you agree with this?
> I freely admit that I am less familiar with the RFC process than many
here,
> so the following proposal may be completely infeasible. But would it be
> possible for this draft to effectively become "let's extend newAuthz
> requests with a wildcard field"? Then the pre-authorization flow outlined
> in the current draft could be used rather than the hack "create but don't
> finalize an order" flow I outlined above. Or would the act of
contradicting
> 8555's restrictions on the wildcard field be too big of an issue?
I think that this is reasonable to me, but I've much less knowledge of the
underlying structures than you :-)
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
