Hi Ray, Sorry for the delay in responding. First off, I want to say a big thanks for implementing ACME and making it interoperate with Certbot. That's a huge step forward for the ACME protocol, and I know the Certbot folks look forward to your contributions.
On 10/04/2016 06:11 AM, Ray Cheng wrote: > One way to accomplish this in the protocol is to simply add a "ca-extension" > object to the registration object, where the "ca-extension" object is an > array of name-value pairs of strings. For example: I think this makes a lot of sense, and is in the spirit of the other places we've intentional left hooks for CA-specific customization, like OOB challenges. I'm inclined to accept it. Additionally, your experience as a commercial implementer of ACME may be valuable to spot places where the current protocol is lacking. For instance, you need an "account" field, and StartCom needs (https://github.com/ietf-wg-acme/acme/pull/172) a "token" field. Can we support those use cases natively in ACME so they don't need to be extensions? What do you put in the "account" field, and how do you authenticate the link between the ACME account and the Entrust account. Thanks, Jacob _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
