Darren, Just a clarification on your last comment. /" For Solaris hardware crypto like the SCA-6000 plugins in to the kernel part of the crypto framework and appears in userland via /usr/lib/libpkcs11.so.1
So the SCA-6000 CAN be accessed via NSS using PKCS#11 just like the UltraSPARC T1/T2 on chip crypto. "/ 1) It appears that T1/T2 crypto engine plugs into crypto framework and provides PKCS11 interfaces. What crypto capabilities exist in T1/T2 and why would anyone need to use SCA6000 on a T1/T2 based machine ? Are there certain algos that are present in one but not in other ? 2) If the crypto boundary in T1/T2 is within the chip, can we then assume FIPS 140-2 level 1 compliance ? Thanks, - sanjay Darren J Moffat wrote: > Sanjay Agrawal wrote: >> Let me see if I get this right: >> 1) NSS provides a wrapper for PKCS11 which means any PKCS11 provider >> can "plug-in" into NSS libraries. > > correct > >> 2) SCF is also a wrapper ( actually much more than a wrapper but I am >> using the term to draw a parallel between NSS and SCF) for PKCS11. > > correct > >> 3) NSS does NOT use SCF. It is a standalone library with its own >> plugin modules. So it can't use SCF enabled cryptos. For SCA6000 h/w >> acceleration to work, SCA6000 needs to provide PKCS11 interfaces that >> directly plugin into NSS. > > NSS does not use the Solaris libpkcs11 (PLEASE don't use the TLA SCF > it mapps to far to many things in Solaris and libscf has nothing to do > with the crypto framework) by default but can be configured to do so > using modutil(1). > > For Solaris hardware crypto like the SCA-6000 plugins in to the kernel > part of the crypto framework and appears in userland via > /usr/lib/libpkcs11.so.1 > > So the SCA-6000 CAN be accessed via NSS using PKCS#11 just like the > UltraSPARC T1/T2 on chip crypto. >
