Re: [Acme] Onion address validation extension

Michael Richardson <> Tue, 21 July 2020 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4AEE3A09B3 for <>; Tue, 21 Jul 2020 07:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JjaLjumlCet7 for <>; Tue, 21 Jul 2020 07:47:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE2BB3A09C9 for <>; Tue, 21 Jul 2020 07:47:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 330FF38A1E; Tue, 21 Jul 2020 10:26:33 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id yo9uqh7CUKBW; Tue, 21 Jul 2020 10:26:32 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 2F81A38A1D; Tue, 21 Jul 2020 10:26:32 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6C5563F; Tue, 21 Jul 2020 10:46:57 -0400 (EDT)
From: Michael Richardson <>
To: Ilari Liusvaara <>
cc: Ryan Sleevi <>, Mailing List <>
In-Reply-To: <20200721104501.GA464556@LK-Perkele-VII>
References: <> <002001d65552$1cd504d0$567f0e70$> <20200709123015.GA214719@LK-Perkele-VII> <> <20200721104501.GA464556@LK-Perkele-VII>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 10:46:57 -0400
Message-ID: <19472.1595342817@localhost>
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 14:47:03 -0000

Ilari Liusvaara <> wrote:
    >> 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).

That's an interesting point.
It seems that should there be future algorithms after EdDSA, that they could
adopt the same process.  But is there no interest in RSA? :-0

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

Is this just a documentation issue, or does it potentially introduce coding errors?

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

Can you explain what you mean by "replaying new keys".

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

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [