Marcin Cieślak

> Graph Explorer is optimized for learning experiences. It should not prevent us from doing useful things, though...

Looks like two conflicting meanings of "hash_algo" here: - do we say "[Ed25519 uses sha256 internally so if sha256 becomes weak, it should be disallowed](https://github.com/wbond/certvalidator/blob/b69d3b745b5af9e5ccd4b9781407ab7e82076d6b/certvalidator/validate.py#L306)"? - or do we say...

There are pre-hashed variants called Ed25519ph and Ed448ph, but [IETF decided not to assign OID values to the hashed variants yet](https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/shepherdwriteup/) and therefore cannot be used in the X.509 certificates.

Thank you for your insightful answer @MatthiasValvekens ! [RFC 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)](https://datatracker.ietf.org/doc/html/rfc8419) tells us exactly this: > [2.3](https://datatracker.ietf.org/doc/html/rfc8419#section-2.3)....

It does not break it, it is my own lousy programming that did it: Instead of a series of `if`s like you did, it assigns `verifyfunc` so that all verification...

I like it, too. But we need to update cms code for this, right?

> We could probably get away with not doing a 2.0 by throwing a `ValueError` if you try to get the hash_algo for Ed25519 or Ed448. Would we? Raising `ValueError`...

Now I wonder if https://github.com/wbond/certvalidator/blob/e53c06ad7f450e85808962a20f14825a43eccbc9/certvalidator/validate.py#L304 should not really access what we just called `.cms_hash_algo` ... suppose SHA-256 is considered weak one day - therefore we might consider `ed25519` to be...

I am fully with you @MatthiasValvekens on this one - I just wanted to look at the current status and didn't dare to think what the proper solution would be....

no, not a typo - just a tongue in cheek proposal to introduce yet another function for that :)