Subject: [Acme] restification of acme

From: Fraser Tweedale <[email-masked]>
Date: Tue, 20 Jan 2015 18:04:28 +1000

Hi all,

After looking at the boulder server and the node-acme 'restify'
branch, and some discussion on #letsencrypt, I am led to believe
that work to make ACME a REST-flavoured protocol is underway.

If this is the case, I have some questions/comments:

- When will we see an updated version of the spec (be it in a branch
  or otherwise?)

- The Retry-After header can be used with response status 503
  Service Unavailable and MAY be used with any 3xx response.  The
  use of the Retry-After header in the restify branch seems to be in
  violation of RFC 2616.

- I'm not sure that REST is a good semantics for ACME (what does
  revocation look like, for example?).  What was the motivation for
  switching to a REST-esque API?

Regards,

Fraser

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Jan 2015 10:39:10 -0500

Please, can we not use buzzwords?

I have known Roy Fielding for 20 years and I read his original paper. I
have absolutely no idea what someone means when they talk about REST and
most times they mean 'perform some horrid kludge'.

We are doing a JSON protocol here. That means

All the request info in a JSON syntax request.
All the response info in a JSON syntax response.

Use of HTTP response codes results in flaky implementations because
intermediaries can meddle with them. You might want to give response codes
in both places but the canonical response code should be in JSON.

HTTP does not add any value here other than providing

1) A mechanism for distinguishing multiple services on the same host
2) Firewall bypass
3) Providing a logical place to put a signature header

HTTP was designed to support idempotent operations. ACME operations are not
idempotent so you are not going to get any benefit from HTTP caching.

I have seen people try to make use of the URI line to encode a request and
the results are ridiculous and useless. You lose the ability to have
structured data for a start. And you don't get caching even for static
lookups unless you canonicalize the URI.

If we were going to spend time 'RESTifying' the spec then there should be a
description of what REST is published as an RFC and agreed by the IAB that
we are working from. Otherwise we just end up chasing buzzwords without
gaining any consistency.

On Tue, Jan 20, 2015 at 3:04 AM, Fraser Tweedale <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 20 Jan 2015 11:46:10 -0800

For reference, here is the pull request for changing the spec to use
REST concepts: https://github.com/letsencrypt/acme-spec/pull/48

I've raised a few of these issues there, in particular idempotence.

On 01/20/2015 07:39 AM, Phillip Hallam-Baker wrote:
> I have known Roy Fielding for 20 years and I read his original paper.
> I have absolutely no idea what someone means when they talk about REST
> and most times they mean 'perform some horrid kludge'. 
>
> intermediaries can meddle with them. You might want to give response
> codes in both places but the canonical response code should be in JSON.
>
> HTTP was designed to support idempotent operations. ACME operations
> are not idempotent so you are not going to get any benefit from HTTP
> caching.
>
>
> I have seen people try to make use of the URI line to encode a request
> and the results are ridiculous and useless. You lose the ability to
> have structured data for a start. And you don't get caching even for
> static lookups unless you canonicalize the URI.
>
>
> If we were going to spend time 'RESTifying' the spec then there should
> be a description of what REST is published as an RFC and agreed by the
> IAB that we are working from. Otherwise we just end up chasing
> buzzwords without gaining any consistency.
>
>
> On Tue, Jan 20, 2015 at 3:04 AM, Fraser Tweedale <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 21 Jan 2015 09:01:52 +0100

I'm not going to comment on the conversion of ACME into a REST-based design, I just find
it amusing/interesting/odd that I in my [sort of] "ACME for mobile devices", SKS/KeyGen2,
came up with essentially the diametrically opposed solution like:

- HTTP POST to the same URL using HTTP 200 as the sole response code
- Uniquely identifiable JSON message classes
- Clear-text JSON signatures
- Key attestations rather than PKCS #10/PoP

Message classes are registered and then automatically instantiated in one place and
after that dispatched to the appropriate handler which also provides the return object.

This is like an extremely scaled-down version of the thing that made people turn to REST,
the bloated and ugly beast known as WS-*.

Anders