Re: [Acme] Supporting off-line (manual) validation

Daniel Kahn Gillmor <> Tue, 28 July 2015 20:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8943D1B2F58 for <>; Tue, 28 Jul 2015 13:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bmQNWI6Kf7Aw for <>; Tue, 28 Jul 2015 13:14:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF29E1B2F56 for <>; Tue, 28 Jul 2015 13:14:38 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 08754F984 for <>; Tue, 28 Jul 2015 16:14:37 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 2DC8D202AC; Tue, 28 Jul 2015 22:14:37 +0200 (CEST)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
User-Agent: Notmuch/0.20.2 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Tue, 28 Jul 2015 16:14:37 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Acme] Supporting off-line (manual) validation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jul 2015 20:14:40 -0000

On Tue 2015-07-28 12:55:33 -0400, Ted Hardie wrote:
> ​I think we still need a failure case here, though, for situations where
> the validation mechanism can't be supported.  (There likely will be
> deployments where encountering "offline" causes the client to conclude that
> the validation mechanism can't be used no matter what is at the URL​,
> because there is no human to check it.)  More troubline is that with the
> ("offline", URL) version the protocol state machine gets stopped part way,
> and distinguishing between "long process" and "abandoned" is difficult.  It
> might be useful to actually recast these so that encountering one results
> in "failure" for the ACME protocol's first run, but results in success with
> a second run using the results of the offline validation.
> That would result in something like this: client A goes to CA Z and asks
> for a cert. CA Z  provides an offline challenge, and Client A soft fails
> while it takes the challenge.  When client A completes the offline process,
> CA Z provides a token using the offline method to be used in
> proof-of-possession.  Client A can then recontacts CA Z and asks for the
> cert, and CA Z provides a proof-of-possesion based challenge.

This seems like a reasonable approach to me.

> That does require some state on CA Z's side to note client A has completed
> the offline challenge and so can use proof-of-possession, but the failure
> case doesn't seem to bad (as you can fail to get a cert, but still can't
> get one you're not entitled to).

on CA Z's side, it could handle the first connection by immediately
creating a high-entropy secret for the validation, handing it over to
the part of the CA infrastructure that does "offline" validation, but
*not* revealing it to the client.  If the offline validation process
completes successfully, it would divulge the high-entropy secret to the
client for the subsequent ACME connection.

On CA Z's side, there is really very little state to manage for the ACME
side of things -- only the creation of a single secret.