[xmlsec] keys manager question

[Tejkumar Arora]

Hi Aleksey,

  From the code, I've learnt that a keys manager contains:

     - keys store (openssl default keys manager uses
       simple keys store)
     - zero or more data stores
       (openssl default keys manager has one X509 data store)

A key has this data associated with it:
     - crypto material (id = "value"). Has Ptrs to crypto
       engine structures.
     - x509data (id = "X509Data"). Has cert chain.


For NSS, what I'd like to do is:
     default keys manager: use the NSS db as the keys store.
                               So, the keys store will just be a wrapper
                               around the NSS db.
                               Don't create a X509 data store.
                               Just use the NSS db where a X509 data
                               store is needed.

     key : don't explicitly maintain the X509Data. It can
           be constructed from the NSS db on demand.

The difference in approach between NSS & OpenSSL is natural
since NSS supports a central key & certs database, while OpenSSL
doesn't.

I'd like to know if you see any problems or issues with this
approach.


thanks,

-Tej


PS: Some feedback from my code browsing experience. I found that
plugging in crypto engine specific functionality through transforms
was very elegant - the closest that C can get to an C++ interface
based approach. The interface and implementation are cleanly
separated.

What confused me the most was issues surrounding keys manager,
keys data, keys data stores, simple keys manager, default keys
manager, simple keys store... etc...
It wasn't obvious which layer was doing what, and the interfaces
between layers were not crisp & clear (By layers, I mean the app,
the core library, and the crypto library). Having well-defined
interfaces between the layers, and placing all the interfaces
in a common place would help a lot in code readability.

Also, I felt that instead of using symbols.h to map to crypto specific
functionality, it would have been better to stick to the interface
based approach just like the transforms Klasses.
Backward compatibility won't be an issue as long as you add
new stuff at the end of the Klass structure.

Overall, xmlsec is a tremendous effort that is hard to
emulate - a valuable gift to the open src world. Thanks!!.