Re: [Acme] Comments on draft-ietf-acme-acme-01

Jacob Hoffman-Andrews <jsha@eff.org> Thu, 04 February 2016 19:33 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 368B71ACE24 for <acme@ietfa.amsl.com>; Thu, 4 Feb 2016 11:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DtYBbh82mQ3Q for <acme@ietfa.amsl.com>; Thu, 4 Feb 2016 11:33:54 -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 55B411ACE2B for <acme@ietf.org>; Thu, 4 Feb 2016 11:33:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ZMDaXgJvzzs+wVOAQtWp9pgbU9Cpt/bjK+oBe7F1WKE=; b=AAAaRWK8G9nhOXAyLsxvyr4LiGqVZLEKG6ekfk1zBs7ttCwc7oblybaHJVeO+dJ1lTyH9bihL3boqEuqw1cSmiwvGZ0f0HcnGq9VAqXBkqHbPtG7a5tgzylmkCFwBsjRnoIpPFx3EUiKmtN85XROSHiYN2ep8JBjhPfHenHBxXM=;
Received: ; Thu, 04 Feb 2016 11:33:53 -0800
To: Phillip Hallam-Baker <phill@hallambaker.com>, Martin Thomson <martin.thomson@gmail.com>
References: <CAMm+LwjnngkD7GTz3z3u4tjnuzDL+WGpHcpjohCxmZLoPGFuJA@mail.gmail.com> <CABkgnnXyn1nA=HNh8whskQ5No7VC9nk_2g-Xc8_rW1AggWCxAA@mail.gmail.com> <CAMm+LwgTjWS-W+XUyjVMR3hwWDtzUVj0uTL46xGRtoV58yPftg@mail.gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <56B3A7A1.8010900@eff.org>
Date: Thu, 4 Feb 2016 11:33:53 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAMm+LwgTjWS-W+XUyjVMR3hwWDtzUVj0uTL46xGRtoV58yPftg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/0VEPiGwo6ksWBrmAxi4AX19JgxA>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Comments on draft-ietf-acme-acme-01
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 04 Feb 2016 19:33:56 -0000

On 02/03/2016 11:55 AM, Phillip Hallam-Baker wrote:
> The reason I would like to have consistency across JSON/HTTP type
> services is that we are going to hit a requirement for 'service
> management' type functions at some point. Things like negotiating
> protocol version, features, declaring end of service, transfer to
> another, scheduled outages, that sort of thing.
>
> That is a module that I would hope we could define once and then
> incorporate by reference in many Web Services.
>
>
> The syntax of the request is currently:
>
> {
>   "resource": "new-reg",
>   "contact": [ "mailto:cert-admin@example.com", ..]
>   }
>
> Now that has all the information we want but there is no guarantee
> "resource" is going to be emitted first in the serialization. That
> could be a problem if you are dealing with abuse cases like very long
> messages.
>
> As a structural matter, I prefer to guarantee that the description of
> the object precedes the object. So I prefer to describe 'new-reg'
> object like so:
>
> {
>   "new-reg" : {
>     "contact": [ "mailto:cert-admin@example.com", ..]
>     }
>   }
I strongly support this. In implementing Boulder for Let's Encrypt, we
ran into a similar problem with challenge types. Since challenges are
distinguished by a "type" field within the JSON itself, we wind up
representing all challenge types as a single super-type that encompasses
all their fields, and then switching on the string value of the type
field. I'd definitely prefer to be able to keep the different types
separate, which is possible in a system like the one you propose.