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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 28 July 2015 20:14 UTC

Return-Path: <dkg@fifthhorseman.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 8943D1B2F58 for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 13:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bmQNWI6Kf7Aw for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 13:14:39 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF29E1B2F56 for <acme@ietf.org>; Tue, 28 Jul 2015 13:14:38 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 08754F984 for <acme@ietf.org>; Tue, 28 Jul 2015 16:14:37 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 2DC8D202AC; Tue, 28 Jul 2015 22:14:37 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: acme@ietf.org
In-Reply-To: <CA+9kkMCF2CQCCv+_cEkBFPPc8rzdkT5rzKq65eX9bc+CZPP-eQ@mail.gmail.com>
References: <cdd7588d86884d81a68e104823b65dcc@ustx2ex-dag1mb2.msg.corp.akamai.com> <CA+9kkMDxAE+SAFkQdu09nbq8LBREXxFc_HNpcjCHppkOYTE35w@mail.gmail.com> <af096a1746d24694a5503b82deb27d74@ustx2ex-dag1mb2.msg.corp.akamai.com> <CAL02cgSGJYws4SEkP7VJ+eOskPBKFKJ1w=_GQ7WLB-MC6=NKiw@mail.gmail.com> <671fb43b59c44e9b848926189912da01@ustx2ex-dag1mb2.msg.corp.akamai.com> <CAMm+LwjANR0UgPcHCXGOxEoa8CeVZM2iUWsEEbKboYouJ9Sb3A@mail.gmail.com> <CAL02cgQJq4Op0sgU4gr5BprdkOTtpzGfiH6bJxhqTSM0fsdgPQ@mail.gmail.com> <CA+9kkMCF2CQCCv+_cEkBFPPc8rzdkT5rzKq65eX9bc+CZPP-eQ@mail.gmail.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Tue, 28 Jul 2015 16:14:37 -0400
Message-ID: <87wpxkghua.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/b0AtUiz2gpWxnl-WJ9OQS3kZcKg>
Subject: Re: [Acme] Supporting off-line (manual) validation
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, 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.

     --dkg