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

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

> On 4 Sep 2023, at 13:51, Ties de Kock <[e-mail]> wrote:
> 
> Hi Job,
> 
>> On 4 Sep 2023, at 13:26, Job Snijders <[e-mail] <mailto:[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 should have read a bit more there: I used the OIDs from
https://datatracker.ietf.org/doc/html/rfc5758#section-3.2 in my test objects.

> 
> 
>> 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?