JCA and JSSE Java API proposal

What is missing for sure:

• ProxyCerts support (including creation)
• Utility methods. I suppose it is nice to include methods to e.g. compare two DNs etc.

What I don't like:

• static creators are not OO
• a lot of objects/interafces is hanging around. It's the price for using JCA/JSSE and I think in Java case we should pay it.
• point (b) below, NOTE one.

a) Representation of material being the fundamental input for certificate validation - the trusted CAs
interface: TrustAnchorFactory
 -> Set<TrustAnchor> getTrustAnchors()
 
implementations:
 -> KeyStoreTAF
 -> OpensslDirectoryTAF

Creation via constructors.

b) CRLs and OCSP and other not natively included in Java certificate chain tests are to be handled by PKIXCertPathChecker extensions:
 -> OCSPCertPathChecker
 -> CRLCertPathChecker (likely more for different crl sources)
 
Creation via constructors.

NOTE: this overlaps with the functionality of classes from sun.security.provider.certpath package what is obviously bad. 
But this approach allows us to configure validation is a reasonable manner.
NOTE: it it is really needed we can add callback mechanism (extend PKIXCertPathChecker with callback registration and 
use the extended class as a base for real checkers).

c) Utility to create PKIXParameters which holds all settings related to cert chain verification.

class: PKIXParametersFactory
 -> static PKIXParameters create(TrustAnchorFactory, PKIXCertPathChcecker...)
 -> other methods might be added here to simplify the typical UNICORE/gLite/ARC settings, i.e.:
    static PKIXParameters createDefault4OpenSSL(String directory, ...)
  
d) Utility to create TrustManager

class: TrustManagerCreator
 -> static TrustManager create(PKIXParameters)
 -> static TrustManager[] createArray(PKIXParameters)
 
d') Utility to create credentials

interface: Credential
 -> KeyStore getAsKeyStore()
 -> KeyManager getAsKeymanager()
 
implementations:
 ->KeystoreCredential (dummy)
 ->PEMFileCredential (may be in different versions)

e) SSL connection verification

interface ConnectionVerificator
 -> void verifyConnection(SSLSocket, SSLContext) throws ...

implementations:
 -> CertHostnameVerificator 

f) Utility to create SocketFactory and ServerSocketFactory

class SocketFactoryCreator
 -> static ServerSocketFactory createSSF(KeyManager, TrustManager)
 -> static ServerSocketFactory createSSF(KeyManager, PKIXParameters)
 -> static SocketFactory createSF(KeyManager, TrustManager)
 -> static SocketFactory createSF(KeyManager, PKIXParameters)
 -> static SocketFactory createSF(KeyManager, TrustManager, ConnectionVerificator...)
 -> static SocketFactory createSF(KeyManager, PKIXParameters, ConnectionVerificator...)

impl. note: returned SocketFactory can use decorator pattern to add ConnectionVerificators to the socket created by the internal/standard SocketFactory.

NOTE: maybe better left decoration for users and only provide verificator? Might be better for users. 



================== EXAMPLE =====================

   //common code, an explicit version. Might be one line when using default settings.
   OpenSSLDirectoryTAF taf = new OpenSSLDirectoryTAF(/*params*/);
   CRLCertPathChecker crlChecker = new CRLCertPathChecker(/*params*/);
   PKIXParameters params = PKIXParametersFactory.create(taf, crlChecker);
      
   //for verification
   CertPathValidator validator = CertPathValidator.getInstance("PKIX");
   validator.validate(toBeChecked, params);
   
   //ssl connection creation
   KeyManager ks = new PEMFileCredential().getAsKeyManager();
   SSLServerSocketFactory sslSsf = SocketFactoryCreator.createSSF(ks, params);      

-- KrzysztofBenedyczak - 19-Oct-2010