[Acme] various issues with the spec

Stefan Bühler <acme@stbuehler.de> Tue, 09 June 2015 20:13 UTC

Return-Path: <acme@stbuehler.de>
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 5E5301A1A31 for <acme@ietfa.amsl.com>; Tue, 9 Jun 2015 13:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.339
X-Spam-Level: *
X-Spam-Status: No, score=1.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id T4OTMzZdvOFt for <acme@ietfa.amsl.com>; Tue, 9 Jun 2015 13:13:29 -0700 (PDT)
Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283C31ACD03 for <acme@ietf.org>; Tue, 9 Jun 2015 13:13:29 -0700 (PDT)
Received: from chromobil.localdomain (unknown [IPv6:2a02:8070:a18c:cc00:baca:3aff:fed7:a10a]) by mail.stbuehler.de (Postfix) with ESMTPSA id A6A28B80128 for <acme@ietf.org>; Tue, 9 Jun 2015 20:13:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1433880806; bh=FtcnQ/bHC5PzMCXtLFE9H/67R9ay0ZIacbg9sT7ipEc=; h=Date:From:To:Subject:From; b=fYwQae3+Yp3oCuap/XS0q9n3B1m+ON7+vT2Kcj8hFqiW5Yq9lK8A6OG1Pmymswflc zZolmqzFul01CIO/VqT//F+kCHSfLKOU0P3nyK8RtkWgn9gUsBmbkPYu4SmIDEdjBi rzzapP8wea6iypEFkd/aWeKaib4vtjD8JBquoqJY=
Date: Tue, 9 Jun 2015 22:13:25 +0200
From: Stefan =?UTF-8?B?QsO8aGxlcg==?= <acme@stbuehler.de>
To: acme@ietf.org
Message-ID: <20150609221325.63935a29@chromobil.localdomain>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/h0eUlBCugITfeK8HmOwXutKudJk>
Subject: [Acme] various issues with the spec
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Jun 2015 19:04:52 -0000

Hi all,

I've been working on a my own acme client (written in Go).

There are some issues I came across, and I thought I'd list them here.
They are too many to write separate mails for each one :)

* Updating registrations: sending empty "contact" and "agreement" should
  actually reset them (if allowed) compared to not sending them, which
  should just keep them as they are (and this should be documented, not
  just happen to be an implementation detail).

  This also means a user can officially query the registration by
  POSTing an empty (signed) JSON object to the registration URI.

* A registration update response should include the rel="next" link and
  the rel="terms-of-service" link, if it would have been sent for a new

* The "success" status code for updates should be documented. Right now
  it seems to be "202 Accepted"

* There should be a way to list all authorizations for a registration,
  and also a way to list all certificates authorized by an

* simpleHttps cannot require the https certificate to use the public
  key of either registration or the "future" key; the registration
  private key should never be available to the web server, and the
  "future" key is not given at that stage.

  Whether https or http is used doesn't matter much here; although I
  see no reason not to require https - it makes MITM harder, because an
  attacker risks getting caught.

* The simpleHttps path should be more restricted to prevent path
  traversals. (https://github.com/letsencrypt/boulder/issues/335)

* dvsni should not require the target domain to be part of the
  certificate; some TLS implementations have quite nice SNI support by
  automatically selecting a matching certificate.

  During the process of authorization you don't want to break your
  normal setup by accidentally using the dvsni certificate.

* 5.5 `If the final state is "valid", ... or add a "recoveryToken"

  There is currently no way for a client to see "private" information
  about a authorization, as it doesn't support a (signed) POST request.

  I think it would be a good idea to define "private" (and completely
  hidden, see below) fields in an authorization request which can only
  be seen by the currect signed request - for example the "key" field
  (which isn't listed by a GET request) and such "recoveryToken" field.

* 6.3. Recovery Contact: `using contact information provided by the
  client in a prior authorizationRequest message.` - I don't see any
  way to provide such contact information - the contact information is
  only provided in the registration, not in the authorization.

  5.5 mentions a "recoveryToken", which would be provided by the
  server, not the client!

* 6.4. Recovery Token: the server must never show the token used to
  satisfy the challenge.

  That way an authorization can be passed on to a different user, i.e.
  someone else tells me the URL to post my registration recovery token
  to, enabling them to takeover the domain without me having to give
  them my recovery token.

* What happens to an expired authorization? Do users create new
  authorizations or reuse the old one?

  The same user should get redirected to an existing authorization when
  trying to create a new one for the same identifier (of course you
  shouldn't redirect to an authorization by a different user).

* Updates should use (or at least allow) "PUT" instead of "POST", as
  they should be idempotent.

* Please document the various "status" more detailed (possible values
  and their interpretations)

* Please document the generic fields a challenge has ("type", "status",
  "url", "validated").

I didn't start working on certificates yet, so there might be more; I
also only had a closer look at simpleHttps and dvsni so far, not at the
other challenge types.

Best regards,