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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 03 February 2016 20:48 UTC

Return-Path: <hallam@gmail.com>
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 8E17A1B2CA5 for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 12:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 F8xmXV2AeFwr for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 12:48:56 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CE71B2C9B for <acme@ietf.org>; Wed, 3 Feb 2016 12:48:56 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id j78so22741000lfb.1 for <acme@ietf.org>; Wed, 03 Feb 2016 12:48:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c+47KLqK5sQDtDJOoYE5eclqrZo2KAb5wlKvrjMDDxE=; b=L6pJmldMws9uX+gBkhsJ8KmsnNQV0YhT7+bKzgj1uUFQEvTHKR9U5aA9CrcCMG0kYg unEi5/ETOiMtlbD+SgsSXc236XpOGdowLoVgNOnLisBU57hqLIhfygWffhSMSPu8lnqv FDhlO+iGP2qvX+iJzplDB3hE23LqiA/S0tYN7Xl/K1DAX6zsD2k6fDcxQiygtyCihGNs ihnK8TVNE3iQECrG2pxMUjxelwgrcKAIv3GIols2S0ti42NoIinFn00rOdQtCLj6Fa1z o091JKDC0DgCfQhmuke3QnxrDXa66cWQ7C88fUF12kqemyFVbucHyMagB3FCYzSlh48i SmEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c+47KLqK5sQDtDJOoYE5eclqrZo2KAb5wlKvrjMDDxE=; b=d9mrROVKscuFc8S4Xgj3NoPkt7n6GvyWYS5R7kE8ADk6TKFJkiLYXb4XW+6Oj8ADxX 22KdEJX92KuzIHCRzvIGdSngs+KuY5qTC5sp1Jho1rguqA6oPbAnetKOcgRTkC+v42wk smioAn3hCpflFXm9cB0S1RVP4zPpwPjKxLDc6axDqrkt3kmEZOFb4GqDeDvR8d8Rs1sU K/GX32oyeuK4n2qI5ZpJHd0PaWK3Zua+vwhcT7Vr6uo1KuIYP+Xc6eyc6A7qnC2ATZuU 2MtcOSJ44lehYfalt7UoZjT4jR3/hnUO/gYb9ccIGN34SSbYHqc6TJvviaK8NdROFgqc 7GXg==
X-Gm-Message-State: AG10YOTzEvUalHdVHkOwoBbz6JarWlZLFny9rvRb/6bXhFErkao/bL7xBzc8rlBGe60BAixgQysEC/X8++fFdw==
MIME-Version: 1.0
X-Received: by 10.25.163.76 with SMTP id m73mr1540254lfe.39.1454532534186; Wed, 03 Feb 2016 12:48:54 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Wed, 3 Feb 2016 12:48:54 -0800 (PST)
In-Reply-To: <CANUQDCj+i2NHwJV89635fkRsa7Sb+b3KrTBQGEF9z=qimZfPdQ@mail.gmail.com>
References: <CAMm+LwjnngkD7GTz3z3u4tjnuzDL+WGpHcpjohCxmZLoPGFuJA@mail.gmail.com> <CABkgnnXyn1nA=HNh8whskQ5No7VC9nk_2g-Xc8_rW1AggWCxAA@mail.gmail.com> <CAMm+LwgTjWS-W+XUyjVMR3hwWDtzUVj0uTL46xGRtoV58yPftg@mail.gmail.com> <CANUQDCj+i2NHwJV89635fkRsa7Sb+b3KrTBQGEF9z=qimZfPdQ@mail.gmail.com>
Date: Wed, 3 Feb 2016 15:48:54 -0500
X-Google-Sender-Auth: GLUHTyYfoeEzA96dadkUNjj3jQk
Message-ID: <CAMm+LwimsgTSvXCwcpT53q+Bcux7pr2fSxXHf-gRhZ34HOk40A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Niklas Keller <me@kelunik.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/FZL4RSOwZR97PWiamSyXubLAR-k>
Cc: "acme@ietf.org" <acme@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
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: Wed, 03 Feb 2016 20:48:57 -0000

On Wed, Feb 3, 2016 at 3:07 PM, Niklas Keller <me@kelunik.com> wrote:
> 2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker <phill@hallambaker.com>om>:

>> 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.
>
>
> And hopefully there will never be such a restriction. The order shouldn't
> matter in any JSON representation. It does already matter in key
> authorization hashes. I think if it matters, no JSON should be used.

There cannot be a restriction on the order of tags inside a JSON
object and it still be JSON. That is XML Schema nonsense we have left
behind.


>> 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:
>
>
> The description is just a protection. The server accepting the request
> should already know what to expect based on the URI and header values.

Assuming that we are going to be wedded to HTTP forever.

I don't think that is a very good plan. I am very much a HTTP
supporter, I worked on HTTP/1.0. But it is a protocol that is designed
to support Web Browsers, not Web Services.

As we get into Internet of Things we are going to want to register for
certificates on devices that have JSON serialization but not TCP/IP,
let alone HTTP.

There should be a clean separation between the application and the
transport/presentation layer.



>>
>> {
>>   "new-reg" : {
>>     "contact": [ "mailto:cert-admin@example.com", ..]
>>     }
>>   }
>>
>> Again, this is something that doesn't make a huge deal of difference
>> for ACME message sizes but would be critical if you were sending a 1GB
>> email.
>
>
> We don't have large payloads in ACME and having to care about order makes
> ACME harder to implement.

My point was that we don't have to worry about order if we do nesting
instead. ACME already has nested objects.

The structure I am proposing is:

{ <Request-Name>  :  { <Request-Data> } }

That will ensure that <Request-Name> is always emitted first as a
matter of course. It is also slightly shorter and avoids the need to
create a reserved name for the resource type.