Re: [Acme] Preconditions

Andrew Ayer <agwa@andrewayer.name> Mon, 18 July 2016 02:41 UTC

Date: Sun, 17 Jul 2016 19:38:40 -0700
From: Andrew Ayer <agwa@andrewayer.name>
To: "acme@ietf.org" <acme@ietf.org>
Message-Id: <20160717193840.5141cdee0e56cc3ad052d452@andrewayer.name>
In-Reply-To: <CAL02cgTyFgc2vbP3JmtOWC41u8RpiOcXD0JFyK0WKpKXh-7FYA@mail.gmail.com>
References: <CAL02cgTu8+7Af4mEfhmV36q9g_JyC5=DPyKsiJxMyFAj0qUyUg@mail.gmail.com> <577D5021.9090001@eff.org> <CAL02cgT9S0VyFGk5Nb8s060Uc+A6HPsMW8GKXX8GFpHuS1GePw@mail.gmail.com> <577ECE9E.9020007@eff.org> <577ED5F3.1000006@eff.org> <CAL02cgTfzrBuXvkEnomY6Pv=6p=VeUac1P2P6TtNvxoTiO84XQ@mail.gmail.com> <20160708000515.GE3244@eff.org> <c707dd3e2cf24073854904c098f246b5@usma1ex-dag1mb1.msg.corp.akamai.com> <CAL02cgTyFgc2vbP3JmtOWC41u8RpiOcXD0JFyK0WKpKXh-7FYA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/NFgZShOcKH38QV1hh-fT3Dnp8bs>
Subject: Re: [Acme] Preconditions
Precedence: list

On Thu, 7 Jul 2016 21:58:35 -0400
Richard Barnes <rlb@ipv.sx> wrote:

> OK, I have updated the preconditions PR to reflect this discussion.
> It's more invasive than I thought going in, but I think it hangs
> together.
> 
> https://github.com/ietf-wg-acme/acme/pull/124

I like the direction that ACME is taking by introducing the application
object.  Let me take a stab at answering the two open issues.

> [[ Open issue: There are two possible behaviors for the CA here.
> Either (a) the CA automatically issues once all the requirements are
> fulfilled, or (b) the CA waits for confirmation from the client that
> it should issue.  If we allow both, we will need a signal in the
> application object of whether confirmation is required.  I would
> prefer that auto-issue be the default, which would imply a syntax
> like "confirm": true ]]

I favor auto-issuance as the only option, for client simplicity.  I
think the creation of an application should be sufficient confirmation
from a client that it wants to issue.  Also consider the case where an
account is already authorized for an identifier.  It would be nice if
the client could create an application and be able to immediately
download a cert without needing an additional round trip.

> [[ Open issue: Should this syntax allow multiple certificates?  That
> would support reissuance / renewal in a straightforward way,
> especially if the CSR / notBefore / notAfter could be updated. ]]

Yes, I think it should.  ACME would be a more valuable protocol if it
didn't just help people get a single certificate, but also helped them
manage a certificate application over its entire lifetime, including
across renewals.  All types of clients would benefit from this, but in
particular it would make the following use of ACME possible:

1. You request a certificate for the first time using a full ACME client
on a central, trusted server that has access to your account key and the
ability to complete challenges.

2. You configure lightweight ACME clients on your various servers and
devices with the URL of the application object created in step 1.  The
client would download new certificates as old ones expire.

The advantage of this architecture is that your account credentials
only need to be in one place (assuming that downloading doesn't require
authentication), and if you're using DNS challenges, the credentials to
modify your DNS only need to be in one place.  The lightweight client
would be very easy to implement and integrate into any sort of software
or device.  It could be as simple as making a single HTTP GET that
returns a certificate chain.  Imagine if instead of specifying a
filesystem path to your certificate, you specified an ACME URL!  It
also makes short-lived certificates a lot easier.

There are some questions to consider.

First, should the CSR field be mutable?  I think so.  It would be
convenient to be able to add a new subjectAltName to an existing
application from your central ACME client and have all your servers
and devices automatically pick up the new certificate once it's issued.
SSLMate supports this, since it's common for site operators to add SANs
to existing certificates as they bring new domain names online.

Second, if a renewal, or the addition of an identifier to the CSR,
requires the completion of new requirements, how should they be
expressed in the object?  What should the status of an application be
if it has a valid certificate, but there is a replacement certificate
pending?

Regards,
Andrew

Re: [Acme] Preconditions Peter Eckersley
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Jeff Hodges
Re: [Acme] Preconditions Jeff Hodges
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Salz, Rich
Re: [Acme] Preconditions Peter Eckersley
Re: [Acme] Preconditions Salz, Rich
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Brad Warren
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Jonathan Rudenberg
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Eric Rescorla
Re: [Acme] Preconditions Jonathan Rudenberg
Re: [Acme] Preconditions Salz, Rich
Re: [Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Andrew Ayer
Re: [Acme] Preconditions Andrew Ayer
[Acme] Preconditions Richard Barnes
Re: [Acme] Preconditions Andrew Ayer
Re: [Acme] Preconditions Ron
Re: [Acme] Preconditions Martin Thomson
Re: [Acme] Preconditions Jacob Hoffman-Andrews
Re: [Acme] Preconditions Jacob Hoffman-Andrews