On Fri, 21 Feb 2025 21:09:32 GMT, Anthony Scarpino <ascarp...@openjdk.org>
wrote:
>> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java
>> line 95:
>>
>>> 93: case "Ed25519" -> {
>>> 94: if (aliasEd25519 == null) {
>>> 95: aliasEd25519 = List.of("EdDSA", "Ed25519");
>>
>> Hmm. Should disabling Ed25519 also disable EdDSA? I can see the reverse, but
>> isn't Ed25519 meant to be a specific curve for EdDSA?
>
> This is complicated by `KeyPairGenerator.getInstance("EdDSA")` returning an
> Ed25519 key
>
> If someone were to check permits() with "EdDSA" the above code recognizes
> that "Ed25519" on the disabled algorithm list overlaps with "EdDSA". This is
> the first test in the test coded included in the PR.
Do we call `permits` before instantiating a `KeyPairGenerator`? What if people
call `kpg.initialize(NPS.Ed448)` after the instantiation?
In reality, I think it depends on how many `permits` calls there are. Modern
algorithms have the key same algorithm name and signature algorithm name. When
a signature operation is carried out, do we check on both the signature
algorithm and the key? It seems only checking on the key is enough. It's
actually more precise, since you can get the exact parameter set name there.
This is why I asked if the method is "never called on a family algorithm name".
When checking a key, if we always call `permits` on the parameter set name, we
get the precise result.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966259933
