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).
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?
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).
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();
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
