I'm currently adding more tests, including for Legacy X448 encryption and I wonder, if it's really worth supporting non-standard legacy X488 (with PublicKeyAlgorithmTags.ECDH) and legacy Ed448 (with PublicKeyAlgorithmTags.EDDSA_LEGACY).
Originally I thought support for these would be desirable, since the PGPKeyConverter classes had partial support already, but the more I think about it I guess supporting those key types would lead to people generating them, causing interop issues with other implementations.
What do you think?
Removing support for non-standard keys would involve reverting some changes from #1663 (simplifying EDDSA_LEGACY branches to always assume Ed25519, removing X448 from the ECDH branches), and removing the LegacyX448KeyPairTest, LegacyEd448KeyPairTest classes.
Originally posted by @vanitasvitae in #1675 (comment)
I'm currently adding more tests, including for Legacy X448 encryption and I wonder, if it's really worth supporting non-standard legacy X488 (with PublicKeyAlgorithmTags.ECDH) and legacy Ed448 (with PublicKeyAlgorithmTags.EDDSA_LEGACY).
Originally I thought support for these would be desirable, since the PGPKeyConverter classes had partial support already, but the more I think about it I guess supporting those key types would lead to people generating them, causing interop issues with other implementations.
What do you think?
Removing support for non-standard keys would involve reverting some changes from #1663 (simplifying EDDSA_LEGACY branches to always assume Ed25519, removing X448 from the ECDH branches), and removing the LegacyX448KeyPairTest, LegacyEd448KeyPairTest classes.
Originally posted by @vanitasvitae in #1675 (comment)