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

[Ties de Kock <[e-mail]>]

Hi all,

> On 3 Sep 2023, at 19:16, Job Snijders <job=[e-mail]> 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,
Ties

[0]: https://drive.google.com/file/d/119G55npxvc9BvPCjvfD1pOw8LxXAkyAq/view?usp=sharing