Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Chris Hegarty]

Thanks Max,

I'm ok with this version, if you are. I'll include it in the final push.

-Chris.

On 02/12/15 15:13, Wang Weijun wrote:



On Dec 2, 2015, at 10:52 PM, Wang Weijun  wrote:

My fault to use an internal class. I should have simply used the hex encoding. 
Please wait a while and I'll send you a fix.

Thanks
Max

RFR 8058778: New APIs for some keytool functions

[Wang Weijun]

Hi All

This enhancement creates a new jdk.security.cert.X509CertificateBuilder API 
that does what keytool -genkeypair/-certreq/-gencert can do.

code changes:

  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/

spec:

  
http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html

You will be able to 

 KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
 kpg.initialize(2048);
 KeyPair ca = kpg.generateKeyPair();
 KeyPair user = kpg.generateKeyPair();

 X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
  .subject(new X500Principal("CN=ca"))
  .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
  .addExtension("BasicConstraints", "", true)
  .signatureAlgorithm("SHA256withRSA")
  .selfSign();

 byte[] request = X509CertificateBuilder.fromKeyPair(user)
  .subject(new X500Principal("CN=user"))
  .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
  .request();

 X509Certificate userCert = X509CertificateBuilder.asCA(
  ca.getPrivate(), caCert)
  .signatureAlgorithm("SHA256withRSA")
  .honorExtensions("all")
  .sign(request);

Thanks
Max

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Chris Hegarty]

Updated to remove all use of reflection. If someone really
wants to run S11N on an older JDK, then it is a simple
edit to uncomment/comment 3 lines.

http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/

-Chris.

On 02/12/15 14:15, Chris Hegarty wrote:

On 02/12/15 14:03, Alan Bateman wrote:


On 02/12/2015 12:08, Chris Hegarty wrote:

The regression tests in the jdk should be updated, where possible, to
use java.util.Base64.

http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/

Should S11N be updated to serialize with JDK 8 so that the core
reflection code isn't needed?


This is certainly possible and would make the test simpler, but
I followed the comments in the test ( it needs to be runnable on
older JDKs ).  I think this is a reasonable requirement since the
test contains bytes array that were generated on older JDKs. Of
course, the test could contain the older JDK code commented out.
If someone really wants to run it with 1.6, then they just make
the simple edits.

I'm ok with any of these solutions, or just removing the possibility
of running on older JDKs.

-Chris.

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Wang Weijun]

> On Dec 2, 2015, at 11:26 PM, Chris Hegarty  wrote:
> 
> Thanks Max,
> 
> I'm ok with this version, if you are. I'll include it in the final push.

Please.

--Max

> 
> -Chris.
> 
> On 02/12/15 15:13, Wang Weijun wrote:
>> 
>>> On Dec 2, 2015, at 10:52 PM, Wang Weijun  wrote:
>>> 
>>> My fault to use an internal class. I should have simply used the hex 
>>> encoding. Please wait a while and I'll send you a fix.
>>> 
>>> Thanks
>>> Max

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Wang Weijun]

My fault to use an internal class. I should have simply used the hex encoding. 
Please wait a while and I'll send you a fix.

Thanks
Max

> On Dec 2, 2015, at 10:15 PM, Chris Hegarty  wrote:
> 
> On 02/12/15 14:03, Alan Bateman wrote:
>> 
>> On 02/12/2015 12:08, Chris Hegarty wrote:
>>> The regression tests in the jdk should be updated, where possible, to
>>> use java.util.Base64.
>>> 
>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
>> Should S11N be updated to serialize with JDK 8 so that the core
>> reflection code isn't needed?
> 
> This is certainly possible and would make the test simpler, but
> I followed the comments in the test ( it needs to be runnable on
> older JDKs ).  I think this is a reasonable requirement since the
> test contains bytes array that were generated on older JDKs. Of
> course, the test could contain the older JDK code commented out.
> If someone really wants to run it with 1.6, then they just make
> the simple edits.
> 
> I'm ok with any of these solutions, or just removing the possibility
> of running on older JDKs.
> 
> -Chris.

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Wang Weijun]

