> On Dec 17, 2015, at 3:26 PM, Mandy Chung <[email protected]> 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 <[email protected]> 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
>>
>
