[Mono-dev] Adding privatekey support to X509Store

[Pablo Ruiz]

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
ms.net's side.

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
      coupled.. ¿?
   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
   corresponding KeyContainerName..


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 ;)
>>
>> Greets.
>>
>> 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
>>> here.
>>>
>>> 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 :-).
>>>
>>> Thanks,
>>> Sebastien
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101020/2df20d93/attachment.html