[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [149.202.51.241]) 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 [127.0.0.1]) 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 ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (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 [127.0.0.1]) 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.).
- [Acme] Increase the idempotency of the protocol Hugo Landau
- Re: [Acme] Increase the idempotency of the protoc… Niklas Keller