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

Richard Barnes <rlb@ipv.sx> Mon, 27 July 2015 22:28 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 623691B34E4 for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 15:28:45 -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 NYgpD_uXn6BZ for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 15:28:44 -0700 (PDT)
Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.47]) (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 BF7A61B34D5 for <acme@ietf.org>; Mon, 27 Jul 2015 15:28:43 -0700 (PDT)
Received: by vnk197 with SMTP id 197so36416118vnk.3 for <acme@ietf.org>; Mon, 27 Jul 2015 15:28:43 -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 :content-transfer-encoding; bh=yXzeYU+cISU3Noh9b54C0248eARtYgzFruPI4AAwN6A=; b=flD+nXgq0MeJiCIbQpgohpYTWiQa/3ty4+W+HxfZOokkOvimyi5YQmDU3zwf6a68tV 527hq/Y6z7JS4eH+xHYT8/PViJupjwYu4zxR0jyG+qVwEvCNkV2qDF400YQ2/xMcjK7J vqeGjZ1pJfuKXvdSpdHhlBuPWBxnhKCgTA0+1pBihZcCSUGAczpSMl0mmJFZTC/XOP1/ EUjx2QpT7mNWyz4TMMv5B46WTYSWduojBjBjnZMJPij4Y2We0gm7IvtWCP7XHQtRh9JE O/q+JAbi/VZZvrgjVZ4O7QLYop3u/2EXny1sMOXNupdG/avVXSbRSwl3HqdJx7V8B9i5 1eZg==
X-Gm-Message-State: ALoCoQlXLJdYN2YsKW48YGkPq1/Tkh0NCCkyohXiSZmCWZNkXELmX02K+aD5+WOPJ6vK+qelCuyd
MIME-Version: 1.0
X-Received: by 10.52.139.210 with SMTP id ra18mr39068148vdb.5.1438036123031; Mon, 27 Jul 2015 15:28:43 -0700 (PDT)
Received: by 10.31.164.207 with HTTP; Mon, 27 Jul 2015 15:28:42 -0700 (PDT)
In-Reply-To: <af096a1746d24694a5503b82deb27d74@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <cdd7588d86884d81a68e104823b65dcc@ustx2ex-dag1mb2.msg.corp.akamai.com> <CA+9kkMDxAE+SAFkQdu09nbq8LBREXxFc_HNpcjCHppkOYTE35w@mail.gmail.com> <af096a1746d24694a5503b82deb27d74@ustx2ex-dag1mb2.msg.corp.akamai.com>
Date: Mon, 27 Jul 2015 18:28:42 -0400
Message-ID: <CAL02cgSGJYws4SEkP7VJ+eOskPBKFKJ1w=_GQ7WLB-MC6=NKiw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/nPT7jzDkTIRrSMORMhxAXZukF_E>
Cc: 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: Mon, 27 Jul 2015 22:28:45 -0000

On Mon, Jul 27, 2015 at 5:11 PM, Salz, Rich <rsalz@akamai.com> wrote:
>> I don't think I understand the IANA registry bit here.  Is the idea that FooCA registers something like FooCA-send-us-this-by-registered-mail, and when the challenge is received by a client it looks at the IANA registry for something it can parse into human interaction?  How is that better than a single "offline" challenge where the URL to check for the steps is in the response?
>
> It lets a single "generic" client say "I don't understand the OmniPublish offline protocol"  Or lets CA vendors ship plugin libraries for a generic ACME client (such as distributed by LetsEncrypt org).  And yes, maybe it's not needed if the URL is something the human points their browser to.

I think you're over-thinking this.  All we need here is a single
escape valve -- "I'm not going to validate this within ACME".  Then
it's up to the CA to make sure that whatever web interface they refer
to explains different options.  Syntactically, I would suggest
something like:

Challenge: { "type": "out-of-band", "href":
"http://example.com/how-to-validate" }
Response: { "type": "out-of-band" }

>> This seems fairly low on the priority list, honestly, but if we are going to do it, I think we need to have some thought to what happens at some of the larger time scales.  If months pass, the contact information may go stale, to take a simple example.
>
> I think it's higher than that *if and only if* the commercial CA's find it something they could use.

I'm not an expert in EV, but I have a pretty hard time thinking of
ways to do EV without something like this.  It's also a nice escape
valve to let CAs move things over to ACME incrementally, or to
innovate with new stuff before clients support it.

It seems like something like this would probably be sensible to add if
there are CAs that might use it.

--Richard


>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme