Re: [Acme] Increase the idempotency of the protocol

Niklas Keller <me@kelunik.com> Wed, 30 December 2015 11:12 UTC

Return-Path: <me@kelunik.com>
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 CFABE1ABD3D for <acme@ietfa.amsl.com>; Wed, 30 Dec 2015 03:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.673
X-Spam-Level: *
X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 6l2MdEx6JJVL for <acme@ietfa.amsl.com>; Wed, 30 Dec 2015 03:11:58 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249821AC40A for <acme@ietf.org>; Wed, 30 Dec 2015 03:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1451473915; l=7298; s=domk; d=kelunik.com; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=Y1WtWWQ5NKdBf/iO7sFqWwtCXauSNSLbBNlvmhAKflM=; b=MWVFpw28bwndSvfn6PfVdZSm/3mggr/KfdadXqwsza0si6Fh3M9CYIXJRAcxPOgI/Qu 23Bs9Wt0QOs36J+wYITs6Xf6GldQXpeAkZEDvkKWfL+YcwvqpZgH9qSi+p6QS2t3PH12Q kI46rwfgW5a5t5ygtCfbyJ7E3sx9Fm1M64o=
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3Y6
X-RZG-CLASS-ID: mo00
Received: from mail-wm0-f45.google.com ([74.125.82.45]) by smtp.strato.de (RZmta 37.15 AUTH) with ESMTPSA id K07ca0rBUBBtoo5 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for <acme@ietf.org>; Wed, 30 Dec 2015 12:11:55 +0100 (CET)
Received: by mail-wm0-f45.google.com with SMTP id u188so36177394wmu.1 for <acme@ietf.org>; Wed, 30 Dec 2015 03:11:55 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.171.97 with SMTP id at1mr69527794wjc.39.1451473915693; Wed, 30 Dec 2015 03:11:55 -0800 (PST)
Received: by 10.194.190.228 with HTTP; Wed, 30 Dec 2015 03:11:55 -0800 (PST)
In-Reply-To: <20151229213656.GA29580@andover>
References: <20151229213656.GA29580@andover>
Date: Wed, 30 Dec 2015 12:11:55 +0100
X-Gmail-Original-Message-ID: <CANUQDCj2k3B96dSZqT3+TFwHnAvi8G4E6i0j5s7JpH8bFY7XNg@mail.gmail.com>
Message-ID: <CANUQDCj2k3B96dSZqT3+TFwHnAvi8G4E6i0j5s7JpH8bFY7XNg@mail.gmail.com>
From: Niklas Keller <me@kelunik.com>
To: Hugo Landau <hlandau@devever.net>
Content-Type: multipart/alternative; boundary=089e013c61502555d505281b9b7e
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/pMRVC9wwh2WsTQr7BIODEYavUGk>
Cc: IETF ACME <acme@ietf.org>
Subject: Re: [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: Wed, 30 Dec 2015 11:12:01 -0000

2015-12-29 22:36 GMT+01:00 Hugo Landau <hlandau@devever.net>et>:

> 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 mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>

There's already another way to do something like this, I proposed to make
those two mandatory instead of optional:
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#registration-objects
(authorizations and certificates keys).

I think having a redirect there is another good addition and also protects
against multi-issuance and resource waste.

Regards, Niklas