{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.}}
Feature Name
System Crypto Database
Summary
Allow NSS applications to access a shared crytpto database for each user (where user specific keys and certificates are stored) as well as access to a shared system database where shared system configuration is stored.
NSS upstream has defined the design for this here: [[
Owner
- Name: Bob relyea
- email: rrelyea@redhat.com
Current status
- Targeted release: [[Releases/Template:12 | Template:12 ]]
- Last updated: June 22, 2009
- Percentage of completion: 60%
Detailed Description
See Upstream wiki page.
Actual implementation will involve: 1) picking up NSS upstream changes. 2) Adding a Fedora module to initialize the Fedora definitions of where the user and system databases exist. 3) [future] Fedora module could be replaced with an IPA specific module which uses IPA to configure where various applications and user store their databases.
Benefit to Fedora
Applications can allow Fedora to configure much of their configuration information from a common location. Once in place it will be possible to configure all applications once without building one-off crypto configuration managers for each application. System can also handle common pem files as well.
Scope
Mostly my changes, as out-lined in the description. Once the feature is in place, applications can make minor changes to start using this new feature.
How To Test
Once in place, the feature can be tested with the NSS certutil command. Simply use certutil to list, add, and remove files from "sql:/etc/pki/nssdb" (that is specify -d sql:/etc/pki/nssdb on the certutil command line with the rest of the command), which would automatically trigger using the Fedora system locations.
If you own an application that uses NSS, you can change your application to open "sql:/etc/pki/nssdb" instead of your private NSS directory and you should have access to the user's shared keys.
Some applications can be faked out as well. I'll include instructions to convince FF and TB to use the system locations.
User Experience
When completed, the User should be able to access any of his keys and certs from any application without copying .p12 or .pem files around.
Dependencies
nss 3.12.4 plus patches.
Contingency Plan
If the feature is not complete, applications can continue to use their private directories to store keys and certificates into.
Documentation
Yes, see link given above.
Release Notes
Comments and Discussion