From Fedora Project Wiki
m (→‎Release Notes: removed superfluous ])
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!-- All fields on this form are required to be accepted by FESCo.
<!-- All fields on this form are required to be accepted by FESCo.
  We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
  We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
Line 10: Line 8:


== Summary ==
== 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.
Allow NSS applications to access a shared crypto 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: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
NSS upstream has defined the design for this here: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
Line 22: Line 20:


== Current status ==
== Current status ==
* Targeted release: Fedora 12
* Targeted release: Fedora ??
* Last updated: June 22, 2009
* Last updated: 2009-07-20
* Percentage of completion: 60%
* Percentage of completion: 60%
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->


== Detailed Description ==
== Detailed Description ==
Line 32: Line 28:


Actual implementation will involve:
Actual implementation will involve:
1) picking up NSS upstream changes.
* picking up NSS upstream changes.
2) Adding a Fedora module to initialize the Fedora definitions of where the user and system databases exist.
* 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.
* [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 ==
== 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.
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.
Fedora users which have a common certificate infrastruture (like a corporate of government CA) can install an admin supplied rpm which loads the corporate CA's into the system database, rather than having each user and application independently trust each CA.


== Scope ==
== Scope ==
Line 61: Line 60:


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
Fedora has started the process of bringing encryption related applications together to use and access the same set of keys and certificates. This means each application does not have to independently manage keys and certs, but simply use those which the user has already requires. You can access keys acquired from Firefox in your email client, for instance. Your already existing keys and certificates are automatically merged into the new database. How this feature works under the covers is described at https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX  and  https://wiki.mozilla.org/NSS_Shared_DB.
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
*


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/YourFeatureName]]  
* See [[Talk:Features/SystemCryptoDatabase]]  
   
   



Latest revision as of 08:13, 1 April 2010


Feature Name

System Crypto Database

Summary

Allow NSS applications to access a shared crypto 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: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Owner

  • email: rrelyea@redhat.com

Current status

  • Targeted release: Fedora ??
  • Last updated: 2009-07-20
  • Percentage of completion: 60%

Detailed Description

See Upstream wiki page.

Actual implementation will involve:

  • picking up NSS upstream changes.
  • Adding a Fedora module to initialize the Fedora definitions of where the user and system databases exist.
  • [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.

Fedora users which have a common certificate infrastruture (like a corporate of government CA) can install an admin supplied rpm which loads the corporate CA's into the system database, rather than having each user and application independently trust each CA.

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

Fedora has started the process of bringing encryption related applications together to use and access the same set of keys and certificates. This means each application does not have to independently manage keys and certs, but simply use those which the user has already requires. You can access keys acquired from Firefox in your email client, for instance. Your already existing keys and certificates are automatically merged into the new database. How this feature works under the covers is described at https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX and https://wiki.mozilla.org/NSS_Shared_DB.

Comments and Discussion