Re: [Sidrops] Signed Object signed with Ed25519 (RFC 8419 proof-of-concept)

Ties de Kock <> Mon, 04 September 2023 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACDDAC15199A for <>; Mon, 4 Sep 2023 04:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10TT7dzcGlia for <>; Mon, 4 Sep 2023 04:51:24 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 6FBC5C14CF1D for <>; Mon, 4 Sep 2023 04:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=aT3EjyZ2zsvgsI8Fz8p6mb4bAYxJ2+PqOcv+FdjJmOY=; b=C4Fp44Foh0iulDDUoQ67I7dQ JUJeQgBjM/WD9TUO4RhorKT58tL+yjs4aXrMK7qQI7M/ZTqaI9KsRyF/W3tI+gYchetcr5k+RV7ge Xk9S/wBXMkiLOOEhc+AYxV9CMfZRkfvk+2m03/pqqiu1dYcNmYua2qRta/3RjDIH1jI8/Xn/KsUcJ ZbyPeMCC/mQVrfUavPkbKR3cCQX4ru5c/m3F6FnwMPng3zJo5nOfQM69VY5BLYf0PznTJEwwiaNvf Tc1O8aMay1cg7wezvWpxpeqius/yknpKzuCxUsRfqfjOX+caOwObO1aYuFnq5eu5XJx67B3QBFuRL ZTLQg6bU8Q==;
Received: from ([2001:67c:2e8:23::c100:170c]:45288) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1qd870-004CeX-33; Mon, 04 Sep 2023 11:51:22 +0000
Received: from ([2001:67c:2e8:9::c100:14e6] by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1qd870-0003zU-2m; Mon, 04 Sep 2023 11:51:22 +0000
From: Ties de Kock <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3023AD80-1563-4C8C-905F-26A0008B90BA"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Mon, 04 Sep 2023 13:51:12 +0200
In-Reply-To: <ZPW+682GaAFXymLo@snel>
To: Job Snijders <>
References: <ZPS/VK+6Q8a4dHgA@snel> <> <ZPW+682GaAFXymLo@snel>
X-Mailer: Apple Mail (2.3731.700.6)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e19ad9d6b9dc85d685ed0e83329996c094
Archived-At: <>
Subject: Re: [Sidrops] Signed Object signed with Ed25519 (RFC 8419 proof-of-concept)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Sep 2023 11:51:28 -0000

Hi Job,

> On 4 Sep 2023, at 13:26, Job Snijders <> wrote:
> On Mon, Sep 04, 2023 at 12:18:59PM +0200, Ties de Kock wrote:
>> I proposed using ECDSA-signed objects due to the ecosystem maturity
>> and provided test objects in private [0].
> Which RFC specifies the parameters to use with ECDSA in CMS? I'm looking
> for something along the lines of RFC 8419.

> I generated a secp256k1/sha256 ASPA object, but unfortunately the
> filesize reduction in semantically equivalent objects is only half that
> of Ed25519. See below:
> RSA EE w/ RSA CA:              1701 bytes [1]
> secp256k1 w/ sha256 w/ RSA CA: 1463 bytes (attached)
> Ed25519 EE w/ RSA CA:          1281 bytes [2]
> Over the years ECDSA seems to be facing increasing criticism,
> specifically due to the difficulty of correctly and safely implementing
> the standard. As many consider this aspect of ECDSA a dangerous
> primitive, ECDSA would not be my go-to choice for future work.

It would not be my first choice in an ideal world. But at the moment I think it
is a valid choice. We should probably ask the CFRG for advice here.

In the end, you need to trust your implementation, and I think that high-quality
implementations are available. Ultimately, you trust your RSA implementation to
generate unpredictable primes, ECDSA to use unique NONCEs, and ed25519
implementations not to leak bits of the sha512 of the private key.

That is to say: All crypto has caveats, and as a software engineer I stay away
from implementing low-level primitves :)

> I'm happy to report that extending LibreSSL and OpenSSL to support use
> of Ed25519 in CMS is a trivial patch (as both libraries already
> supported Ed25519 signing & verification operations).
> Support for Ed25519 in HSMs indeed remains an open question. Perhaps now
> that the algorithm is FIPS-approved more HSM vendors will feel
> comfortable adding it to their roadmaps? Thank you for sharing that
> Bouncy Castle still needs some work, it's good to identify such gaps.

I was surprised that it was available (but this is a very recent HSM)! It is
definitely good to identify the gaps.

Kind regards,

> Kind regards,
> Job
> [1]:
> [2]:
> ps. Your test object threw errors: 'RSYNC://' != 'Rsync://' in the SIA.
> <secp256k1.asa>

Seems like this was a conscious change in our test code in 2020. Isn’t the
scheme case-insensitive?