Re: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

> 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 c

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

> On May 31, 2019, at 11:15 PM, Sean Mullan wrote: > > On 5/30/19 8:49 PM, Weijun Wang wrote: >> Sure. How many info do you want to see? >> I can prepend `keytool -printcert` but that's too much. At least I think the >> extensions part is not needed. Also, I don't wish people reading the >>

Re: RFR 6722928: Support SSPI as a native GSS-API provider

> On May 31, 2019, at 11:42 PM, Nico Williams > wrote: > > On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote: >>> On May 31, 2019, at 3:09 AM, Nico Williams >>> wrote: >>> Can you >>> just use the empty realm like Heimdal and MIT do? >> >> This is for export(), where they use "WE

Re: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

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 installe

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

This looks good to me, and thanks for fixing the other instances of BUILD_TOOLS_JDK! /Erik On 2019-05-30 20:00, Weijun Wang wrote: New webrev at https://cr.openjdk.java.net/~weijun/8193255/webrev.01 Changes: 1. Textual info at the beginning of each cert 2. Makefile: indentation, BUILD_

Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote: > > On May 31, 2019, at 3:09 AM, Nico Williams > > wrote: > > Can you > > just use the empty realm like Heimdal and MIT do? > > This is for export(), where they use "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I > hesitate to introduce it.

Re: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

On 5/30/19 8:49 PM, Weijun Wang wrote: Sure. How many info do you want to see? I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert

RE: [11u] RFR: 8208698: Improved ECC Implementation

Hi Martin, thanks for the review. Makes sense to take the fix regarding the overflow check along. I requested approval for JDK-8217344, too, and will push both patches together. Best regards Christoph > -Original Message- > From: Doerr, Martin > Sent: Freitag, 31. Mai 2019 14:40 > To:

Re: RFR 6722928: Support SSPI as a native GSS-API provider

> On May 31, 2019, at 3:09 AM, Nico Williams wrote: > > On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote: >> Practically, if I always add the current realm to a name without a realm, and >> then always remove the realm if it's the current realm when calling >> InitiateSecurityContex

RE: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

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

Re: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

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 > > everyone

Re: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

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 all

RE: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

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 th

RE: RFR 8193255: Root Certificates should be stored in text format and assembled at build time

Hi Max, this looks all good to me now :) Best regards Christoph > -Original Message- > From: build-dev On Behalf Of > Weijun Wang > Sent: Freitag, 31. Mai 2019 05:01 > To: Erik Joelsson > Cc: security-dev@openjdk.java.net; build-dev d...@openjdk.java.net> > Subject: Re: RFR 8193255: R