[Mono-dev] Adding privatekey support to X509Store
pablo.ruiz at gmail.com
Wed Oct 20 15:34:01 EDT 2010
After inspecting KeyPairPersistence, it looks like as I guessed, it allows
persisting a privateKey's parameters.. However, one must know the key's
KeyContianerName in order to pass an appropiate CspParameter to RSACsp..
till this point everything it's clear and it (externally) just looks like
However, looks like I will need to hack the following things:
1. Modify certmgr so if input it's a p12/pfx file, we set
p12.RSA.PersistInCsp = true, to force keypair persistence.
1. Actually setting PersistInCsp can also be donde inside's
Mono.Security.X509.X509Store, but this will require that privateKey is
passed to it from SSCX.X509Store, and look like making things a bit more
2. Also I will need to modify MonoSX.X509Store so it fills
X509Certificate.RSA with an RSACryptoSecurityProvider instance created by
passing a CspParameters class with the correct KeyContainerName.. But.. How
do you think it's the best way to associate a certificate name with it's
On Wed, Oct 20, 2010 at 7:52 PM, Pablo Ruiz <pablo.ruiz at gmail.com> wrote:
> Here's another question to the list:
> - What's exactly the purpose of KeyPairPersistence is? It looks like
> some sort of pseudo KeyContainer implementation which it's used by
> RSACryptoServiceProvider to save keys to disk.. however I'm still trying to
> look it's relationship to X509Stores..
> On Wed, Oct 20, 2010 at 4:06 PM, Pablo Ruiz <pablo.ruiz at gmail.com> wrote:
>> Hi Sebastien,
>> Great you replied, as you were the first one on my (short) list of 'people
>> to ask in case of emergency' ;)
>> Actually my (medium-long term) goal it's adding support for non-software
>> based crypto devices to mono, however I know this it's not a simple task to
>> undertake, so I will try to implement it on a step-by-step basis.
>> In fact, here it's, an initial short list of what I would like to do, it's
>> an initial list of goals, which has not been analyzed in deep.. so any
>> comment/ideas/proposals would be great:
>> - Adding (software-based) privateKey support to X509Stores, so one can
>> get an X509Certificate2 from an store and sign with it, just the same way it
>> works in MS.Net.
>> - Adding privateKey support to X509Stores, but using some sort of
>> provider model, similar to what has been done at mono's System.Messaging,
>> allowing user to switch certificate store's (or *CryptoServiceProvider's)
>> implementation.. (and or allowing us to have different x509store mechanism
>> on different OSs)
>> - Implementing one of such x509store/CSP sub-systems which allows to
>> use a hardware HSM, maybe by using pkcs11 or openssl-engine under the hood.
>> I already have knowledge on x509 programing on both win32 (c++/.net) and
>> linux/openssl, however, as you said, how things are assembled in mono can be
>> challenging as AFAIK there's also support for MacOSX/iPhone/etc.
>> As such, being able to add support for (software based) privateKey
>> handling to X509Stores looks like an not-so-hard initial task which will
>> allow me to start hacking around Mono.Security & System.Security so I can
>> learn how all those bits are put in place on mono.
>> I have already started hacking a bit, and by now I have it's just added
>> (to Mono.Security.dll) the ability to store private key's along with public
>> x509 certificate files, however I have a few doubts which:
>> - My initial idea was extending Mono.Security.X509.X509Store::Import
>> so if a certificate with exportable parameters are passed as input, it will
>> create (along with the DER certificate file) a new file ($UniqueName$.key),
>> which will contain the PKCS8 privateKey (encrypted using
>> ProtectedData.Protect). Obviously when accessing the certificate, the
>> oposite operation will be done to return a certificate with it's
>> corresponding privateKey if available.. However, I'm not completelly sure
>> about this approach.. ¿any recomendation in this area?
>> - Also, I would like to control which key's cannot be exported (just
>> the same as on win32), where would you store this infomartion (a bool or
>> something indicating that a key it's exportable).. ¿a $UniqueName$.xml file
>> along with cert and key?
>> - Also, I have doubts about how to associate certs and privateKeys
>> within the store. My current solution looks great for software based
>> privateKey, however, if/when at some point we do support hardware based
>> privateKey.. how can our X509Store know that a certificate's privateKey it's
>> 'usable' by using one specific x509-provider? Just storing this info on an
>> ¿XML? file along with the certificate itself seems a viable solution, but I
>> would like to share ideas with others..
>> - As far as I can see, a few Mono.Security's classes (X509Store among
>> them) are duplicated at mcs/class/corlib/Mono.Security.X509/.. ¿should I
>> copy my updated classes back to corlib/Mono.Security.X509?
>> - Regarding RSAManaged and RSACryptoServiceProvider, I know that on MS
>> side of things, X509Certificate2 has a CAPI binding (via PrivateKey
>> property) to the CSP store which holds the certificate (and it's
>> privateKey).. Right now I have not made a deep analisys of what it's the
>> best path to provide the same functionality, and any pointer on this subject
>> would be great ;)
>> This is what I have by now.. but undoubtly more issues will come.. ;)
>> I'm also available at irc (#mono) and I guess I will ask you some
>> questions there at some point, however, I will submit of our conclusions
>> here, of course ;)
>> On Wed, Oct 20, 2010 at 2:33 PM, Sebastien Pouliot <
>> sebastien.pouliot at gmail.com> wrote:
>>> Hello Pablo,
>>> On Wed, 2010-10-20 at 00:23 +0200, Pablo Ruiz wrote:
>>> > Hi,
>>> > I'm thinking on adding privateKey support for Mono.Security.X509Store,
>>> > so it can be (later) used as part of
>>> > System.Security.Cryptography.X509Certificates (on 2.0+). This is one
>>> > of the x509 related improvements I would like to add to mono's trunk.
>>> > However, I would like to discuss (by email and/or irc?) some of the
>>> > details first with some core member (some sort of mentoring) in order
>>> > to start in a good direction.
>>> You can either discuss this here, on this mailing-list, since it will
>>> leave a google-able trace of the discussion. Otherwise you can try to
>>> ping me on IRC (e.g. #monodev on GIMPNet) and we can post a resume later
>>> There are quite a few things to be aware in order to implement this
>>> (since it involves OS level features, tools and the class libraries). I
>>> think the best step would be, for you, to describe your understanding of
>>> the issues and I'll fill the blanks (in any :-).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list