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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 03 February 2016 18:12 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 []) by ietfa.amsl.com (Postfix) with ESMTP id DB4BC1B2A5C for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 10:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KpUFOtIcXlOu for <acme@ietfa.amsl.com>; Wed, 3 Feb 2016 10:12:42 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 939011A802E for <acme@ietf.org>; Wed, 3 Feb 2016 10:12:41 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id dx2so16950406lbd.3 for <acme@ietf.org>; Wed, 03 Feb 2016 10:12:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=i+8GMqcfpZLfPGJV4oy7NEAHUWK+UD3EVeyfplkveps=; b=pd9GsdhleOyVZG4rFEOLAfAwJ+gmlEKTyUTY70BcZxm0iCvsypvGo80cNf8VtnpKa9 tujvCaJ9ANfmZRw/YbkK/qQbZLSBzkMPEvxURdG6a/dAmQrBliMbVGRWJzU7FJT79K0b rO1SWY5NqYntU7EYjWTJcEIWEgmMLO2YDRuaAUHm2wGPCZ2TFni78yh9LAjd3srbJn0C tJZFbLIUQNhuqdKHa2EsnKaP9irpYRPWaIISya9VjrStEQ/uP8fLPbaOJU2P4386veob eR8z8FS21UyTWZlUuNLtB9E//1c1Xr0pY7g5Xn/vBSn2idR1DGS/kiBm34dTFXpuHWeq oRkQ==
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:date:message-id:subject:from :to:content-type:content-transfer-encoding; bh=i+8GMqcfpZLfPGJV4oy7NEAHUWK+UD3EVeyfplkveps=; b=SvNkNRdUNgT8bAmvZttCK62TUyvjqM9s0F+MoK8r+ra5D6dnr4CBxWQJhB97ds1lG7 xJFxwo+QyreBq+lkocw5CD2FuDwi3dsqY6qwNsguyggxqU6n6/XHQjOxBLW3+r9AcbsY 4MHJA/NsMKAN4Vs1ob500cP+VjA4fe/CM7aRQw/RlMN8NA0YARIbPUjX6evGne7moxvH BnWVHZm8vmlyIupvc0VygJlgwPna2tEjnnESpqNKuxD2OxCZyBOCSUJHliIuDrbht9Y+ GeOSXEFZX6BSwCUR3uOgOi+8OOD0YR+RMMOo0PXQswf1vHjPdtU3ehNwFkFVIb5JSh6U qbTw==
X-Gm-Message-State: AG10YOTnQoJ8NEPLLW/7wdBKyOPeM90vtUPJAH+fEnePejInKuGPFCq5OFGJb7RV/2bD7zKPkQrEGLHNckUeTg==
MIME-Version: 1.0
X-Received: by with SMTP id k5mr1464193lbs.133.1454523159615; Wed, 03 Feb 2016 10:12:39 -0800 (PST)
Sender: hallam@gmail.com
Received: by with HTTP; Wed, 3 Feb 2016 10:12:39 -0800 (PST)
Date: Wed, 3 Feb 2016 13:12:39 -0500
X-Google-Sender-Auth: vwP6bmbztQ97Y5TxMixAUpBd1Ww
Message-ID: <CAMm+LwjnngkD7GTz3z3u4tjnuzDL+WGpHcpjohCxmZLoPGFuJA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "acme@ietf.org" <acme@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/7ThDRWSZdonudi8_3Mo7nTlnP6U>
Subject: [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 18:12:43 -0000

Section 3.

ACME does not use Base64 encoding, it uses Base64url. This is the
correct choice but the document specifies this indirectly.

--- Definitions

Account Key Pair: A public key pair to authenticate certificate
management requests. An ACME server considers the holder of the
private key authorized to manage certificates for a given identifier.
A single key pair MAY be authorized for multiple identifiers.

--- Base64

" ACME messaging is based on HTTPS [RFC2818] and JSON [RFC7159]. Since
JSON is a text-based format, binary fields are Base64-encoded. For
Base64 encoding, we use the variant defined in [RFC7515]."

RFC7515 has:

 Base64url Encoding Base64 encoding using the URL- and filename-safe
character set defined in Section 5 of RFC 4648 [RFC4648], with all
trailing ’=’ characters omitted (as permitted by Section 3.2) and
without the inclusion of any line breaks, whitespace, or other
additional characters. Note that the base64url encoding of the empty
octet sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)

I suggest changing the text to

"ACME messaging is based on HTTPS [RFC2818] and JSON [RFC7159].

Binary fields are encoded using Base64url encoding described in
[RFC4648] Section 5, according to the profile specified in JSON Web
Signature  [RFC7515] Section 2. This encoding uses a URL safe
character set. Trailing '=' characters MUST be stripped."

[If it isn't a MUST strip then readers MUST accept padding so no point
talking about it.]

Section 3 is headed Terminology but actually contains normative
descriptive text. I suggest using 'Terminology and References' to make
this clear. I would also suggest that people are more used to finding
this as section 2.

It is a better way to organize though. I am changing some of my docs
to follow suit. Basically, put all the material that relates to
external dependencies in one place.

Suggest more use of subsections though, gather all the JWS stuff into
one place, all the JSON, etc.