Short update on the state of the X-Wing RFC: Two weeks ago I contacted the authors, asking if they expect further changes. Which they don’t:
> "X-Wing is final and being shipped by Google and Apple presumably in > hardware." > - Bas Westerbaan and > "No significant changes, no changes planned or expected at all" > - Deirdre Connolly So while test vectors may still update (this is a TODO in the current draft), the risk of a last-minute change seems to be marginal. That said, I would love to get a first review of the overall implementation. Would you mind if I draft a PR? Shall I also create a corresponding issue in the bug tracker? > On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.w...@oracle.com> wrote: > > Cool. > > The current NamedPKCS8Key was designed based on an older approach where > modern asymmetric keys store private key data in a nested OCTET STRING > format. This pattern was introduced with EdDSA and XDH, and at the time of > JDK 24, we anticipated it would become the norm. > > However, things have changed significantly, as seen in the evolution of > draft-ietf-lamps-dilithium-certificates and > draft-ietf-lamps-kyber-certificates. The original design now needs to be > revised. While we’re still waiting for the IETF drafts to be finalized, we’re > already experimenting with changes in > https://github.com/openjdk/jdk/pull/24969. > > Hopefully, by the time X-Wing is finalized, we’ll already have a solution in > place. > > Thanks, > Weijun > >> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.sten...@gmail.com> >> wrote: >> >> Hi Weijun, >> >> I got a mostly working implementation based on NamedKEM [0], however to >> fulfil the spec I need your advice: >> >> The (current) X-Wing spec wants this PKCS#8 encoding: [1] >> >> However, the NamedPKCS8Key implementation always puts a nested OctetString >> into the private key part. [2] >> >> Note the difference here: >> * >> https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f >> * >> https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo >> >> I believe we need some more flexibility, as the ASN.1 standard leaves it >> open to the algorithms how a private key is formatted. What do you think how >> to approach this? >> >> Or should I ask the authors whether they have a specific encoding in mind? >> The ASN.1 definitions in the spec don’t seem to be complete yet. >> >> Best regards, >> Sebastian >> >> [0]: >> https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing >> [1]: >> https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D >> [2]: >> https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81 >> >>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.w...@oracle.com> wrote: >>> >>> >>> >>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.sten...@gmail.com> >>>> wrote: >>>> >>>> Hi Weijun, >>>> >>>> waiting for the final standard is understandable. The internals may still >>>> change, but the „outer hull“ of the PR is something that could already be >>>> discussed before - under these premises, would it make sense to already >>>> start a draft? Knowing that it won’t be merged yet? >>> >>> Feel free to start a draft if you’d like. I'll create a JBS issue once we >>> decide we want to include it in the JDK. >>> >>>> >>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including >>>> test vectors basically ready - just SHAKE256 currently borrowed from BC. >>>> >>>> I know that using SHAKE256 within the JDK is not a problem. However if we >>>> want to make it public, there simply *is no* XOF API in JCA. Technically >>>> the expand step of the KDF API can be used, but semantically that would be >>>> a misuse. Adding a completely new API is nothing I currently want to work >>>> on. >>> >>> I see. >>> >>>> >>>> Btw I am somewhat familiar with the development process as I have started >>>> contributing to the JDK in 2021 on cipher and NIO issues. [1] >>> >>> Nice to know. Sorry I didn't noticed that earlier. >>> >>> Thanks, >>> Weijun >>> >>>> >>>> Thank you, >>>> Sebastian >>>> >>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter >>>> >>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.w...@oracle.com> wrote: >>>>> >>>>> Hi Sebastian. >>>>> >>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel >>>>>> <sebastian.sten...@gmail.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> For the past few months I have been in contact with one of the authors >>>>>> of two spec drafts for future JOSE encryption standards [1] [2] with the >>>>>> latter of them relying on X-Wing. >>>>>> >>>>>> As the X-Wing spec doesn’t face significant changes any more (there have >>>>>> been some larger shifts in regards to secret key derivation last year), >>>>>> I am now tasked to create a prototype implementation for these RFCs. >>>>> >>>>> Thanks for your continued interest on enhancing OpenJDK. >>>>> >>>>> That said, we have a policy of not implementing algorithms that haven't >>>>> been standardized. So we won't be able to consider your contribution >>>>> until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not >>>>> sure how familiar you are with the OpenJDK developing process, but in the >>>>> meantime, you might find it helpful to read the OpenJDK Developers’ Guide >>>>> [1] and try working on something smaller first. >>>>> >>>>>> >>>>>> All the primitives for X-Wing are technically already there in OpenJDK, >>>>>> however two of them are private API (namely SHAKE256 and ML-KEM’s >>>>>> `KeyGen_internal(d, z)` [3]). So the question arises whether I can >>>>>> contribute an X-Wing KEM implementation to the JDK at the current state >>>>>> of the spec? >>>>> >>>>> It's acceptable to use private API inside OpenJDK when you are working on >>>>> OpenJDK itself. After all, we created them for this very purpose. >>>>> However, please keep in mind that this means you bind your X-Wing >>>>> implementation to the SunJCE/SunEC implementations. Usually, as a >>>>> higher-level algorithm, if its underlying algorithms could be implemented >>>>> by different security providers, it will be nice to make it >>>>> provider-neutral where possible. >>>>> >>>>>> >>>>>> Alternatively, can we make the two mentioned APIs public? >>>>> >>>>> No. These methods are too specific to their respective algorithms. We >>>>> prefer JCA/JCE-style API that is algorithm-neutral. >>>>> >>>>> [1] https://openjdk.org/guide/ >>>>> >>>>> Thanks, >>>>> Weijun >>>>> >>>>>> >>>>>> Cheers! >>>>>> Sebastian >>>>>> >>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/ >>>>>> [2]: >>>>>> https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07 >>>>>> [3]: >>>>>> https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536 >>>>>> >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
