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

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

Hi Job,

> On 4 Sep 2023, at 13:26, Job Snijders <[e-mail]> 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.

https://datatracker.ietf.org/doc/html/rfc7427#appendix-A.3.2


> 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,
Ties

> Kind regards,
> 
> Job
> 
> [1]: https://console.rpki-client.org/chloe.sobornost.net/rpki/RIPE-nljobsnijders/5m80fwYws_3FiFD7JiQjAqZ1RYQ.asa.html
> [2]: https://mailarchive.ietf.org/arch/msg/sidrops/CG2BWxOa6Ly8F0huOULIBd4hGEc/
> 
> 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?