[External] : Re: PEM KeyStore Implementation

[Karl Scheibelhofer]

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