RFR 8058778: New APIs for some keytool functions

[Wang Weijun]

> On Dec 6, 2015, at 4:43 AM, Mike StJohns <mstjohns at comcast.net> wrote:
> 
> Hi Max -
> 
> This comes under the heading of meta issues.  There are at least two forms of certificate request - PKCS10 (RFC2986) and CRMF (RFC4211).  There may be others (not sure that SCEP is a request per se vs a protocol).

I can change to request(type). Or we can keep the one without an argument which means always-pkcs10.

> 
> Both generate requests for X509 certificates so you can't differentiate on that basis.  So how do you wire this together to allow either/both to be provided by providers?

This Builder class is not a JCA engine, i.e. no Builder.getInstance().

> 
> For the "getSigXXX" methods - maybe define a "PKISignature" class with those methods instead?  Have it package:  signature value, signature algorithm, params and ideally "keyid" (to identify the public key necessary to verify this signature).

Can we add these methods later?

> 
> Lastly, there are a number of certificates that use only the SubjectAltName extension as their name.  You can end up with an empty X500Principal in the request in that case.  And you probably want a way of getting any request attributes: Collection<Attribute>  getRequestAttributes();

The sign() method blindly signs the request (should the method also include a requestType parameter or can it detect the type? maybe do not worry about it at the moment. we can add an overloaded method later) without looking at the content. If a real CA decides to use the API, it will need to call some other 3rd party tools to inspect the content.

Thanks
Max


> 
> Mike
> 
> 
> On 12/3/2015 3:31 AM, Wang Weijun wrote:
>> I tried.
>> 
>> It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better.
>> 
>> Extension
>> ---------
>> 
>> Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension:
>> 
>>   static Extension newExtension(String oid, byte[] content, boolean isCritical);
>>   static Extension newExtension(String oid, String value, boolean isCritical);
>> 
>> The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say,
>> 
>>   static final String KEYUSAGE = "2.5.29.16".
>> 
>> The "for example" comment of getExtensionValue() will be gone.
>> 
>> CertificateRequest
>> ------------------
>> 
>> A new CertificateRequest will be added which looks a lot like Certificate, it will have
>> 
>>   String getType();
>>   byte[] getEncoded();
>>   PublicKey getPublicKey();
>> 
>> and serialization but no verify(). It is always self-signed so the constructor can verify.
>> 
>> It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have
>> 
>>   byte[] getCertificationRequestInfo;
>>   X500Principal getSubjectX500Principal();
>>   byte[] getSignature();
>>   String getSigAlgName();
>>   String getSigAlgOID();
>>   byte[] getSigAlgParams();
>>   int getVersion();
>> 
>> (Or maybe not all getSigXXX() methods?)
>> 
>> CertificateFactory should have a new method
>> 
>>   CertificateRequest generateCertificateRequest(InputStream)
>> 
>> and CertificateFactorySpi needs a corresponding engine method throwing UOE.
>> 
>> The X509Factory implementation will read it.
>> 
>> 
>> All these sound straightforward, worth doing?
>> 
>> Thanks
>> Max
>> 
>> 
>> 
>