On Fri, 2010-02-19 at 10:30 +0100, Mathias Tausig wrote: > Hy Sebastien (and everybody else)! > > Am 16.02.2010 15:37, schrieb Sebastien Pouliot: > > On Tue, 2010-02-16 at 15:17 +0100, Mathias Tausig wrote: > >> [...]. > > > >> The best concept that I could > >> make up so far, was to write a PKCS#11 wrapper and then subclass RSA. > > > > Yep, that's the right thing to do. > > > > Sebastien > > > > I have done that now (and no, I have not written a PKCS#11 wrapper in > the course of 2 days, I had already started the work before),
hahaha, I share your pain :-) > but I am > facing a slight problem. > In Mono's implementation of X509Certificate2, when the key is accessed > via the PrivateKey property, the ExportParameter method of > AssymetricAlgorithm ist invoked (see > http://anonsvn.mono-project.com/viewvc/tags/mono-2-6-1/mcs/class/System/System.Security.Cryptography.X509Certificates/X509Certificate2.cs > , line 213). When I implemented my Pkcs11RsaKey class, derived from RSA, > I chose to throw a CryptographicException whenever ExportParamters(true) > is called (since there is no possibility to actually read the private > parameters off a token). But if I do so, X509Certificate2.PrivateKey > returns null and the whole https - login process fails. > > Since you wrote the whole Cryptographic namespace, maybe you could shed > some light, why this call to ExportParameters is neccesary. > Do you see any workaround for this, apart from simply returning the > public parameters from ExportParameters(true), as I have done now, to > make it work as a proof of concept? It's a FX design flaw. The cryptographic hierarchy is sound (mostly) but some types (like RSACryptoServiceProvider) are short-circuiting the logic (which is a CryptoAPI limitation - or at least a mismatch with the FX design). IOW it means that RSACryptoServiceProvider (with its limitations) is unusable to some tasks (like SSL/TLS) unless you export the private key and re-load it into a (more compliant) RSAManaged instance. Sadly that does not play well with other, custom RSA instance. The fix is not overly complicated (i.e. detect if the instance is not a RSACryptoServiceProvider and use it without the current hack) unless your RSA implementation cannot provide [Decrypt|Encrypt]Value methods. This happens on some smartcards (I recall some of the G&D Starcos 2.3 about 10 years ago ;-) which insist on doing all padding operations inside the card. Those cards (unless they have a PKCS11 mode or support the special SSL padding*) are unusable for this purpose. Sebastien * that would require a much larger fix to get it working _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