> On Dec 2, 2015, at 10:52 PM, Wang Weijun  wrote:
> 
> My fault to use an internal class. I should have simply used the hex 
> encoding. Please wait a while and I'll send you a fix.
> 
> Thanks
> Max


S11N.java
Description: Binary data

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Alan Bateman]

On 02/12/2015 15:26, Chris Hegarty wrote:

Thanks Max,

I'm ok with this version, if you are. I'll include it in the final push.


This version looks okay to me too.

-Alan.

Re: RFR 8058778: New APIs for some keytool functions

[Mandy Chung]

Hi Max,

Is there any reason why this X509CertificateBuilder can’t be Java SE API?  Have 
you considered defining this builder API in 
java.security.cert.X509Certificate.Builder?

Mandy

> On Dec 2, 2015, at 6:36 AM, Wang Weijun  wrote:
> 
> Hi All
> 
> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API 
> that does what keytool -genkeypair/-certreq/-gencert can do.
> 
> code changes:
> 
>  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
>  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> 
> spec:
> 
>  
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> 
> You will be able to 
> 
> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> kpg.initialize(2048);
> KeyPair ca = kpg.generateKeyPair();
> KeyPair user = kpg.generateKeyPair();
> 
> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
>  .subject(new X500Principal("CN=ca"))
>  .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
>  .addExtension("BasicConstraints", "", true)
>  .signatureAlgorithm("SHA256withRSA")
>  .selfSign();
> 
> byte[] request = X509CertificateBuilder.fromKeyPair(user)
>  .subject(new X500Principal("CN=user"))
>  .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
>  .request();
> 
> X509Certificate userCert = X509CertificateBuilder.asCA(
>  ca.getPrivate(), caCert)
>  .signatureAlgorithm("SHA256withRSA")
>  .honorExtensions("all")
>  .sign(request);
> 
> Thanks
> Max
> 

Re: RFR 8058778: New APIs for some keytool functions

[larry mccay]

Hi Max -

Happy to see this enhancement - it would be great if it made its way into
SE and other JVM implementations as a result!

If not, what would the added dependency be for consuming applications?

thanks,

--larry

On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung  wrote:

> Hi Max,
>
> Is there any reason why this X509CertificateBuilder can’t be Java SE API?
> Have you considered defining this builder API in
> java.security.cert.X509Certificate.Builder?
>
> Mandy
>
> > On Dec 2, 2015, at 6:36 AM, Wang Weijun  wrote:
> >
> > Hi All
> >
> > This enhancement creates a new jdk.security.cert.X509CertificateBuilder
> API that does what keytool -genkeypair/-certreq/-gencert can do.
> >
> > code changes:
> >
> >  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >
> > spec:
> >
> >
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >
> > You will be able to
> >
> > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> > kpg.initialize(2048);
> > KeyPair ca = kpg.generateKeyPair();
> > KeyPair user = kpg.generateKeyPair();
> >
> > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >  .subject(new X500Principal("CN=ca"))
> >  .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >  .addExtension("BasicConstraints", "", true)
> >  .signatureAlgorithm("SHA256withRSA")
> >  .selfSign();
> >
> > byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >  .subject(new X500Principal("CN=user"))
> >  .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >  .request();
> >
> > X509Certificate userCert = X509CertificateBuilder.asCA(
> >  ca.getPrivate(), caCert)
> >  .signatureAlgorithm("SHA256withRSA")
> >  .honorExtensions("all")
> >  .sign(request);
> >
> > Thanks
> > Max
> >
>
>

Re: RFR 8058778: New APIs for some keytool functions

[larry mccay]

Applications that depend on such APIs are currently jumping through hoops
to provide the same functionality on multiple JVMs.
We have some nasty reflection based code in order to deal with build-time
dependencies.

It really should be formalized and made part of the SE API.
It will be great that I can not worry about the new API going away in
openJDK and oracle - but I'll need to continue to use the reflection
because of IBM.

Baby steps, maybe?

On Wed, Dec 2, 2015 at 8:25 PM, Wang Weijun  wrote:

