RFR: 8346129: Simplify EdDSA & XDH curve name usage

[Anthony Scarpino]

On Fri, 21 Feb 2025 21:11:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 78:
>> 
>>> 76:     private static List<String> aliasEd25519 = null;
>>> 77:     private static List<String> aliasXDH = null;
>>> 78:     private static List<String> aliasX25519 = null;
>> 
>> I am a little suspicious in this approach. At least this means for each "family" algorithm name like "EdDSA", we need to hardcode all its parameter set names here. Sounds not very sustainable.
>> 
>> An EdDSA key always has its `getAlgorithm` being "EdDSA" (at least inside SunEC) and its `getParams()` being the parameter set name. So it looks like it's enough if we do a name comparison on both.
>> 
>> Also, why no `aliasEd448` and `aliasX448` here?
>
> I have to give more thought on checking the algorithm and the `getParams()` against the list.  That may eliminate the need for the hardcoded list..
> 
> As to why 448 curves didn't need an alias, there is no other way to specify those curves other than their given name, like mentioned with the KPG/Ed25519 example in my comment to Sean

So using the `getAlgorithm()` and `getParams().getName()` work because there is a Key, but not for non-key situation such as `permits(Set.of(CryptoPrimitive.SIGNATURE), "EdDSA", null)`.

But this does bring up a point I had not considered.  The `permits()` call does not specify any key details other than the family name.  Perhaps it's ok for `permits()` to return a passing result with the information given.  But for a `permit()` that had more detail, it could return a failing result.   However, the KPG example does make me think that the consistency in the current PR is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966265139