X.509 and PKCS#11 provider

Question

Sorry if I'm asking the stupid question, but there is something in JCE PKCS#11 provider architecture that I'm missing.
Let's say I have some hardware crypto module (e.g. SUN SCA-6000) and want to be sure that all crypto work is done in it. So I would configure PKCS#11 provider as the 1st (highest priority) entry in java.security file (and configure PKCS#11 to use my hardware crypto module).
Now, let's say I need to work with some X.509 certificate. When I check the supported algorithms of PKCS#11 and SUN providers, it looks like CertificateFactory.X509 algorithm is supported only by SUN provider, and not by PKCS#11 provider.
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#ALG
http://java.sun.com/javase/6/docs/technotes/guides/security/SunProviders.html#SUNProvider
So I wonder what does this essentially mean? Does it mean that even though I configured my HCM PKCS#11 provider, some crypto work is still done in other software modules (e.g. SUN provider)? Or may be SUN provider just "decomposes" these "high-level" algorithms to more "primitive" ones (e.g. Signature.SHA1withRSA) and essentially "proxies" all work to whatever provider supports these "primitive" algorithms - i.e. essentially to my HCM PKCS#11 provider?
Regards,
Alex

Answer 1

This is not a stupid question. Any question involving cryptography isn't stupid IMO, and one that includes hardware security modules (HSM) is even less stupid. :-)
That said, sabre150 has provided some information, and I'll try to add a little more from my experience.
HSM's are used primarily to perform "raw" cryptographic operations in highly constrained environments for security reasons - the goal is to ensure that symmetric keys (DES, 3DES, AES) or the private-keys of asymmetric key-pairs (RSA, DSA, EC) do not come out of the HSM into the main memory of the computer. This ensure that attackers cannot snoop the secrets from main memory.
So, the CertificateFactory in JCE is primarily used to do cryptographic operations with the digital certificate; however any operation involving just the digital certificate - and not its corresponding private-key - involves just the public-key in the certificate, the certificate attributes or certificate extensions. Since ALL information in a digital certificate is public information, there is no reason to waste HSM resources to perform X509 operations inside the security module. Not only is there nothing to protect in those operations, but as sabre150 pointed out, some old HSM's may not be able to handle them very well.
However, some HSM's are not just for security, but they also perform crypto-acceleration. This means that they can speed up raw cryptographic processing, and there is a benefit from having them perform even the public-key operations inside the HSM. However, the PKCS11 libraries will typically send in only the "raw" crypto operation into the HSM, leaving all the certificate-parsing work outside.
One final point: in order to make sure that you are definitely performing all secret operations inside an HSM, make sure you explicitly name the specific HSM provider for your crypto operations, otherwise the JVM may silently use a software module to perform the operation (if possible) and expose your secret in main memory.
Hope that helps.