On Mon, Nov 21, 2016 at 2:52 PM, Ray Cheng <[email protected]> wrote:
> 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? > The current PR defines the registries as "specification required", as defined here: https://tools.ietf.org/html/rfc5226#section-4.1 """ Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. """ > > > 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]> > 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] > https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
