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

Richard Barnes <rlb@ipv.sx> Tue, 28 July 2015 01:45 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 137941A1BCB for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 18:45:10 -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 q7WcNx2pNuLR for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 18:45:08 -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 906BE1A1B27 for <acme@ietf.org>; Mon, 27 Jul 2015 18:45:07 -0700 (PDT)
Received: by vnav141 with SMTP id v141so37737646vna.0 for <acme@ietf.org>; Mon, 27 Jul 2015 18:45:06 -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=l8D+z0sTmpZevGipo09AxyTz00cQj/LFNpELmDbyJZY=; b=GMM+8Kwc3HuNbfHoFZUMEelYrVdEwEGROP0UN4VMRVSssIm8OYmS3wbf5u43A4kDoP AwRAQizx9+1ugO4diEMK4seemPiEPglb9pxRsLk/3a+xWNXBrRRmZzo/db6CUGaSHwOy ihfCl//AhNeb20Y4VH3f8eZa83e1zXXgUQaD76cQXj8REtCPtFniHOxaOfxopM6h6lwg JTRWDFNfwUAjjBHnsKeFla27qMOU2RKIOHDnK9v0GGFeFTaLFnvvGWdQl9kIJd3wgsHw ocMZ935Swfthta9BcxAzmOYMJ1Kn+f4CSlCM6y93K+XxAqNhw29teN5aveeBqPkFaSvl dLQg==
X-Gm-Message-State: ALoCoQnzrJ3gJqNYiDpPy7wIEhtfLdGCIs+BmBIFd5EpoNSncTR3Fv3BoTPaoOnwY65b5fQl+3is
MIME-Version: 1.0
X-Received: by 10.52.139.210 with SMTP id ra18mr40240824vdb.5.1438047906842; Mon, 27 Jul 2015 18:45:06 -0700 (PDT)
Received: by 10.31.164.207 with HTTP; Mon, 27 Jul 2015 18:45:06 -0700 (PDT)
In-Reply-To: <CAMm+LwjANR0UgPcHCXGOxEoa8CeVZM2iUWsEEbKboYouJ9Sb3A@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>
Date: Mon, 27 Jul 2015 21:45:06 -0400
Message-ID: <CAL02cgQJq4Op0sgU4gr5BprdkOTtpzGfiH6bJxhqTSM0fsdgPQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/zepJkk4hggiYM1oI-xDvJ6kd_v0>
Cc: "Salz, Rich" <rsalz@akamai.com>, Ted Hardie <ted.ietf@gmail.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 01:45:10 -0000

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 :)

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

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