Taking a look back at Phil's email, and his slides from B-A [1], I see a few things worth keeping, a couple of questions, and one thing we should drop.
KEEP: Clearer description of what's signed. No-brainer. Filed https://github.com/ietf-wg-acme/acme/issues/121 KEEP: Full resource URL within the signed object. I agree that it's useful to be more independent of HTTP in this way. And of course, we already need this to address the issues Karthik raised. I think this falls under https://github.com/ietf-wg-acme/acme/issues/112 QUESTION: Should we suggest that an ACME server MAY ignore the HTTP request URL, and instead use the URL provided in the JWS? That could be a little more robust than comparison, but I'm wary of becoming *that* independent of the HTTP layer. QUESTION: Should ACME support multiple CAs per ACME endpoint? Right now, there's an implicit assumption that each ACME server represents a single CA. If we were to open this up, we'll have to consider how we do it. For example, you could have multiple new-cert URIs for different issuers, but then you would probably want them to share policy state (i.e., have a common view of authorizations). It seems like there's a complexity tarpit here, so I'm inclined to skip it and go with the current single-CA model unless people have concrete use cases. DROP: More nesting in JSON objects, i.e., moving from { "type": "FOO"... } to { "FOO": { ... } }. The additional nesting doesn't add anything, and it would map poorly to a bunch of existing JSON bindings (e.g., challenge.token vs. challenge["http-01"].token). There's not reason to distinguish "type" in this way -- why not use "token"? Of the many JSON APIs I've looked at, none of them follow this pattern. --Richard [1] https://www.ietf.org/proceedings/95/slides/slides-95-acme-1.pdf On Wed, Apr 27, 2016 at 11:48 AM, Salz, Rich <[email protected]> wrote: > Is there any other feedback from what Phil proposed? (Start here > http://www.ietf.org/mail-archive/web/acme/current/msg01035.html even > though we’re still waiting for his promised PR, which he reasonably says he > wants to know if the WG is interested in his moving forward) > > > > As an individual, I kinda like the JSON changes. > > > > /r$ > > > > -- > > Senior Architect, Akamai Technologies > > IM: [email protected] Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
