> On Dec 6, 2015, at 4:43 AM, Mike StJohns <mstjo...@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 >> >> >> >
