So to be blunt: You're saying that some of what we want could be achieved by hacks within the existing model, rather than getting all of what we want by changing the model :)
I really think it's cleaner at this point to change the model. There's not that much deployed code yet, so we should go ahead and get things right. --Richard On Thu, Jul 7, 2016 at 6:21 PM, Brad Warren <[email protected]> wrote: > I think there's a possibility we could implement a lot of the desired > functionality without preconditions or changing the reg-authz-cert flow. > The main benefits initially mentioned for preconditions were payments, > wildcards, and CA issuance flows. > > To implement payments, it seems like we could use a generic out of band > challenge type. I agree that this needs to be more fleshed out. > > For wildcards, we could build off of Ron's suggestion to allow clients > to include a wildcard domain in the authorization request. If we did > this, however, we'd probably want to modify the HTTP/DNS challenges to > allow the server to specify the exact domain where the client has to > complete the challenge. > > For example, if the client requests an authorization for *.example.org, > the ACME server could say that the client needs to complete HTTP > challenges for a.example.org, b.example.org, and c.example.org. > > Changes like those described above would still allow CAs to differ based > on what the client needs to do to be authorized for an identifier. The > big downside to this approach is it only allows that flexibility based > on the domain the client requested. If a CA wants to have different > preconditions based on values in the CSR other than the domains, this > won't work. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
