Re: [Acme] Onion address validation extension
Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 09 July 2020 12:30 UTC
Return-Path: <ilariliusvaara@welho.com>
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 45F603A0982 for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 05:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 Y6AlDnuoBH2u for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 05:30:20 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51733A0989 for <acme@ietf.org>; Thu, 9 Jul 2020 05:30:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 888A267E46; Thu, 9 Jul 2020 15:30:18 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id x3eBKnJ3EtZu; Thu, 9 Jul 2020 15:30:18 +0300 (EEST)
Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5051C2308; Thu, 9 Jul 2020 15:30:16 +0300 (EEST)
Date: Thu, 09 Jul 2020 15:30:15 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Sebastian Nielsen <sebastian@sebbe.eu>
Cc: 'Mailing List' <acme@ietf.org>
Message-ID: <20200709123015.GA214719@LK-Perkele-VII>
References: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com> <002001d65552$1cd504d0$567f0e70$@sebbe.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <002001d65552$1cd504d0$567f0e70$@sebbe.eu>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/84gt5eXgcD0qPu-vpcqFB8d6c6E>
Subject: Re: [Acme] Onion address validation extension
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 09 Jul 2020 12:30:22 -0000
On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote: > Couldn’t it be done in the way that the ACME server creates a nonce. I am not sure why the client nonce is there. And I can not quickly find any discussion about cryptographic reasons. It could be for hash strenthening. However, that explanation is problematic: - The signature scheme is Ed25519, which has built-in hash strengthening. - For hash strenthening via applicant nonce to actually work, the CSR must have applicant nonce before CA nonce. However, I do not think it is impossible that it is indeed for hash strengthening and these two details were just missed. > 2 – OR the client can choose to submit the validation result inside > the final CSR. There is a object in the CSR called ”Challenge > password”, which could be ”reused” for this purpose, by filling it > with the result of the validation (ergo a signature by the onion > private key over the nonce). I do not think that would work for two reasons: - ACME protocol is not meant to proceed to CSR sending until after all names are validated. Breaking that would cause implementation problems. - The CSRs are assumed to be self-signed, which is a problem here: - The signature needs to be from Tor key for obvious reasons. - The Tor keys are Ed25519, which is not allowed in WebPKI, even for subscriber certificates. - Even if the keys were allowed, using them for TLS is not cryptographically kosher. However, there should be no problems in this case. For designing a cleaner mechanism to propose to CABForum, I think reasonable starting point would be to model it like the ACME key- change endpoint. However, signing JOSE messages with Tor key is not cryptographically kosher (just like singing CSRs with it is not kosher). However, again there should be no problems in practice (Tor itself never signs with this key, only derives other keys from it). -Ilari
- [Acme] Onion address validation extension Roland Shoemaker
- Re: [Acme] Onion address validation extension Sebastian Nielsen
- Re: [Acme] Onion address validation extension Ilari Liusvaara
- Re: [Acme] Onion address validation extension Ilari Liusvaara
- Re: [Acme] Onion address validation extension Ryan Sleevi
- Re: [Acme] Onion address validation extension Sebastian Nielsen
- Re: [Acme] Onion address validation extension Roland Shoemaker
- Re: [Acme] Onion address validation extension Roland Shoemaker
- Re: [Acme] Onion address validation extension Ilari Liusvaara
- Re: [Acme] Onion address validation extension Salz, Rich
- Re: [Acme] Onion address validation extension Michael Richardson