IETF Logo Mail Archive

Re: [Acme] Assisted-DNS challenge type

Thomas Lußnig <lussnig@suche.org> Tue, 23 January 2018 16:42 UTC

Return-Path: <lussnig@suche.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DE91270FC for <acme@ietfa.amsl.com>; Tue, 23 Jan 2018 08:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Z3-JlFE_7Q2D for <acme@ietfa.amsl.com>; Tue, 23 Jan 2018 08:42:20 -0800 (PST)
Received: from relay-mx.smcc.de (relay-mx.smcc.de [194.50.33.90]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EBA1270B4 for <acme@ietf.org>; Tue, 23 Jan 2018 08:41:57 -0800 (PST)
Received: by mx-32.smcc.de (Postfix, from userid 65534) id 639B4563BF; Tue, 23 Jan 2018 17:41:56 +0100 (CET)
X-Spam-SCL: 1
Received: from localhost (localhost [127.0.0.1]) by mx-32.smcc.de (Postfix) with ESMTP id 0B2B4562B3; Tue, 23 Jan 2018 17:41:56 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx-30.smcc.net
Received: from relay-mx.smcc.de ([127.0.0.1]) by localhost (relay-mx-02.smcc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ML_BnO2BBEm; Tue, 23 Jan 2018 17:41:55 +0100 (CET)
Received: from [192.168.1.2] (aftr-95-222-26-151.unity-media.net [95.222.26.151]) by mx-32.smcc.de (Postfix) with ESMTPSA id D85C456264; Tue, 23 Jan 2018 17:41:55 +0100 (CET)
To: acme@ietf.org
References: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org> <DM5PR14MB1289780FE7165120F0EEE14083E30@DM5PR14MB1289.namprd14.prod.outlook.com>
From: Thomas Lußnig <lussnig@suche.org>
Message-ID: <5dfe4e3b-172e-a38b-e632-61a5dbfce30d@suche.org>
Date: Tue, 23 Jan 2018 17:41:58 +0100
MIME-Version: 1.0
In-Reply-To: <DM5PR14MB1289780FE7165120F0EEE14083E30@DM5PR14MB1289.namprd14.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/MvmIMlXVTuhL6jeYZg8JHEsLPu0>
Subject: Re: [Acme] Assisted-DNS challenge type
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Jan 2018 16:42:22 -0000

Yes and if you avoid the random token in the primary location,
you can use the public account key announced in the dns also as static 
prove.


On 1/23/2018 5:37 PM, Tim Hollebeek wrote:
> Your proposed method defeats one of the goals of the BR domain control
> validation requirements, which is to demonstrate control at time of validation,
> not just as some previous time in the past.  That's why the existing, approved
> validation methods require random numbers to guarantee the validation is
> fresh and not based on some previous validation.
>
> If control at some time in the past is sufficient, you can just re-use the previous
> validation, which is allowed in some circumstances (see the BRs).

v2.23.0 | Report a Bug | By Email