I think the main restriction you are likely to run into is with trust.
You can likely explain how this works far better than I can, but I think
essentially, you can't treat your multiple cert/key databases as
entirely separate for purposes of trust. Ie. if you try to trust one CA
in one DB/slot and not trust it in another DB/slot, you won't actually
be able to do that. I think pkcs11.txt will dictate where trust actually
ends up getting stored. But there will be one one value of trust flags
per cert per process at a time.
So, op should make sure the limitations with trust are understood before
trying to use this call. IMO, it's a big can of worms. Like John, I
would also recommend avoiding the use of multiple DBs per process. We
didn't go all the way and did not implement multiple trust domains,
which would be needed to accomplish true separation of trust.
Ideally, NSS should support multiple, completely separate
initializations per process, without any shared state between them. But
it wasn't designed that way. I think this could be fixed for the upper
layers like libnss/libssl/libsmime .
It is more difficult to fix for the lower layers, especially PKCS#11,
unless the different trust domains have no overlapping PKCS#11 shared
libs in common . I don't think the PKCS#11 semantics allow for multiple
independent states within one shared lib. So this would likely need to
be an extension of the spec.
Julien
On 1/10/2017 3:24 PM, Robert Relyea wrote:
On 01/10/2017 01:40 PM, John Dennis wrote:
On 01/10/2017 04:23 PM, Robert Relyea wrote:
2) To open additional databases you want to use SECMOD_OpenUserDB:
Bob, is SECMOD_OpenUserDB new?
No, it's been around for quite some time.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
