[Acme] Increase the idempotency of the protocol

Hugo Landau <hlandau@devever.net> Tue, 29 December 2015 21:37 UTC

Return-Path: <hlandau@devever.net>
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 558C31A89FE for <acme@ietfa.amsl.com>; Tue, 29 Dec 2015 13:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.689
X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JCkicPYpAUqG for <acme@ietfa.amsl.com>; Tue, 29 Dec 2015 13:36:58 -0800 (PST)
Received: from umbriel.devever.net (umbriel.devever.net []) by ietfa.amsl.com (Postfix) with ESMTP id 6C7001A8780 for <acme@ietf.org>; Tue, 29 Dec 2015 13:36:58 -0800 (PST)
Received: from localhost (localhost []) by umbriel.devever.net (Postfix) with ESMTP id 5D47B1C854 for <acme@ietf.org>; Tue, 29 Dec 2015 22:36:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1451425017; x=1469614378; bh=WGXc yqNRK0TyMKyppOgULGEZOQkNlQRs2GY9jUpOEZM=; b=Mqu3aG3euCNpU+gihHMx CUkCEzbQ4s/BEhf1NwDRCS9cALLtrKp8zOSbWkLowyMSY6DftJfDBiy6VQvymQsw RcdJhp5jIGJeyS08TqpfOGIc8V8lKRt0QllNGENc2q0FFc6cuy0csYmDbqCWmw4E UEfVxP9BKA4mHXUi+7AKxOuiR8LTuUwvRtOEOgK/r5iDD9JLXzeSIVLwgTxE+6UD Ggd5Kipm6ulbmmc4leHEsgjj9nAXwFct+GnlvtrMF0wAUeL91drZPnKSra/fON/R x43AqoKEGy2D2vSBoJxLzs/TF5ItiE9t0EIeUSU2X2EgMKKZ75r5RsjU/5FDmAhU +w==
Received: from umbriel.devever.net ([]) by localhost (umbriel.devever.net []) (amavisd-new, port 10026) with LMTP id 5AlwivIVQfet for <acme@ietf.org>; Tue, 29 Dec 2015 22:36:57 +0100 (CET)
Received: from andover (localhost []) by umbriel.devever.net (Postfix) with SMTP id 264521C0D7 for <acme@ietf.org>; Tue, 29 Dec 2015 22:36:57 +0100 (CET)
Date: Tue, 29 Dec 2015 21:36:57 +0000
From: Hugo Landau <hlandau@devever.net>
To: acme@ietf.org
Message-ID: <20151229213656.GA29580@andover>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/1S6D7IO-Rc7CbI19Dl6_nQ-fFMI>
Subject: [Acme] Increase the idempotency of the protocol
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: Tue, 29 Dec 2015 21:37:00 -0000

While developing a client, one minor consideration was remembering for
which hostnames authorizations have been obtained. My client remembers
the expiry date of authorizations so that it can avoid unnecessarily
requesting authorizations which have already been obtained.

A general princple of my client is to keep as little state as possible,
on the grounds that where state isn't kept, state can't get messed up.
Where state is kept, there is an implicit hierarchy of normativity, so
that derived state is subsidiary to normative state, and is wherever
possible inferred at runtime rather than being stored.

The 'new account' flow is idempotent in the sense that it can be done
safely if an account has already been registered. It would be highly
desirable for this idempotency to be extended to authorization creation.
Possibly even some thought could be put into idempotency for certificate
and revocation requests.

Essentially, I propose that a client be able to include an expiry time
in a new authorization request. If a valid authorization for the given
hostname exists and which expires on or after the given time, a redirect
should be returned for that authorization in much the same way that an
attempt to register an existing account does. (This expiry time never
influences the validity period of an authorization.)

Requests which do not include an expiry time can be considered
equivalent to requests with a default expiry time. That default expiry
time could be NOW+5m (a choice made under the assumption that no client
will take more than 5 minutes to request a certificate), or +INFINITY
(i.e., an unsatisfiable value resulting in a new authorization always
being created; this preserves compatibility with existing clients).

Certificate requests could be made idempotent by recommending or
requiring servers to redirect to existing certificates when a CSR is
submitted to the server which it has already seen. Servers could
implement this by storing CSRs or hashes of them.

To summarise, the protocol could be rendered significantly more
idempotent with only minor, non-breaking changes. This is a win for
robustess and reduces the chances of repeated requests and corresponding
unnecessary loads on a CA. This would be especially desirable for
certificate requests which exert the most significant cryptographic load
on a CA (HSMs, OCSP signing, etc.).