Thread-topic: in-memory keychain or keychain-oidal data store?
It does help, thanks. It's also both probably more than I want to do and less than what would be necessary (to do it that way).
In my particular case, I am trying to provide a Mac OS X implementation of CertOpenStore < https://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/certopenstore.asp>, specifically when the provider is CERT_STORE_PROV_MEMORY. The Windows' HCERTSTORE concept includes the stores opened by CertOpenSystemStore, which have direct analogs to keychains on the Mac, but also these other miscellaneous collections based on files (PKCS #7 signed messages, PKCS #12 packets), LDAP queries, etc. You can enumerate the system stores, but you can't enumerate the memory stores (AFAICT), so there's some implicit security separation based on who actually has a HCERTSTORE handle, and in our case, we wish to ensure that security separation.
In trying to determine whether to (1) implement these stores in terms of an object that either points to a keychain or some array of certificate refs (though keys become tricky), or (2) go the whole 9 yards and implement a completely ephemeral memory-based DL that can store these items and have the certificate store always be a keychain. There are problems of ACLs that are handled nicely by the Windows APIs that would not be handled as nicely without going the whole 9 yards. Then again, the mechanism might create several disparate memory certificate stores dynamically, and the way I read what your comments, I'd have to register them statically, which doesn't seem possible. I'm also not sure in what context the DL would create it's memory; the context of the application (as that is the way the above operates). Another other hurdle, of course, is to avoid having look at open source code -- a limitation of my employer. Sample code, on the other hand (with appropriate re-use licensing) is fine.
At the moment, all I have to do is work with certificates, but that might change over time to include private keys and whatnot, and I'm trying to think through the ramifications.
Thanks again,
nh
-----Original Message-----
From: Ken McLeod [mailto:email@hidden]
Sent: Wednesday, September 27, 2006 10:53 AM
To: Nathan Herring
Cc: email@hidden
Subject: Re: in-memory keychain or keychain-oidal data store?
On Sep 25, 2006, at 3:12 PM, Nathan Herring wrote:
> SecKeychainOpen/Create expect the keychain to live in a file. Is there
> sample code for me to emulate an in-memory keychain using
> CSSM_DL_DbCreate and get all of the normal behavior of
> SecKeychainSearchXXX, SecIdentitySearchXXX, etc. The idea is that this
> in-memory store would get deleted upon either termination of the
> program or on an explicit release.
I don't think it's possible to create a non-file-based keychain through
SecKeychainOpen/Create at this point, since those APIs assume use of
the standard built-in CSP/DL module. We'd need to add a new API to
allow specification of a different DL module.
The other Sec* APIs should work transparently if you write your own DL
plugin to manage your in-memory database. As far as examples go, you
might want to look at the LDAP DL (libsecurity_ldap_dl), and the .Mac
DL (libsecurity_dotmacdl), both of which issue queries for certificates
to backend databases on the network and return the results. These DL
plugins are just bundles that can live anywhere in the filesystem (the
LDAP and .Mac DLs get installed in /System/Library/Security); their
location is registered when the module is installed via the MDS APIs.
You can grab these DL projects from
http://www.opensource.apple.com/darwinsource/, as well as the standard
file-based DL modules (libsecurity_apple_file_dl and
libsecurity_apple_cspdl). It would be a good idea for us to gut one of
these modules and make it into sample code, with instructions for
installation and use, at some point when we have more time. :-)
Since you can't use SecKeychainOpen to get a SecKeychainRef for a
database managed by a non-file-based DL, you'll currently need to
insert it in the keychain list manually (i.e. add a dictionary entry to
the DLDBSearchList array in
~/Library/Preferences/com.apple.security.plist, with the appropriate
GUID and subservice type for your DL module, and a "path" string that
identifies the database.) The DLDBSearchList array defines the set of
keychains which are searched by the Sec* APIs. Note that this list is
merged with the one for all users of the system (in
/Library/Preferences/com.apple.security.plist) to make up what you see
in Keychain Access.
Once you have an entry for your database in the DLDBSearchList array,
you can get its SecKeychainRef by iterating over all keychains and
picking the one with your module's GUID. (For each SecKeychain Ref in
the array returned by SecKeychainCopySearchList, get its
CSSM_DL_DB_HANDLE by calling SecKeychainGetDLDBHandle(), then use
CSSM_GetModuleGUIDFromHandle() to obtain the GUID for the DLHandle
field of the CSSM_DL_DB_HANDLE, and compare against the known GUID of
your module.)
Hope this helps...
-ken
>
> Thanks,
> nh
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
This email sent to email@hidden