>
> > On Dec 3, 2015, at 2:38 AM, Mandy Chung  wrote:
> >
> > Hi Max,
> >
> > Is there any reason why this X509CertificateBuilder can’t be Java SE API?
>
> Well, not much.
>
> When we first design the new API, it was meant to be a quick alternative
> to sun.security.tools.keytool.Main since that class will be invisible after
> jigsaw. So it's just a simple utility class and not fine polished.
>
> One unpolished is the certificate request. It's now just a byte[]. We
> might need a base class CertificateRequest and a child
> X509CertificateRequest and some getters.
>
> Another is the addExtension() method [1] that takes string values.
> Although I've tried my best to specify the precise format [1] I still think
> it's not mature enough as a Java SE API. Maybe I should just keep the
> addExtension(Extension) one [3] and create static methods in Extension (or
> shall I create a child named X509Extension) that generates known/unknown
> extension objects.
>
> Maybe my understanding is biased, but when I am thinking of a Java SE API,
> it contains multiple classes and a clean structure. On the other hand, a
> JDK-specific tool can be a huge single class with every method inside (just
> like keytool itself).
>
> > Have you considered defining this builder API in
> java.security.cert.X509Certificate.Builder?
>
> That sounds like a good place.
>
> Thanks
> Max
>
> [1]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean-
>
> [2]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions
>
> [3]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension-
>
> >
> > Mandy
> >
> >> On Dec 2, 2015, at 6:36 AM, Wang Weijun  wrote:
> >>
> >> Hi All
> >>
> >> This enhancement creates a new jdk.security.cert.X509CertificateBuilder
> API that does what keytool -genkeypair/-certreq/-gencert can do.
> >>
> >> code changes:
> >>
> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >>
> >> spec:
> >>
> >>
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >>
> >> You will be able to
> >>
> >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> >> kpg.initialize(2048);
> >> KeyPair ca = kpg.generateKeyPair();
> >> KeyPair user = kpg.generateKeyPair();
> >>
> >> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >> .subject(new X500Principal("CN=ca"))
> >> .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >> .addExtension("BasicConstraints", "", true)
> >> .signatureAlgorithm("SHA256withRSA")
> >> .selfSign();
> >>
> >> byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >> .subject(new X500Principal("CN=user"))
> >> .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >> .request();
> >>
> >> X509Certificate userCert = X509CertificateBuilder.asCA(
> >> ca.getPrivate(), caCert)
> >> .signatureAlgorithm("SHA256withRSA")
> >> .honorExtensions("all")
> >> .sign(request);
> >>
> >> Thanks
> >> Max
> >>
> >
>
>

RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Chris Hegarty]

The regression tests in the jdk should be updated, where possible, to 
use java.util.Base64.


http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/

-Chris.

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Paul Sandoz]

> On 2 Dec 2015, at 13:08, Chris Hegarty  wrote:
> 
> The regression tests in the jdk should be updated, where possible, to use 
> java.util.Base64.
> 
> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
> 

+1

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Alan Bateman]

On 02/12/2015 12:08, Chris Hegarty wrote:
The regression tests in the jdk should be updated, where possible, to 
use java.util.Base64.


http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
Should S11N be updated to serialize with JDK 8 so that the core 
reflection code isn't needed?


-Alan

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Chris Hegarty]

On 02/12/15 14:03, Alan Bateman wrote:


On 02/12/2015 12:08, Chris Hegarty wrote:

The regression tests in the jdk should be updated, where possible, to
use java.util.Base64.

http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/

Should S11N be updated to serialize with JDK 8 so that the core
reflection code isn't needed?


This is certainly possible and would make the test simpler, but
I followed the comments in the test ( it needs to be runnable on
older JDKs ).  I think this is a reasonable requirement since the
test contains bytes array that were generated on older JDKs. Of
course, the test could contain the older JDK code commented out.
If someone really wants to run it with 1.6, then they just make
the simple edits.

I'm ok with any of these solutions, or just removing the possibility
of running on older JDKs.

-Chris.

Re: RFR 8058778: New APIs for some keytool functions

[Wang Weijun]

> On Dec 3, 2015, at 2:38 AM, Mandy Chung  wrote:
> 
> Hi Max,
> 
> Is there any reason why this X509CertificateBuilder can’t be Java SE API?  

Well, not much.

When we first design the new API, it was meant to be a quick alternative to 
sun.security.tools.keytool.Main since that class will be invisible after 
jigsaw. So it's just a simple utility class and not fine polished.

