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

Ties de Kock <> Mon, 04 September 2023 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 446E9C151711 for <>; Mon, 4 Sep 2023 03:19:19 -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, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aBuFm_9moOQh for <>; Mon, 4 Sep 2023 03:19:13 -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 A127CC14CE5D for <>; Mon, 4 Sep 2023 03:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=LltlUfr2NHzgs/KzPgFWL+n30rgKsAMFzqJiPnlv2PM=; b=THSMworRk2LoZTc3LI1lPt1U rkobYTeZMoobN78Rq26fqZXYVQX65H9D4OMddl52ssA6uF5rELSc3qSS/0x3GoqBlOJpvm3jufmaM g96F53VAMpyttSsduaPECf8xr36JSMOJLjKXgl9GmhHwNaxQ9n2KWJkUQhH+ZkdPU5F7LHhhw2G6Q 9tDo96HZnQgX1KeBhXwdWq7uvx2C6+p/lKU+DjYt9Y4lYtt93PykoeTN71o1w+ZZ02UhHMqZGk8W/ Fxi4EuUGQjsC06pnqu8R5pKC/BxvRRUYGOizSdDLe9ntFR1DLjxBbepZ7c4jPSkrM5iHRCcGrq3gH GH8DslqjjQ==;
Received: from ([2001:67c:2e8:23::c100:170c]:44360) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1qd6fm-004AIM-0u; Mon, 04 Sep 2023 10:19:10 +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 1qd6fm-00069p-0h; Mon, 04 Sep 2023 10:19:10 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Ties de Kock <>
In-Reply-To: <ZPS/VK+6Q8a4dHgA@snel>
Date: Mon, 04 Sep 2023 12:18:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <ZPS/VK+6Q8a4dHgA@snel>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3731.700.6)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15f10ee674a4ae00ead336cb768f9cb4b
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 10:19:19 -0000

Hi all,

> On 3 Sep 2023, at 19:16, Job Snijders <> wrote:
> Hi Ben, Ties, Russ, group,
> During IETF 117 hallway conversations the idea of using something other
> than RSA/SHA256 (RFC 7935) came up. Ties pointed out that perhaps the
> average size of Signed Objects could be reduced by using Ed25519 instead
> of RSA. The initial feasibility study stalled on my side when I
> discovered neither OpenSSL nor LibreSSL had support to produce or verify
> CMS with EdDSA signatures.

That was an interesting hallway discussion where we discussed some possible
trivial speedup and realised that signature verification is the slowest step.

I proposed using ECDSA-signed objects due to the ecosystem maturity and provided
test objects in private [0].

> Today, Theo Buehler and I worked on LibreSSL to add experimental support
> for the Ed25519 part of RFC 8419 "Use of Edwards-Curve Digital Signature
> Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)".
> I'd like to share a few observations:
> The Ed25519 public key contained in the EE certificate's SPKI is a mere
> 32 bytes compared to RSA's 256 bytes. But the message digest attribute
> doubles in size (32 -> 64 bytes) because SHA-512 is used. On the upside,
> SHA-512 is ~ 50% faster on 64-bit CPUs compared to SHA-256. The Ed25519
> signature is 64 bytes compared to RSA's 256 bytes. Absence of algorithm
> parameters in Ed25519 also accounts for a few bytes.
> All in all using a Ed25519 keypair for the EE certificate leads to a
> reduction of 420 bytes for semantically equivalent Signed Objects,
> that's significant! And if the CA was Ed25519-based, that would shave
> off another 192 bytes or so.
> Comparison of two semantically equivalent objects:
>    RSA EE w/ RSA CA:     1701 bytes [1]
>    Ed25519 EE w/ RSA CA: 1281 bytes (attached)
>    difference:           420 bytes
> It is possible to mix multiple cryptographic algorithms in the RPKI (see
> section 5 of RFC 6485), provided there is group consensus. There
> wouldn't be a need to produce new Trust Anchors & TALs, those can could
> remain RSA.
> Ed25519 has a few advantages: obviously the reduction in filesize is
> a major one, but it's also FIPS-approved nowadays, widely available,
> well-documented (RFC 8032), standardized for use with CMS, and the
> concept of "PureEdDSA" negates the necessity for error-prone
> Initialize/Update/Finalize (IUF) API interfaces making life easier for
> implementers.
> Questions to the group:
> 1) is there some interest to start a project where the outcome would be
>   to allow Ed25519 in the RPKI, in addition to RSA?

I do think that considering a second algorithm is beneficial. First of all, we
gain performance (by reduction of object size, and increase in verification
speed). Second, in a number of years we likely will want to introduce another
algorithm for the long-lived keys.

Ecosystem support is most important. As you mention, Ed2519-in-CMS support is
recent, as well as the inclusion of Ed25519 in FIPS 186-5 (February 2023).

This matters when you start to consider HSM support. I would focus on ECDSA.

> 2) Russ/Ben/Ties/others - can you successfully decode & verify the
>   attached ASPA object? I can sign and verify the attached object with
>   rpki-client/LibreSSL - but that's just one implementation. I'd love
>   to know if we managed to correctly implement RFC 8419 support before
>   looking at releasing it.

As far as I can tell the relevant OIDs to use during verification (let alone the
rest of the implementation) are not included in bouncy castle 1.76; I can not
verify these objects in a idiomatic way until this is included.

Kind regards,