On Fri, 2 Apr 2021 04:03:50 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> Maybe we don't need to resolve it in this code change. If we look carefully >> at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 >> is using the signer's SKID in 10.1 as its own SKID and it has no AKID. >> Currently, keytool will generate a new SKID and use signer's SKID as AKID. >> If we really want to generate a certificate that's identical to the one in >> the RFC, we'll need a way to tell keytool to omit the AKID (something like >> "-ext akid=none"). > >> Maybe we don't need to resolve it in this code change. If we look carefully >> at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 >> is using the signer's SKID in 10.1 as its own SKID and it has no AKID. >> Currently, keytool will generate a new SKID and use signer's SKID as AKID. >> If we really want to generate a certificate that's identical to the one in >> the RFC, we'll need a way to tell keytool to omit the AKID (something like >> "-ext akid=none"). > > Better to use AKID for certification path building. I don't mean we will remove it by default. Just think there needs a way to remove either AKID or SKID, because we always generate them automatically. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281
