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

Job Snijders <job@fastly.com> Sun, 03 September 2023 17:16 UTC

Return-Path: <job@fastly.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 602DFC151088 for <sidrops@ietfa.amsl.com>; Sun, 3 Sep 2023 10:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5-dkQ9Fmcvd6 for <sidrops@ietfa.amsl.com>; Sun, 3 Sep 2023 10:16:09 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B72BC14CEED for <sidrops@ietf.org>; Sun, 3 Sep 2023 10:16:09 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-99bf3f59905so110992166b.3 for <sidrops@ietf.org>; Sun, 03 Sep 2023 10:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1693761367; x=1694366167; darn=ietf.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=dcKjXDE4aHtaVNzMuvKk2olNf9j5pW24NPqnZGQPoe0=; b=YlPPVHg8dS6APROa5NGgfyu3QcOa9HQeyjFSM3VuCui29c0OwwZ7TgvekXtGUU5PuU SH9kYxmd6fpY8xid32eFtowoQN33NTaucuFU+jVCVfjxLzv6nyLAceXrLL6DJSlYQ+xy pBlfL4zuFgXfaaC/E3tBlUnxanRwqe464wapo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693761367; x=1694366167; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dcKjXDE4aHtaVNzMuvKk2olNf9j5pW24NPqnZGQPoe0=; b=BJGkQxtcd/tavnYSdL2phQxqLyI66b340aQHIUvxyQ0yguIUqtKWC2kcdsQl4eZPZ9 5PTAny8CuZnHDOjs+j/F24B9+yvGC3R4dd3BvVVVwtMDpbJqaaY/VJGEqE0qklHsluEP lmOHYeAvJk+6Wz6kGXJgA2ReA3KG+woSWPXNHU8yDyVvnW3705m8ETTpY/yN4f/Q0y/e +NHR2aJkJ9u74oqx7ZNprnaIlXWRJGkovOdTOngO/ex1fkg9vGdRuAHE8ODf1n20Xoyb rio7UpwRoOuLI8WTuzgIN6w5yyok5IdygFIe2S8FKvnle/Id0llS9kLeL2QIGEm2BW1s 2jvQ==
X-Gm-Message-State: AOJu0Yx/BtiHWOvk/l6OFDpCKiU9Gyhgrn02ATaSF2GlzYd8cg3Yv9uR cf/QB/J5pG4UuwRHOccSXzltLKhDwuzVn09O2KAemg46tZ2kY8DKz5LAsHliTvwmU62bA7zm6sL GkXlywxMhDQyynS5AFiaqDc32vrNSqAqgjPFHfNvcQgrzxdfC5XkXwtbtA1iIgvA=
X-Google-Smtp-Source: AGHT+IFYi640smacaP9G0ijkhnE3MOrTPj+CKLMfIPW/3I9mRlt+gjp3kAYKnlG1/IjQMCRV9CwaMg==
X-Received: by 2002:a17:906:1dd:b0:9a4:ea7a:d0bb with SMTP id 29-20020a17090601dd00b009a4ea7ad0bbmr5701342ejj.76.1693761366888; Sun, 03 Sep 2023 10:16:06 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id n18-20020a170906119200b009a219ecbaf1sm4957520eja.85.2023. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Sep 2023 10:16:06 -0700 (PDT)
Date: Sun, 03 Sep 2023 19:16:04 +0200
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <ZPS/VK+6Q8a4dHgA@snel>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="qFsdfNv5vO2fV2Yb"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CG2BWxOa6Ly8F0huOULIBd4hGEc>
Subject: [Sidrops] Signed Object signed with Ed25519 (RFC 8419 proof-of-concept)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Sep 2023 17:16:13 -0000

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.

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

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?

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.

Kind regards,


[1]: https://console.rpki-client.org/chloe.sobornost.net/rpki/RIPE-nljobsnijders/5m80fwYws_3FiFD7JiQjAqZ1RYQ.asa.html