Thank you, looking forward to.
Am 2019-08-02 um 11:59 schrieb Weijun Wang:
Great. This is also easy for me.
--Max
On Aug 2, 2019, at 5:20 PM, Michael Osipov <1983-01...@gmx.net> wrote:
On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01...@gmx.net> wrote:
Can you please explain why not
Great. This is also easy for me.
--Max
> On Aug 2, 2019, at 5:20 PM, Michael Osipov <1983-01...@gmx.net> wrote:
>
>>> On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01...@gmx.net> wrote:
>>>
>>> Can you please explain why not simple PEM bundles like OpenSSL have been
>>> chosen?
>>
>> Is
> > On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01...@gmx.net> wrote:
> >
> > Can you please explain why not simple PEM bundles like OpenSSL have been
> > chosen?
>
> Is that /etc/ssl/certs on Ubuntu? It's a directory containing a lot of PEM
> files. Do you prefer this style or a big file
Am 2019-06-03 um 17:07 schrieb Sean Mullan:
On 6/2/19 11:00 AM, Weijun Wang wrote:
But it still has to be a keystore. KeyStore is designed into SSL's
TrustManagerFactory. JSSE has system properties
javax.net.ssl.trustStore* pointing to it specifying file name,
keystore type, and password. If we
On 6/2/19 11:00 AM, Weijun Wang wrote:
But it still has to be a keystore. KeyStore is designed into SSL's TrustManagerFactory. JSSE has system
properties javax.net.ssl.trustStore* pointing to it specifying file name, keystore type, and password. If we
really use a PEM bundle, we might need to
OK, now I see, it will probably require a "pem" style, because PKCS12
stores X.509 certs too, "x509" would be too generic.
I must admit, I have never used the KeyStore interface directly, but I
can't image that it would be too hard to add virtual aliases for.
I'd be happy to review your ideas.
But it still has to be a keystore. KeyStore is designed into SSL's
TrustManagerFactory. JSSE has system properties javax.net.ssl.trustStore*
pointing to it specifying file name, keystore type, and password. If we really
use a PEM bundle, we might need to define a new keystore type "x509" or
Am 2019-06-02 um 12:36 schrieb Alan Bateman:
On 02/06/2019 09:48, Weijun Wang wrote:
:
There is also a compatibility impact as someone out there might be
opening cacerts directly.
A general point here is that the contents of the lib directory is not a
supported interface, a point that may be
On 02/06/2019 09:48, Weijun Wang wrote:
:
There is also a compatibility impact as someone out there might be opening
cacerts directly.
A general point here is that the contents of the lib directory is not a
supported interface, a point that may be relevant to the wording in the CSR.
-Alan
Am 2019-06-02 um 10:48 schrieb Weijun Wang:
Oops, I thought this is about another RFE
8193255: Root Certificates should be stored in text format and assembled at
build time
So, are you proposing to simply put the long PEM bundle as the final cacerts in
the release? In fact, I've proposed
Oops, I thought this is about another RFE
8193255: Root Certificates should be stored in text format and assembled at
build time
So, are you proposing to simply put the long PEM bundle as the final cacerts in
the release? In fact, I've proposed this before [1] but there were no response.
The main reason I put each cert in an individual file is for the file name,
which will be used as the alias in the cacerts keystore.
If all certs are in a single file, I know I can add attribute lines like
"alias: name [jdk]" before each PEM block but these extra lines are not well
defined and
Am 2019-05-31 um 05:32 schrieb Weijun Wang:
Please review the CSR at
https://bugs.openjdk.java.net/browse/JDK-8224891
(Oh, I hate the CSR having a different bug id.)
Basically, with this change, the cacerts file can be loaded with
KeyStore.getInstance("JKS" or "PKCS12").load(stream,
> On Jun 1, 2019, at 2:41 AM, Sean Mullan wrote:
>
> Rename it to "Migrate cacerts keystore to password-less PKCS12 format".
>
> In the Problem section, you may also want to add something like:
>
> - the certificates are public
> - The integrity protection is not really necessary since the
Rename it to "Migrate cacerts keystore to password-less PKCS12 format".
In the Problem section, you may also want to add something like:
- the certificates are public
- The integrity protection is not really necessary since the cacerts
file is part of the installed JDK, which should be
Hi Max,
> But you changed
>
>everyone (yes, everyone) has been loading cacerts with a null password
> and they are able to read all certificate inside.
>
> to
>
>everyone (yes, everyone) who loads cacerts with a null password is able to
> read all certificates inside.
>
> I *did* mean
Well, at least "almost everyone". The "everyone" sounds contradict with those
"existing applications that uses the hardcoded password".
--Max
> On May 31, 2019, at 5:43 PM, Weijun Wang wrote:
>
> It's not easy to find out the word difference after a CSR edit.
>
> But you changed
>
>
It's not easy to find out the word difference after a CSR edit.
But you changed
everyone (yes, everyone) has been loading cacerts with a null password and
they are able to read all certificate inside.
to
everyone (yes, everyone) who loads cacerts with a null password is able to
read
Hi Max,
I've already made some updates to the wording in the CSR.
In the specification section, it should probably also not mention the source
location src/java.base/share/lib/security/cacerts as it is about to be
eliminated by JDK-8193255. It should rather refer to
/lib/security/cacerts, I
19 matches
Mail list logo
