Re: [Acme] Onion address validation extension

Ilari Liusvaara <> Tue, 21 July 2020 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D46C3A0A36 for <>; Tue, 21 Jul 2020 03:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.63
X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UCNY0Z-6xm41 for <>; Tue, 21 Jul 2020 03:45:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64ED23A087B for <>; Tue, 21 Jul 2020 03:45:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B165167C45; Tue, 21 Jul 2020 13:45:04 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id LOoRNxFL9uwp; Tue, 21 Jul 2020 13:45:04 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 73D162316; Tue, 21 Jul 2020 13:45:02 +0300 (EEST)
Date: Tue, 21 Jul 2020 13:45:01 +0300
From: Ilari Liusvaara <>
To: Ryan Sleevi <>
Cc: Mailing List <>
Message-ID: <20200721104501.GA464556@LK-Perkele-VII>
References: <> <002001d65552$1cd504d0$567f0e70$> <20200709123015.GA214719@LK-Perkele-VII> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Acme] Onion address validation extension
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2020 10:45:09 -0000

On Thu, Jul 09, 2020 at 09:01:25AM -0400, Ryan Sleevi wrote:
> On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara <>
> wrote:
> > 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).
> I think the odds of a change in the Forum are low here. I’ll readily admit,
> I am intentionally rather hostile to JOSE / COSE being introduced into the
> CABF, because of the consistent and persistent security failures these
> formats lead to.
> That said, given the rather significant improvements to the cryptographic
> constructions of v3, I’m also quite keen for any establishment protocol in
> the CSR that can suitably demonstrate a POP within the CSR. It needs to be
> robust to cross-protocol reuse, but I suspect that is now substantially
> easier given the v3 construction. I suspect that would also make it easier
> for ACME, but perhaps I’m overlooking why even a simplified form is
> challenging?

It turns out that signing messages with Tor key does not have harmful
cryptographic interactions with the way Tor uses that key (due to EdDSA
also hashing the key when signing). 

The main issue with the present CSR method is complexity. The applicant
nonce does nothing useful (as due to ordering of the main EdDSA hash,
R already strenghens it). The description of format is too hard to
understand (an example would go long way to resolving the latter issue).

There are simpler constrctions that would do the POP. For example
(TLS syntax):

struct {
	opaque public_key[32];
	opaque nonce<22..255>;
} PopInner;

Sign PopInner structure using TLS 1.3 signature format with context
string "ACME, tor-rendv3-pop". Base64url-encode the 64-byte signature
and send it in ready for challenge request. 

CA can verify this by reconstructing the PoPInner from the known key
nonce and verifying the given signature with the key.

However, this does not do approval of ACME key (neither does the present
CSR method). I think the reason of approving old key with new key in
performing the key rollover is to prevent replaying new keys. Replay
here is prevented by the CA nonce.

And I think I found an issue in draft-shoemaker-acme-onion: It requires
only 64 bits of entropy for CA nonce, while BRs require 112, and base
ACME spec requires 128. Fix would be to change the first "64 bits of
entropy" in section 4 to "128 bits of entropy". This is presumably due
to confusing the two nonces, as applicant nonce can indeed be 64-bit.