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

Richard Barnes <rlb@ipv.sx> Tue, 28 July 2015 20:02 UTC

Return-Path: <rlb@ipv.sx>
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 903EF1B2EF9 for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 13:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 WfLF7zsVt-Ht for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 13:02:43 -0700 (PDT)
Received: from mail-vn0-f42.google.com (mail-vn0-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFF81B2DF7 for <acme@ietf.org>; Tue, 28 Jul 2015 13:02:42 -0700 (PDT)
Received: by vnk197 with SMTP id 197so47097377vnk.3 for <acme@ietf.org>; Tue, 28 Jul 2015 13:02:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WgUUMLNwMfjBwDclgHfracbExtQTQfkJeVMvUyYpgiw=; b=mIwZjdhk2mbgM4tDjIZgbVX/7ZqfB8XfU58QAE6O84cCe1J84DDEfKywKeH9O2Nztr 9flcybcVkQDTYr+W/hcxEa6XPzSLPGx+8w4NVfSSnMz2cyXSDazgBgAlD65sAk6IsLs7 XK7mwlmNciyv4lNFzsYxnGkUBbobzsIgBTP+0FGGN6OCfjayR3mhZtwDmHhqb88CrreL wq23MeFflBEpSInCdhadnqAOUjBKC8uUSLBLuJBFT8g5A32lWuMnYhjanYLyx+z8h61t JF6nrEMXCo82rENACpHyQGYoxYx8f7Iz2pjRLsOEsCcUzhJFjNp4XGPSlhFgQX8FEIhB V0pA==
X-Gm-Message-State: ALoCoQl1WWBX6YgIf9aaAXDAxODWbLot+cWtAObEZEQoUSSz/ROeAQ4mlx3xRQuFc5Lgxum/BC99
MIME-Version: 1.0
X-Received: by 10.52.255.233 with SMTP id at9mr46011088vdd.38.1438113762027; Tue, 28 Jul 2015 13:02:42 -0700 (PDT)
Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 13:02:41 -0700 (PDT)
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>
Date: Tue, 28 Jul 2015 16:02:41 -0400
Message-ID: <CAL02cgR0HSGT_j4_DOjUnqHW4GOS3mcuWtp4Xaj0OVuYfqLQRw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/cKWSK-uem7y5TDXYmJ7cdqP_7RU>
Cc: "Salz, Rich" <rsalz@akamai.com>, Phillip Hallam-Baker <phill@hallambaker.com>, "acme@ietf.org" <acme@ietf.org>
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:02:49 -0000

On Tue, Jul 28, 2015 at 12:55 PM, Ted Hardie <ted.ietf@gmail.com>; wrote:
> On Mon, Jul 27, 2015 at 6:45 PM, Richard Barnes <rlb@ipv.sx>; wrote:
>>
>> On Mon, Jul 27, 2015 at 7:51 PM, Phillip Hallam-Baker
>> <phill@hallambaker.com>; wrote:
>> > As a general rule, any protocol that contains a component that may be
>> > subject to variation in the field needs an IANA registry. Since we are
>> > going
>> > to have multiple automatic validation processes we will be required to
>> > have
>> > a registry even if there is only one entry at first.
>>
>> ACME has always been structured with a registry in mind; the IANA
>> considerations just haven't been written up :)
>>
>
> So, I think Rich's initial suggestion of FCFS was derived from the notion
> that there would be many proprietary validation mechanisms and that a
> registry should be low friction.  If we are going to use a single mechanism
> and a parameter ("offline", URL), then I think the bar should go up a bit
> and I think it will be between Standards Action and Expert Review.
>
> Any initial thoughts there?

This is getting a bit off-topic for this thread, assuming you're
talking about the overall registry of challenges.

But in any case, I would set the minimum bar at Specification
Required, maybe Expert Review with an eye toward deduplication.  I
don't think there's a need for a ton of review for things to go into
the registry, since you're going to have organizations like CABF and
the CAs themselves making secondary decisions about which mechanisms
they think are suitable.


>> > For the offline part, I don't think that the border between automatic
>> > and
>> > offline is quite as clear as some folk seem to think. Some validation
>> > mechanisms are intrinsically offline we have a proposal for a completely
>> > automatic one but virtually all the processes in use today are a mix of
>> > the
>> > two.
>> >
>> > Even EV issue can be automated if you have an already validate
>> > credential
>> > and a DV issue can return 'pending' for a host of reasons. And even if
>> > you
>> > are doing EV you have to pass domain validation as well.
>>
>> I think what's being proposed is a generic "offline" thing for cases
>> where the validation method you want to use hasn't been defined and
>> registered, or doesn't have broad client support.  So the idea
>> wouldn't be to draw a clear distinction between online and offline
>> validation, but rather to provide an escape valve for cases where the
>> CA and the client can't agree on a fully automated way to do things.
>>
> 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.
>
> 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).
>
> Does that logic track for others?

I think the requirement you've identified here is for the client to
have a way to terminate an authorization.  That might happen because
the client gets the challenges and realizes it can't fulfill any of
them (e.g., because "offline" is all it supports, and it has no
human), or it might happen in a situation like you describe above,
where the first transaction gets cancelled in favor of the second.

It's not immediately obvious how to encode this syntactically, but it
seems like it shouldn't be too hard.

--Richard


>
> Ted
>
>
>
>>
>> --Richard
>>
>> > So I don't think this is a taxonomy thing. It is a 'label the process so
>> > the
>> > automatic bits can be identified' thing and a 'this may not work
>> > automatically' thing. So no to offline/xxxx but yes to a registry of
>> > validation schemes.
>
>