Hey Ray, We discussed this at the F2F meeting at IETF 97 last week. The conclusion there was that we're not going to create a special zone for CA extensions, but rather just let CAs extend the relevant object directly.
The major risk here is collision -- if two CAs extend an object using the same field name with different semantics. To help avoid that, I've posted a PR that creates registries of field names; the only requirement to add something to the registry is that there be a specification for it somewhere. https://github.com/ietf-wg-acme/acme/pull/211 Does that sound OK to you? Let me know if you have any comments on the PR. --Richard On Tue, Nov 1, 2016 at 12:43 AM, Ray Cheng <ray.ch...@entrustdatacard.com> wrote: > 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
