RFR 8058778: New APIs for some keytool functions

Wang Weijun weijun.wang at oracle.com
Thu Dec 3 08:31:00 UTC 2015

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.


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 = "".

The "for example" comment of getExtensionValue() will be gone.


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?


More information about the security-dev mailing list