Re: [Acme] Onion address validation extension

Sebastian Nielsen <> Wed, 08 July 2020 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A75CD3A059F for <>; Wed, 8 Jul 2020 11:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wW-2OSxTiKsR for <>; Wed, 8 Jul 2020 11:03:44 -0700 (PDT)
Received: from ( [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79A633A0542 for <>; Wed, 8 Jul 2020 11:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=root; h=Date:To:From:cc; bh=f5IQcXYxda3Ikr3OJQ2iOA4VDqGvQn2Sz8tAa1m2NEE=; b=MbpCb/B2CMWY+7FoDYRBgFnIJCmMLkwpOYE6Ah3ZDRL7unLlrIVGz/bUaZvcORBuOL79D4wpzX U4jMQIfduUeCxSjlqHDKyJGGQP/yLvy0OKyZ+Qia/1bxkDQOdD2FsBDdyeJtZ2UgZ61WoIXIGkPaS uVJx5k/U9nqu+gIA299s=;
Received: from localhost ([] helo=sebastian-desktop) by with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <>) id 1jtEQ0-000sRz-68 for; Wed, 08 Jul 2020 20:03:40 +0200
Received: from [] (helo=DESKTOPVB5MBIV) by with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <>) id 1jtEPz-000sRw-Qr for; Wed, 08 Jul 2020 20:03:39 +0200
From: Sebastian Nielsen <>
To: 'Mailing List' <>
Message-ID: <002001d65552$1cd504d0$567f0e70$>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_81_1889513353.1594231420149"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIoBxNeWfZA9U1giAhjseBuptMn16hakp+A
X-Encryption-Target: external
Date: Wed, 08 Jul 2020 20:03:40 +0200
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: Wed, 08 Jul 2020 18:03:48 -0000

Couldn’t it be done in the way that the ACME server creates a nonce.

Then there is 2 choices for the client to proceed:


1 – Either the client proceeds as in the draft, and submits the validation to the ACME server – this is required if the client wants to validate more than one domain name


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



This could be made as 2 different validation types: onion-01 and onion-02

Onion-01 requires responding to the validation (as usual as described in the draft), while onion-02 will always succeed at validation stage, but instead you submit the validation response in the final CSR.


(Note that the final CSR in onion-02 is then signed with the certificate private key, while it contains the nonce-signature of the onion-private-key inside the ”Challenge password” field).


Such a ”shortcut” validation method then skips the whole sequence of having to submit for validation, wait for it to succeed and wait for response etc. Its effectively short-cuts the whole process to the very final CSR – while still keeping the same security level.


Från: <> För Roland Shoemaker
Skickat: den 8 juli 2020 19:48
Till: IETF ACME <>
Ämne: [Acme] Onion address validation extension


With the recent passage of SC27 at the CA/Browser Forum there are now acceptable mechanisms for validating v3 Onion addresses for inclusion in DV certificates. As such it would be good to extend ACME to be able to make use of these methods. I've written a short draft that covers what is likely to be the most interesting validation mechanism to CAs (i.e. the one that doesn't require actually using Tor directly) and would be interested in thoughts from the WG.


The defined ACME challenge is basically just an adapted version of the method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think in general the usage of a CSR as the transport mechanism for the nonces and key signature are a bit burdensome, and likely to cause some confusion for implementers (since it introduces yet another place a CSR is transferred between the client and server, with another non-standard use). That said I think the first priority in this document is to get out something that works with current CABF rules. There could be value though in defining our own validation mechanism that is a bit more straightforward alongside the existing CABF method and if/when this document is standardized we could lobby for it's inclusion as a blessed CABF validation method.