Hi Sean, Yes, I can help with this new PEM API.
Let me know, when there is something to review. Best regards, Karl On Tue, Oct 17, 2023, 19:12 Sean Mullan <sean.mul...@oracle.com> wrote: > Hi Karl, > > I discussed your proposal with some other colleagues. > > We generally feel a PEM KeyStore would be a useful addition to the JDK. > This would alleviate usability issues that many users encounter when > configuring and deploying applications that store keys or certificates in > PEM files. > > However, we would like to first make sure that your PEM KeyStore > implementation will work well with the PEM API that we will be proposing > soon. We think this is a perfect opportunity to ensure they work well > together and would appreciate your help in reviewing and validating the API > - would you be interested in helping out? > > Once that is done, we can discuss next steps. > > Thanks, > Sean > > > On Oct 5, 2023, at 9:41 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > > > On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer <karl.scheibelho...@gmx.net> > wrote: > > Hi Sean, > > Yes, I had a look at the Contributing docs at the OpenJDK site before. I > also signed the OCA. > > > Great, thanks. > > > Honestly, I thought there would be some more reaction on the suggested PEM > KeyStore. It would really be good to discuss the topic with others. Is > there anything we can do to get others in sharing their thoughts on this? > > > I think there is a fair amount of interest in it, but reviewing something > significant like this takes a bit of time, as I mentioned in my prior > email. Also, if we do decide to accept the contribution, we want to make > sure it works well with the PEM API that we are working on - we hope to > have a draft of a JEP for that out in the next few weeks. So I think we > probably need a few weeks to review your contribution. > > > There is already a fair amount of documentation und unit tests. See > https://github.com/KarlScheibelhofer/java-crypto-tools/ . > > > Ok. > > —Sean > > > Best regards, > Karl > > On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mul...@oracle.com> wrote: > >> Hi Karl, >> >> The OpenJDK Developer’s Guide includes a helpful section on Contributing >> to an OpenJDK Project [1]. I suggest you read through that if you have not >> already. In particular, have you signed the OCA? I don’t want to review >> your code/contribution until that is done. >> >> For this particular contribution, I don’t think there has been enough >> discussion and evaluation from members of the Security project. This would >> be a fairly major contribution. Keep in mind that a contribution doesn’t >> mean the work ends there. There would need to be documentation, tests, and >> ongoing support for the foreseeable future. We need to think about these >> aspects every time we add a new feature, so there needs to be a strong >> motivation for doing it. >> >> Thanks, >> Sean >> >> [1] https://openjdk.org/guide/#contributing-to-an-openjdk-project >> >> > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer < >> karl.scheibelho...@gmx.net> wrote: >> > >> > Hi All, >> > >> > I would like to contribute my PEM KeyStore implementation to the >> > OpenJDK, including integration in the OpenJDK source and creating a >> > pull request. >> > What is the recommended way to do this? >> > Who can create a suitable ticket in OpenJDK to document the >> > enhancement and to track the progress? >> > >> > What are the requirements for a pull request to get merged? >> > >> > Best regards >> > >> > Karl >> > >> > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl Scheibelhofer >> > <karl.scheibelho...@gmx.net>: >> >> >> >> Hi Tony! >> >> >> >> When the PEM API implementation becomes available it would make sense >> >> to use it inside the PEM Keystore implementation. It will reduce the >> >> code (the internal classes PemReader und PemWriter may become >> >> obsolete), but it does not affect the functionality of the PEM >> >> keystore. Users of the PEM Keystore won't experience a difference. >> >> >> >> Let me know when there is something for the PEM API and I will see if >> >> I can assist. >> >> >> >> I would suggest starting with PEM Keystore now and not wait for the >> >> PEM API, because the time schedule for it seems vague. I would try to >> >> refactor my current PEM Keystore implementation to integrate in the >> >> OpenJDK sun.security.provider package. I do not expect any API changes >> >> or other compatibility issues with existing code. Then consult this >> >> group for feedback before creating a pull request. >> >> >> >> When the PEM API becomes available, rework the PEM Keystore >> >> implementation to use it internally. >> >> >> >> What do you think? >> >> >> >> Best regards >> >> >> >> Karl Scheibelhofer >> >> >> >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino >> >> <anthony.scarp...@oracle.com>: >> >>> >> >>> There are no doc links yet. >> >>> >> >>> Tony >> >>> >> >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote: >> >>>> Hi Tony, >> >>>> >> >>>> The motivation was mostly about reading PEM keys and certificates >> >>>> generated somewhere else. This is common practice in enterprise >> >>>> environments I work in. Because corporate key material is subject to >> >>>> centralized key management, including generation, backup and >> rollover. >> >>>> PEM is the format most software products can handle. For Java >> >>>> applications, having a PEM KeyStore would reduce the often required >> >>>> additional step of converting PEM key and certificate in a Java >> >>>> Keystore/PKCS#12. >> >>>> Even truststores handling is easier with individual PEM certificates >> >>>> instead of a single PKCS#12 Truststore. Adding or deleting a single >> >>>> file instead of replacing the complete PKCS#12 store is less error >> >>>> prone and cleaner to track in version control. The additional benefit >> >>>> of a MAC in PKCS#12 adds little to no security in most cases. >> >>>> And being text based, PEM is more version control friendly than >> binary PKCS#12. >> >>>> >> >>>> But to enable sound support of PEM, I also implemented writing PEM >> >>>> keys and certificates. This way, one can use the JDK keytool to >> >>>> generate key and certificate signing requests in PEM format. Getting >> >>>> the certificate from the CA in PEM, one can use PEM throughout the >> >>>> process. >> >>>> >> >>>> Do you have any links or documentation on the PEM API JEP that you >> mentioned? >> >>>> >> >>>> Thank you for your feedback and best regards >> >>>> >> >>>> Karl >> >>>> >> >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino >> >>>> <anthony.scarp...@oracle.com>: >> >>>>> >> >>>>> Hi Karl >> >>>>> >> >>>>> The keystore is interesting and may have some value. Was your use >> case >> >>>>> mostly reading PEM keys and certificates generated elsewhere for use >> >>>>> with a particular application, maybe webservers? Did you see value >> in >> >>>>> writing to this keystore from Java? >> >>>>> >> >>>>> On the topic of PEM, I hope before the end of the year to have a >> PEM API >> >>>>> JEP. I would be interested in your API feedback from your keystore >> >>>>> experiences. I think if this keystore contribution was accepted, it >> >>>>> should wait so it can use that API. >> >>>>> >> >>>>> thanks >> >>>>> >> >>>>> Tony >> >>>>> >> >>>>> >> >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: >> >>>>>> Hi, >> >>>>>> >> >>>>>> Working with Java and the JCA KeyStore for decades, I came across >> >>>>>> many situations where I thought it would be convenient to be >> >>>>>> able to load private keys and certificates in PEM format directly >> >>>>>> using the KeyStore API. Without the need to convert them to >> PKCS#12/JKS. >> >>>>>> >> >>>>>> You can find my implementation of a PEM KeyStore in >> >>>>>> >> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ >> . >> >>>>>> >> >>>>>> I wondered if it would make sense to integrate such an >> implementation >> >>>>>> in one of the standard providers of OpenJDK - like the SUN >> provider. >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Best regards >> >>>>>> >> >>>>>> Karl >> >> > >
