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, 03 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>: > 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 >
- [Acme] Comments on draft-ietf-acme-acme-01 Phillip Hallam-Baker
- Re: [Acme] Comments on draft-ietf-acme-acme-01 Martin Thomson
- Re: [Acme] Comments on draft-ietf-acme-acme-01 Phillip Hallam-Baker
- Re: [Acme] Comments on draft-ietf-acme-acme-01 Niklas Keller
- Re: [Acme] Comments on draft-ietf-acme-acme-01 Phillip Hallam-Baker
- Re: [Acme] Comments on draft-ietf-acme-acme-01 Jacob Hoffman-Andrews