One unpolished is the certificate request. It's now just a byte[]. We might 
need a base class CertificateRequest and a child X509CertificateRequest and 
some getters.

Another is the addExtension() method [1] that takes string values. Although 
I've tried my best to specify the precise format [1] I still think it's not 
mature enough as a Java SE API. Maybe I should just keep the 
addExtension(Extension) one [3] and create static methods in Extension (or 
shall I create a child named X509Extension) that generates known/unknown 
extension objects.

Maybe my understanding is biased, but when I am thinking of a Java SE API, it 
contains multiple classes and a clean structure. On the other hand, a 
JDK-specific tool can be a huge single class with every method inside (just 
like keytool itself).

> Have you considered defining this builder API in 
> java.security.cert.X509Certificate.Builder?

That sounds like a good place.

Thanks
Max

[1] 
http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean-

[2] 
http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions

[3] 
http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension-

> 
> Mandy
> 
>> On Dec 2, 2015, at 6:36 AM, Wang Weijun  wrote:
>> 
>> Hi All
>> 
>> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API 
>> that does what keytool -genkeypair/-certreq/-gencert can do.
>> 
>> code changes:
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.04
>> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
>> 
>> spec:
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
>> 
>> You will be able to 
>> 
>> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
>> kpg.initialize(2048);
>> KeyPair ca = kpg.generateKeyPair();
>> KeyPair user = kpg.generateKeyPair();
>> 
>> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
>> .subject(new X500Principal("CN=ca"))
>> .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
>> .addExtension("BasicConstraints", "", true)
>> .signatureAlgorithm("SHA256withRSA")
>> .selfSign();
>> 
>> byte[] request = X509CertificateBuilder.fromKeyPair(user)
>> .subject(new X500Principal("CN=user"))
>> .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
>> .request();
>> 
>> X509Certificate userCert = X509CertificateBuilder.asCA(
>> ca.getPrivate(), caCert)
>> .signatureAlgorithm("SHA256withRSA")
>> .honorExtensions("all")
>> .sign(request);
>> 
>> Thanks
>> Max
>> 
> 

Re: RFR 8058778: New APIs for some keytool functions

[Wang Weijun]

> On Dec 3, 2015, at 4:11 AM, larry mccay  wrote:
> 
> Hi Max -
> 
> Happy to see this enhancement - it would be great if it made its way into SE 
> and other JVM implementations as a result!

I replied to Mandy's mail.

> 
> If not, what would the added dependency be for consuming applications?

They will need the jdk.security.cert module. It will be in JRE (I added it into 
boot.modules) but if you want to create your own runtime you will need to add 
it using jimage or jlink things. (I am not a module expert but you know it).

Thanks
Max

> 
> thanks,
> 
> --larry
> 
> On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung  wrote:
> Hi Max,
> 
> Is there any reason why this X509CertificateBuilder can’t be Java SE API?  
> Have you considered defining this builder API in 
> java.security.cert.X509Certificate.Builder?
> 
> Mandy
> 
> > On Dec 2, 2015, at 6:36 AM, Wang Weijun  wrote:
> >
> > Hi All
> >
> > This enhancement creates a new jdk.security.cert.X509CertificateBuilder API 
> > that does what keytool -genkeypair/-certreq/-gencert can do.
> >
> > code changes:
> >
> >  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >
> > spec:
> >
> >  
> > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >
> > You will be able to
> >
> > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> > kpg.initialize(2048);
> > KeyPair ca = kpg.generateKeyPair();
> > KeyPair user = kpg.generateKeyPair();
> >
> > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >  .subject(new X500Principal("CN=ca"))
> >  .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >  .addExtension("BasicConstraints", "", true)
> >  .signatureAlgorithm("SHA256withRSA")
> >  .selfSign();
> >
> > byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >  .subject(new X500Principal("CN=user"))
> >  .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >  .request();
> >
> > X509Certificate userCert = X509CertificateBuilder.asCA(
> >  ca.getPrivate(), caCert)
> >  .signatureAlgorithm("SHA256withRSA")
> >  .honorExtensions("all")
> >  .sign(request);
> >
> > Thanks
> > Max
> >
> 
>