Hi Richard, Yes, the registries of field names would address our needs.
Can you clarify what you mean by: "… the only requirement to add something to the registry is that there be a specification for it somewhere"? What does "somewhere" refer to in this context? Ray From: Richard Barnes [mailto:[email protected]] Sent: Friday, November 18, 2016 8:09 PM To: Ray Cheng <[email protected]> Cc: [email protected]; Jacob Hoffman-Andrews <[email protected]> Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
