[External] : Re: PEM KeyStore Implementation
Karl Scheibelhofer
karl.scheibelhofer at gmx.net
Wed Oct 18 10:00:08 UTC 2023
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.mullan at 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.mullan at oracle.com> wrote:
>
>
>
> On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer <karl.scheibelhofer at 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.mullan at 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.scheibelhofer at 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.scheibelhofer at 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.scarpino at 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.scarpino at 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20231018/6f6ef98b/attachment.htm>
More information about the security-dev
mailing list