[Mono-dev] PKCS12 and SecretBags

[Sebastien Pouliot]

Hello Jay,

Some important things to consider about PKCS12 (well Mono.Security.dll
in general)...

(a) some very core Mono tools (like SN) and libraries (including, even
if indirectly, mscorlib.dll) depends on this assembly. This imply that:

        i. we cannot break binary compatibility (we can add stuff, but
        we can't change it). Other (Mono/non-Mono) applications depends
        on it;
        
        ii. we do not want the assembly to get "too big" (as it gets
        loaded often). The Crimson project was created, in parts, to
        avoid "bloat" in Mono.Security.dll

(b) it exists because:

        * the BCL didn't expose enough functionality/details for some
        tools;
        
        and
        
        * we didn't feel "hiding" the extra classes (inside tools or
        other assemblies) was in the best interest of the community
        (some parts, like SSL/TLS and Authenticode, have proved very
        popular);

        
On Mon, 2006-12-18 at 16:09 -0700, Jay Miller wrote:
> I'm looking to make use of the SecretBag type in a PKCS12 file.  Mono
> does not currently support SecretBags in any explicit sense, which is to
> say that users cannot access them using the PKCS12 class.  This makes
> some sense because SecretBags aren't really defined in the standard.
> 
> Nonetheless, I would like to make use of both the PKCS12 class *and*
> SecretBags.  I was hoping I could run a couple of solutions by the
> developers and perhaps submit a patch if one sounds good.
> 
> Solution 1)
> 
> Arbitrarily decide that SecretBags will be of type byte[].  Add
> functions that mirror existing ones: AddSecretBag(), GetSecretBags(),
> RemoveSecretBag(), etc.  Add a member _secretBags that stores the
> current SecretBags.

I like this approach because:

1. everything converts into byte[]

2. it doesn't break anything and doesn't add too much stuff to the
class;

3. the class itself can (later) be updated to disallow adding/removing
some content (if that ever required);

> Solution 2)
> 
> Make the _safeBags member accessible outside the class to allow the user
> low-level access to the various bags stored by the instance.  This way a
> user could write her own GetXxx() class for SecretBags, CRLs, or
> whatever, simply by traversing the _safeBags list.

No immediate problem, but this would make it hard (if required in the
future) to "protect" (e.g. ensure something exist, or doesn't get
deleted) some contents.

> Solution 3)
> 
> Make PKCS12 more friendly as a base class such that users can derive
> PKCS12 and implement their own understandings of SecretBags, CRLs, or
> whatever else.  Private members will need to be made protected, maybe
> add a few 'virtual' keywords..

This will likely break binary compatibility.

> Hopefully one of these solutions (or another that I hadn't considered?)

Bring a copy of it into Crimson and experiment on it (e.g. like #3)
But I admit it's a lot more work ;-)

> will sound reasonable, as I really don't want to maintain an entire
> PKCS12 class just to add SecretBags!

Make sense :)

> Thanks very much for your time and comments!

Be sure to include unit tests with any patches ;-)

-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/