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
