Hi Jacob, From: Jacob Hoffman-Andrews, Thursday, October 27, 2016 5:28 PM: > > 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. >
We are effectively using "ca-account-id" and "ca-account-secret" fields to authenticate the link to the Entrust account. Since these fields do not currently exist in draft-03 and certbot, we are embedding them in the URL that a particular customer uses to access our ACME server. The "external_secret"/"token" is slightly different but is also useful as an "API key" type of authentication. Although we see value in a "ca-extension" object, we also support adding explicit fields in ACME. There are some advantages to explicit fields - one in particular is the special handling of designated secret fields by clients. Thanks for your feedback. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
