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

Ted Hardie <ted.ietf@gmail.com> Tue, 28 July 2015 16:55 UTC

Return-Path: <ted.ietf@gmail.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 6F69B1B2A94 for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 09:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 g3wb6UCrw-KW for <acme@ietfa.amsl.com>; Tue, 28 Jul 2015 09:55:35 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 AC8781B2A98 for <acme@ietf.org>; Tue, 28 Jul 2015 09:55:34 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so187588815wic.0 for <acme@ietf.org>; Tue, 28 Jul 2015 09:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=msv3Z/NK1W3ZUnuiJ5D2Vt27TZ4oE+oTAfIiGaNstd0=; b=Lu6sJ7XPiS6f2IFJQpNgRjwTnGiHww6CrNoQMfjDlRRnjh0btE9w9fi3K+eqGCP0m/ +hTkJNnnvr8w05JopxNUX7zglZ7GlPdTahF7plXwvF4yOLq7wOTrpsCgxZzsNJc/4uP7 8IUJPlIrZt8BEujb+hfTEYweEQR84wGeqFMq+WuGquIkcAjJvTBUYoXSXvpyr8VTnQuH kenMgQ7zbd+F+Pg9IlXyHIqrXXTW9f0daQYoBPm423lInhCTgOTiAF4ydn4tCyxY0Mbe iLPK09OKS40mHtLGUXPLWvZ53PT81fc1rRRovV7YEAtPG4cPav0IPQfO2dLH0H8lCJqn kCrA==
MIME-Version: 1.0
X-Received: by 10.194.221.71 with SMTP id qc7mr67773976wjc.9.1438102533446; Tue, 28 Jul 2015 09:55:33 -0700 (PDT)
Received: by 10.194.17.68 with HTTP; Tue, 28 Jul 2015 09:55:33 -0700 (PDT)
In-Reply-To: <CAL02cgQJq4Op0sgU4gr5BprdkOTtpzGfiH6bJxhqTSM0fsdgPQ@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>
Date: Tue, 28 Jul 2015 09:55:33 -0700
Message-ID: <CA+9kkMCF2CQCCv+_cEkBFPPc8rzdkT5rzKq65eX9bc+CZPP-eQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary=001a11c3b724a82085051bf25696
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Y7zp8rnaiwPBxJKfLj32yc10h2k>
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 16:55:37 -0000

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?



> > 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?

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.
>