RFR 8058778: New APIs for some keytool functions

Wang Weijun weijun.wang at oracle.com
Thu Dec 17 07:48:30 UTC 2015


> On Dec 17, 2015, at 3:26 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Max,
> 
> Very high level comments:
> - Builder::selfSign and Builder::sign are the two methods building the X509Certificate.
> 
> Both @throws java.lang.IllegalStateException - if the builder is initialized with one of the asCA methods 
> 
> It reads to me that there is no other method to generate a certificate from a builder created from Builder::fromKeyPair factory method.

Not sure what you are asking about.

selfSign() returns a self-signed certificate. If you want to get a CA-signed one, you run certificateRequest() and send the output byte[] to an asCA Builder and that builder can sign() it.

> 
> - is clearExtensions needed only for reusing the Builder?  

Yes.

> Would it be reasonable to require it to create a Builder that I suppose it’s not too expensive?  In that case, the clearExtensions is not needed.

Sounds correct.

> 
> Extension::newSubjectAlternativeNameExtension(boolean isCritical, List<?>... names)
> Extension::newIssuerAlternativeNameExtension(boolean isCritical, List<?>... names)
> Extension::newSubjectInformationAccessExtension(List<?>... accessDescriptions)
> Extension::newAuthorityInformationAccessExtension(List<?>... accessDescriptions)
> - this takes List<?> with 3 entries, each of which is of a specified type.
> 
> There may be other better alternatives to define this API.  A builder may fit well that can take 3 parameters for each name/accessDescription such that it can be statically checked.  Have you considered other options?

I designed the methods to be consistent with X509Certificate methods, like

   Collection<List<?>> getSubjectAlternativeNames()

and secretly hoped that if people can live with these methods they can also live with my new ones.

I know it's ugly but if enhanced I am not sure how far I should go. Should it be these?

   interface GeneralName {}
   static GeneralName newURIName(URI);
   static GeneralName newDnsName(String host);
   ...
   static newSubjectAlternativeNameExtension(boolean isCritical, GenralName... names);
   class AccessDescription { String oidMethods, GeneralName location);
   static newAuthorityInformationAccessExtension(AccessDescription... accessDescriptions);

I tried it but I don't like inventing too many new classes.

Thanks
Max

> 
> Mandy
> 
> 
>> On Dec 15, 2015, at 6:26 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>> 
>> Hi All
>> 
>> Here is an updated webrev
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/
>> 
>> Spec change is at
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html
>> 
>> These changes are made:
>> 
>> 1. The Builder is moved into java.security.cert.X509Certificate as an inner class
>> 
>> 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment.
>> 
>> 3. keytool directly calls X509Certificate.Builder now.
>> 
>> No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded.
>> 
>> Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed.
>> 
>> --Max
>> 
> 




More information about the security-dev mailing list