Subject: [Acme] Phill's proposal

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Apr 2016 15:48:55 +0000

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-masked] Twitter: RichSalz

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Apr 2016 14:51:36 -0400

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-masked]> 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)
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Ron <[email-masked]>
Date: Thu, 28 Apr 2016 05:48:00 +0930

> more robust than comparison, but I'm wary of becoming *that* independent of

I'm inclined to think this should go the other way, in that what is in
the JWS is a magic octet string (and may not be a URL at all) which
doesn't need to (be) compare(d) to the request URL at all.

It just needs to confirm to the recipient that this JWS was intended
for it by the sender, regardless of how it got sent there.

ie. I don't think the ACME server should ignore either of those pieces
of information, but they don't necessarily need to be comparable to
each other.

> unless people have concrete use cases.

I think we've got enough to still bolt down for the single-CA model to
not want to add that sort of complexity to the initial protocol.

It would be possible for an ACME provider to do something like that
out of band anyway (ie. it could just document that authz is shared
between services it provides), and clients are already supporting
multiple ACME servers (for testing on the LE staging server and
issuing live certificates).

There might be some other nice things which that could enable, but I'd
want to see something compelling about how the current protocol limits
something people really want/need to do.

---

From: Niklas Keller <[email-masked]>
Date: Wed, 27 Apr 2016 20:48:24 +0000

Richard Barnes <[email-masked]> schrieb am Mi., 27. Apr. 2016 20:51:

> 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.
>

We might need something similar for multiple issuers but the same CA. This
is required for having both, RSA and ECC intermediates.

Regards, Niklas

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Apr 2016 09:11:01 +0900

> QUESTION: Should ACME support multiple CAs per ACME endpoint?

a major win in our never-ending search for complexity not justified by
'must have to get the plane off ther ground'