I don’t recall much discussion on your summary. Some support to NOT support multiple CA’s and some inconclusive discussion about the HTTP URL vs the URL in the JSON.
Does anyone else have feedback? Are we ready for a consensus call? -- Senior Architect, Akamai Technologies IM: [email protected] Twitter: RichSalz From: Richard Barnes [mailto:[email protected]] Sent: Wednesday, April 27, 2016 2:52 PM To: Salz, Rich Cc: [email protected] Subject: Re: [Acme] Phill's proposal 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_issues_121&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7Ivqc6yDsnAYEpfBkqGSPR3qPoe4qgsuduBVK_khDMw&s=uA7rII4BZV9P66lztHHo_c5nRvRejM_gAoGtlX24lSE&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_issues_112&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7Ivqc6yDsnAYEpfBkqGSPR3qPoe4qgsuduBVK_khDMw&s=tVIoLeBTCo6xoTCBzc1AR-OZmilK00EFIoZZ5TluVCw&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Dacme-2D1.pdf&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7Ivqc6yDsnAYEpfBkqGSPR3qPoe4qgsuduBVK_khDMw&s=lhVcX2yt4f2tUMo_AmsWHKBugXYvXz8IHxii8QZzIs4&e=> On Wed, Apr 27, 2016 at 11:48 AM, Salz, Rich <[email protected]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darchive_web_acme_current_msg01035.html&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7Ivqc6yDsnAYEpfBkqGSPR3qPoe4qgsuduBVK_khDMw&s=4HE4EAfAS7DYSsFlcu2YMlKxkfdmGfsTM6tLpQzZhFM&e=> 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]<mailto:[email protected]> Twitter: RichSalz _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7Ivqc6yDsnAYEpfBkqGSPR3qPoe4qgsuduBVK_khDMw&s=T4Qk-8j4R1uZDZItoEKf6ZA8KxEQQxH9kSao6efBFWg&e=>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
