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

Phillip Hallam-Baker <> Wed, 03 February 2016 19:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9D301B2C10 for <>; Wed, 3 Feb 2016 11:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GMqKdcowVNMo for <>; Wed, 3 Feb 2016 11:55:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03CD01B2C0F for <>; Wed, 3 Feb 2016 11:55:49 -0800 (PST)
Received: by with SMTP id j78so21811776lfb.1 for <>; Wed, 03 Feb 2016 11:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JR/4rGomhd+QqSSkuA5qXMRuocyfpPmIxnvdZ/VZXl0=; b=ZqNYA0bR1tIN2Qk/z+a4qsn7fWY6QVkLLKxWe8zDtedQ9nkKPL0iUxGuJlttEdN8DN J+GP3N2fKAmskmBzaEfaehhjOZLFqB1gnpqFFFnmAPIKOnQgC6VTdQ1Vg3TUgCL8aaEF LX/5H7UKLbI48U9tKICdgkXg0w5eCpGW5DM6KOgMO8G6+64sGcNTH2DO9IH8u5R6P6oP Sl9aI4K/cgiqsACGBtrObxGbrEuPK1EJfd04chXTOfPC2E+YzI+Q7rPx1jMUvzVrmXbB tlJK9Z3dp+tLmKpea34iyIceaYDGD8Xx6RtRe0AcdGC0YbjwUK92c1Z0jnRXmno67HYp aPuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JR/4rGomhd+QqSSkuA5qXMRuocyfpPmIxnvdZ/VZXl0=; b=cllgphddqG461Zj762QCEohlP05fCr96NyDUqhnQ9ty71TLoyW15vwAG8PqN+Ja/E3 +vwTyYlyByyLaFw4RQ3jmbAspviwyT8KWxuwgMnS6aVw+D55InLSk+3HUpuAExUKVFWZ Lb4FNzISl7ewwT6qI+0OhTRFJmltyLtW+9BCPrnJezLRa+9TivbvYoyStMfrOzgb82nr KsBxoTYSRFQhYBMW+BtqfgE+lh1naYTHbZzQpkMcegRSX0EcYSZGJWEhzcE7ftXaprbx C8+T5MypY5Ks0310ZZMrilfpjU4Xxkso9Qb0YQIJCpOf3OBTZBeVG4gkctO/0YA2HEPQ lnDw==
X-Gm-Message-State: AG10YOQ9/rfYL9MpW5i2m6OKd9YPhZEDQVO6rJNMFaqaQXlBZOPDglg/XJlsEt59HlHwiI3zF9OaVv1jDWMXNQ==
MIME-Version: 1.0
X-Received: by with SMTP id r15mr1432276lfe.166.1454529347208; Wed, 03 Feb 2016 11:55:47 -0800 (PST)
Received: by with HTTP; Wed, 3 Feb 2016 11:55:46 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 3 Feb 2016 14:55:46 -0500
X-Google-Sender-Auth: u21vNz6UqLBex8FJGEGLiAjJ7EU
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Martin Thomson <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [Acme] Comments on draft-ietf-acme-acme-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Feb 2016 19:55:50 -0000

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:

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


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": [ "", ..]

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

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": [ "", ..]

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

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?