http://www.gsmworld.com/newsroom/press-releases/2010/5726.htm
As I said a million times before, on-line provisioning of HW tokens is the future. My take on this subject is (still...) defining a standard container based on "Open Hardware" because E2ES (End to End Security) cannot be abstracted (due to MACs); it is concrete by nature. That you as a "side-effect" gets a unified driver as well may turn out as the most significant thing in the end. Who (in their right mind...) *likes* smart card middleware? Due to the E2ES requirements, relics like "CertEnroll", <keygen>, and generateCRMFRequest() will hardly be around five years from now but there will be a veritable war regarding their replacements. Regarding NSS (which I have no deeper knowledge of), I wouldn't be surprised if most of the contenders will come to the same conclusion as I have which is that "Using" keys and "Provisioning" keys are quite distinct, and therefore do not particularly gain by being cast in a single API like PKCS #11, at least not if on-line E2ES is to be honored. PKCS #11 is probably OK as is, while on-line provisioning is more like starting at square one :-) thanx, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
