Re: [Acme] restification of acme

Jacob Hoffman-Andrews <jsha@eff.org> Tue, 20 January 2015 19:46 UTC

Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB31B2B01 for <acme@ietfa.amsl.com>; Tue, 20 Jan 2015 11:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLs-hcGNGVh0 for <acme@ietfa.amsl.com>; Tue, 20 Jan 2015 11:46:11 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB891ACF55 for <acme@ietf.org>; Tue, 20 Jan 2015 11:46:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9ZPIvwYVjW+nXskdbOZTPDv2nZapFVVDgyBfD14YX78=; b=0e+9UwPnUTCRWSQFAsM37k28XZYVhq0g11shpvdod9PL3HCKdSLiYaWTQwSLdVGzP+fyNWC9zBJeVWNK/dMrHqpjFagF4j4vFkCQpM4XqAMmsFYB62o/Ct1d2C+pI6wmhctHVV9aB5TmZbj5DA+8FFzu1MHlHAxfJ+Q0NxUN/eA=;
Received: ; Tue, 20 Jan 2015 11:46:10 -0800
Message-ID: <54BEB082.3040901@eff.org>
Date: Tue, 20 Jan 2015 11:46:10 -0800
From: Jacob Hoffman-Andrews <jsha@eff.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <phill@hallambaker.com>, Fraser Tweedale <frase@frase.id.au>
References: <20150120080427.GB1238@bacardi.hollandpark.frase.id.au> <CAMm+LwgKLSCSvx1QHL+HLgtc0NK8-HygpgXEF81unbcxWt6Uvw@mail.gmail.com>
In-Reply-To: <CAMm+LwgKLSCSvx1QHL+HLgtc0NK8-HygpgXEF81unbcxWt6Uvw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060600060800070409070604"
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/a8ASBdo7gJOA1TbMInfMMP759FI>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] restification of acme
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 19:46:15 -0000

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:
> 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 <frase@frase.id.au
> <mailto:frase@frase.id.au>> wrote:
>
>     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
>
>     _______________________________________________
>     Acme mailing list
>     Acme@ietf.org <mailto:Acme@ietf.org>
>     https://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme