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

Niklas Keller <me@kelunik.com> Wed, 03 February 2016 20:07 UTC

Return-Path: <me@kelunik.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 7EBB61B2C2A for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 12:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level:
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 aZfkDQOIErLX for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 12:07:30 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8034D1B2C1F for <acme@ietf.org>; Wed, 3 Feb 2016 12:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1454530048; l=9982; s=domk; d=kelunik.com; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=3zh84+SA1bDZCQ/gc9fMyuvWPulCMSx2hP2jIs9Dfdg=; b=TR1samu6BArIg0+ndM3Gs6cJ6YWUk8EaYTLrX+5Ow9OVzirNYhfHamxS7MNzdtSWAyv i5qwZBoraKeLVwrAemOxoc0rfe7/qy4Xe+sqUJUzCKR/AZNxwYL+oOG6pnn73bQrenfaK Bo3rpfCCgEQNZMaAZ2Q+dWWHEPwuK3STUGE=
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtOnA6
X-RZG-CLASS-ID: mo00
Received: from mail-wm0-f53.google.com ([74.125.82.53]) by smtp.strato.de (RZmta 37.17 AUTH) with ESMTPSA id C05f5as13K7S9cU (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for <acme@ietf.org>; Wed, 3 Feb 2016 21:07:28 +0100 (CET)
Received: by mail-wm0-f53.google.com with SMTP id l66so87320616wml.0 for <acme@ietf.org>; Wed, 03 Feb 2016 12:07:28 -0800 (PST)
X-Gm-Message-State: AG10YOStBK0LwOkVz8eQXjwiNJEk4y1eTYUkGAeLR1OnmjyF42YmYRB2T5xQSz0evpxNStvZX3OAv+J+Akr+Ng==
MIME-Version: 1.0
X-Received: by 10.28.101.131 with SMTP id z125mr25300858wmb.60.1454530048078; Wed, 03 Feb 2016 12:07:28 -0800 (PST)
Received: by 10.194.78.133 with HTTP; Wed, 3 Feb 2016 12:07:28 -0800 (PST)
In-Reply-To: <CAMm+LwgTjWS-W+XUyjVMR3hwWDtzUVj0uTL46xGRtoV58yPftg@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>
Date: Wed, 3 Feb 2016 21:07:28 +0100
X-Gmail-Original-Message-ID: <CANUQDCj+i2NHwJV89635fkRsa7Sb+b3KrTBQGEF9z=qimZfPdQ@mail.gmail.com>
Message-ID: <CANUQDCj+i2NHwJV89635fkRsa7Sb+b3KrTBQGEF9z=qimZfPdQ@mail.gmail.com>
From: Niklas Keller <me@kelunik.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary=001a114af706d4c394052ae32af1
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/PnLokUR4KBITyDC-El6hNFYmEgk>
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:07:33 -0000

2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker <phill@hallambaker.com>om>:

> I think Terminology and Dependencies should also have a mention of
> HTTP / HTTPS, also RFC3339 (time format).
>
> What I would like to get to eventually is some external document
> describing a particular style of JOSE /JSON / HTTP / TLS Web service
> that can simply be referenced by a Web Service spec. This means:
>
> * We don't keep having to write out the same thing
> * We don't have slightly different versions in different specs
> * This can be handled by code synthesizers and support libraries.
>
> I did a pass on this for the Mesh:
>
> https://tools.ietf.org/html/draft-hallambaker-json-web-service-01
>
> So far it looks pretty similar to ACME except that I am introducing a
> new JOSE serialization format as I am looking at supporting future
> apps that can't tolerate the Base64url encoding of the payload (which
> will likely be in GB).
>
>
> In section 5, actual examples of the messages would be nice.
>
> 5.1 There is a mention of cross origin but no explanation of what is
> involved.
>
> This is worrying, what use is being made of HTTP state mechanisms in
> ACME? Why is cross origin relevant? So far I have not read anything
> that gives a rationale.
>
> I would prefer to decouple ACME from HTTP as far as possible. HTTP is
> far to complex to be analyzed at this point. Reinventing the wheel is
> precisely what to do when someone is offering you jet propelled roller
> skates.
>
> 5.2
>
> I start to get lost at this point. The "resource" values look to me
> like protocol transaction requests.
>
> I think it is important to be clear on this because at some point we
> are going to want to add in request types that are expressly command
> like. Commands like "Hello".
>
> 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.
>

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.


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


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


> Where it does give a lot of leverage however is when you are using a
> protocol synthesizer like ProtoGen. The parser knows what type of
> object it is parsing when it starts on that object. That allows for a
> more efficient process than having to first scan for the 'resource'
> tag and then construct the object to emit.
>
>
> 5.6: We are going to do CFRG curves, right?
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>