On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer
<karl.scheibelho...@gmx.net <mailto: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.
Best regards,
Karl
On Wed, Oct 4, 2023, 13:58 Sean Mullan <sean.mul...@oracle.com
<mailto: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
<https://openjdk.org/guide/#contributing-to-an-openjdk-project>
> On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer
<karl.scheibelho...@gmx.net
<mailto: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
<mailto: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
<mailto: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
<mailto: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$
<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
