[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 [127.0.0.1]) 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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, 09 Jun 2015 22:13:25 +0200
From: Stefan Bühler <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 registration. * 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 authorization. * 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" field.` 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, Stefan
- [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Salz, Rich
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec hallam
- Re: [Acme] various issues with the spec Fraser Tweedale
- Re: [Acme] idempotent requests (various issues wi… Stefan Bühler
- Re: [Acme] various issues with the spec Fraser Tweedale
- Re: [Acme] various issues with the spec Stefan Bühler
- Re: [Acme] various issues with the spec Phillip Hallam-Baker