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 <weijun.wang at oracle.com> wrote:

>
> > On Dec 3, 2015, at 2:38 AM, Mandy Chung <mandy.chung at oracle.com> 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 <weijun.wang at oracle.com> 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
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20151202/ff1daedf/attachment.htm>