m (internal link cleaning) |
|||
(21 intermediate revisions by 3 users not shown) | |||
Line 8: | Line 8: | ||
== Owner == | == Owner == | ||
* Name: | * Name: PKI Developers | ||
* email: | * email: pki DASH devel AT redhat DOT com | ||
== Current status == | == Current status == | ||
* Targeted release: Fedora 13 | * Targeted release: Fedora 13 | ||
* Last updated: | * Last updated: 02-04-2010 | ||
* Percentage of completion: | * Percentage of completion: 100% | ||
== Detailed Description == | == Detailed Description == | ||
Line 62: | Line 62: | ||
== Scope == | == Scope == | ||
* Code complete. Awaiting Package Review and fedora-cvs approval on | * Code complete. Awaiting Package Review and fedora-cvs approval on one remaining package: | ||
** pki-tps | ** pki-tps | ||
== How To Test == | == How To Test == | ||
Hardware Requirements | '''Hardware Requirements''' | ||
At least Intel Pentium 4 or faster with 1GB RAM and 10GB disk | |||
'''System Prep''' | |||
Expected Results | Update system with all the latest Fedora packages | ||
'''Testing and Expected Results''' | |||
The following list of tests is not comprehensive by any means and not in | |||
any order but will give the user the means and the ideas of how to test a PKI system: | |||
* Install pki-ca,pki-kra,pki-ocsp,pki-tps,pki-tks packages via yum | |||
* Follow the default instance creation procedures to create a base instance of the various sub-systems. | |||
* Once the setup is complete, perform these tests: | |||
** Issue different types of certificates like user certs, server certs | |||
** Revoke a few certificates | |||
** Generate a CRL | |||
** Customize profiles based on different types of extensions and constraints | |||
*** Generate certs to have say for example an AIA extension | |||
** Submit a CRL to the OCSP responder | |||
** Check Java Console access | |||
*** Use the Java console to perform various configuration updates such as; | |||
**** Adding/editing/deleting additional CRL issuing points | |||
**** ACL configurations | |||
**** Adding/editing/deleting profiles | |||
**** Log file configurations | |||
** Certificate enrollment via different types of browsers such as IE and Firefox | |||
** Smartcard enrollment and format operations | |||
* Also see this for configuring/testing: | |||
** [[QA:Testcase_Dogtag_Certificate_System_Configure]] | |||
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | ||
Line 94: | Line 116: | ||
== User Experience == | == User Experience == | ||
''' | |||
Dogtag Certificate System is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. | |||
This full-featured PKI solution includes a complete Smartcard Management system as well as support for all aspects of certificate lifecycle management including: | |||
* '''Certificate Authority (CA)''' | |||
** A required PKI subsystem which issues, renews, revokes, and publishes certificates as well as compiling and publishing Certificate Revocation Lists (CRLs). The Dogtag Certificate Authority can be configured as a self-signing Certificate Authority (CA), where it is the root CA, or it can act as a subordinate CA, where it obtains its own signing certificate from a public CA. | |||
* '''Data Recovery Manager (DRM)''' | |||
** An optional PKI subsystem that can act as a Key Recovery Authority (KRA). When configured in conjunction with the Dogtag Certificate Authority, the Dogtag Data Recovery Manager stores private encryption keys as part of the certificate enrollment process. The key archival mechanism is triggered when a user enrolls in the PKI and creates the certificate request. Using the Certificate Request Message Format (CRMF) request format, a request is generated for the user's private encryption key. This key is then stored in the Dogtag Data Recovery Manager which is configured to store keys in an encrypted format that can only be decrypted by several agents requesting the key at one time, providing for protection of the public encryption keys for the users in the PKI deployment. | |||
** Note that the Dogtag Data Recovery Manager archives encryption keys; it does not archive signing keys, since such archival would undermine nonrepudiation properties of signing keys. | |||
* '''Online Certificate Status Protocol (OCSP) Manager''' | |||
** An optional PKI subsystem that can act as a stand-alone Online Certificate Status Protocol (OCSP) service. The Dogtag Online Certificate Status Protocol Manager performs the task of an online certificate validation authority by enabling OCSP-compliant clients to do real-time verification of certificates. Note that an online certificate-validation authority is often referred to as an OCSP Responder. | |||
** Although the Dogtag Certificate Authority is already configured with an internal OCSP service. An external OCSP Responder is offered as a separate subsystem in case the user wants the OCSP service provided outside of a firewall while the Dogtag Certificate Authority resides inside of a firewall, or to take the load of requests off of the Dogtag Certificate Authority. | |||
** The Dogtag Online Certificate Status Protocol Manager can receive Certificate Revocation Lists (CRLs) from multiple Dogtag Certificate Authority servers, and clients can query the Dogtag Online Certificate Status Protocol Manager for the revocation status of certificates issued by all of these Dogtag Certificate Authority servers. | |||
** When an instance of Dogtag Online Certificate Status Protocol Manager is set up with an instance of Dogtag Certificate Authority, and publishing is set up to this Dogtag Online Certificate Status Protocol Manager, CRLs are published to it whenever they are issued or updated. | |||
* '''Registration Authority (RA)''' | |||
** An optional PKI subsystem that acts as a front-end for authenticating and processing enrollment requests, PIN reset requests, and formatting requests. | |||
** Dogtag Registration Authority communicates over SSL with the Dogtag Certificate Authority to fulfill the user's requests. | |||
* '''Token Key Service (TKS)''' | |||
** An optional PKI subsystem that manages the master key(s) and the transport key(s) required to generate and distribute keys for hardware tokens. Dogtag Token Key Service provides the security between tokens and an instance of Dogtag Token Processing System, where the security relies upon the relationship between the master key and the token keys. A Dogtag Token Processing System communicates with a Dogtag Token Key Service over SSL using client authentication. | |||
** Dogtag Token Key Service helps establish a secure channel (signed and encrypted) between the token and the Dogtag Token Processing System, provides proof of presence of the security token during enrollment, and supports key changeover when the master key changes on the Dogtag Token Key Service. Tokens with older keys will get new token keys. | |||
** Because of the sensitivity of the data that Dogtag Token Key Service manages, Dogtag Token Key Service should be set up behind the firewall with restricted access. | |||
* '''Token Processing System (TPS)''' | |||
** An optional PKI subsystem that acts as a Registration Authority (RA) for authenticating and processing enrollment requests, PIN reset requests, and formatting requests from the Enterprise Security Client (ESC). | |||
** Dogtag Token Processing System is designed to communicate with tokens that conform to Global Platform's Open Platform Specification. | |||
** Dogtag Token Processing System communicates over SSL with various PKI backend subsystems (including the Dogtag Certificate Authority, the Dogtag Data Recovery Manager, and the Dogtag Token Key Service) to fulfill the user's requests. | |||
** Dogtag Token Processing System also interacts with the token database, an LDAP server that stores information about individual tokens. | |||
* '''Enterprise Security Client (ESC)''' | |||
** Enterprise Security Client allows the user to enroll and manage their cryptographic smartcards. | |||
** The ESC client is available on Linux, Macintosh, and Windows platforms. | |||
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | |||
== Dependencies == | == Dependencies == | ||
Line 215: | Line 274: | ||
== Contingency Plan == | == Contingency Plan == | ||
N/A | |||
N/A as this is a completely new feature and failing to implement it will not affect any other part of the distribution. | |||
== Documentation == | == Documentation == | ||
Line 226: | Line 286: | ||
* See [[Talk:Features/DogtagCertificateSystem]] | * See [[Talk:Features/DogtagCertificateSystem]] | ||
[[Category: | [[Category:FeatureAcceptedF13]] | ||
<!-- When your feature page is completed and ready for review --> | <!-- When your feature page is completed and ready for review --> | ||
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | ||
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | ||
<!-- A pretty picture of the page category usage is at: | <!-- A pretty picture of the page category usage is at: [[Features/Policy/Process]] --> |
Latest revision as of 08:07, 18 September 2016
Dogtag Certificate System
Summary
Dogtag Certificate System is an enterprise-class open source Certificate Authority (CA) supporting all aspects of certificate lifecycle management including key archival, OCSP and smartcard management.
Owner
- Name: PKI Developers
- email: pki DASH devel AT redhat DOT com
Current status
- Targeted release: Fedora 13
- Last updated: 02-04-2010
- Percentage of completion: 100%
Detailed Description
Details can be found here.
Benefit to Fedora
All new feature. Full featured open source PKI comprised of 6 major subsystems (25 packages):
- Certificate Authority (CA)
- Data Recovery Manager (DRM)
- OCSP Manager (OCSP)
- Registration Authority (RA)
- Token Key Service (TKS)
- Token Processing System (TPS)
Package List:
- tomcatjss
- osutil (x86, x86_64, ppc, ppc64)
- pki-symkey (x86, x86_64, ppc, ppc64)
- pki-native-tools (x86, x86_64, ppc, ppc64)
- pki-util
- pki-util-javadoc
- pki-java-tools
- pki-java-tools-javadoc
- pki-selinux
- pki-setup
- dogtag-pki-common-ui
- pki-common
- pki-common-javadoc
- pki-silent
- dogtag-pki-ca-ui
- pki-ca
- dogtag-pki-kra-ui
- pki-kra
- dogtag-pki-ocsp-ui
- pki-ocsp
- dogtag-pki-tks-ui
- pki-tks
- dogtag-pki-ra-ui
- pki-ra
- dogtag-pki-tps-ui
- pki-tps (x86, x86_64, ppc, ppc64)
- pki-tps-devel
- dogtag-pki-console-ui
- pki-console
Scope
- Code complete. Awaiting Package Review and fedora-cvs approval on one remaining package:
- pki-tps
How To Test
Hardware Requirements
At least Intel Pentium 4 or faster with 1GB RAM and 10GB disk
System Prep
Update system with all the latest Fedora packages
Testing and Expected Results
The following list of tests is not comprehensive by any means and not in any order but will give the user the means and the ideas of how to test a PKI system:
- Install pki-ca,pki-kra,pki-ocsp,pki-tps,pki-tks packages via yum
- Follow the default instance creation procedures to create a base instance of the various sub-systems.
- Once the setup is complete, perform these tests:
- Issue different types of certificates like user certs, server certs
- Revoke a few certificates
- Generate a CRL
- Customize profiles based on different types of extensions and constraints
- Generate certs to have say for example an AIA extension
- Submit a CRL to the OCSP responder
- Check Java Console access
- Use the Java console to perform various configuration updates such as;
- Adding/editing/deleting additional CRL issuing points
- ACL configurations
- Adding/editing/deleting profiles
- Log file configurations
- Use the Java console to perform various configuration updates such as;
- Certificate enrollment via different types of browsers such as IE and Firefox
- Smartcard enrollment and format operations
- Also see this for configuring/testing:
User Experience
Dogtag Certificate System is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments.
This full-featured PKI solution includes a complete Smartcard Management system as well as support for all aspects of certificate lifecycle management including:
- Certificate Authority (CA)
- A required PKI subsystem which issues, renews, revokes, and publishes certificates as well as compiling and publishing Certificate Revocation Lists (CRLs). The Dogtag Certificate Authority can be configured as a self-signing Certificate Authority (CA), where it is the root CA, or it can act as a subordinate CA, where it obtains its own signing certificate from a public CA.
- Data Recovery Manager (DRM)
- An optional PKI subsystem that can act as a Key Recovery Authority (KRA). When configured in conjunction with the Dogtag Certificate Authority, the Dogtag Data Recovery Manager stores private encryption keys as part of the certificate enrollment process. The key archival mechanism is triggered when a user enrolls in the PKI and creates the certificate request. Using the Certificate Request Message Format (CRMF) request format, a request is generated for the user's private encryption key. This key is then stored in the Dogtag Data Recovery Manager which is configured to store keys in an encrypted format that can only be decrypted by several agents requesting the key at one time, providing for protection of the public encryption keys for the users in the PKI deployment.
- Note that the Dogtag Data Recovery Manager archives encryption keys; it does not archive signing keys, since such archival would undermine nonrepudiation properties of signing keys.
- Online Certificate Status Protocol (OCSP) Manager
- An optional PKI subsystem that can act as a stand-alone Online Certificate Status Protocol (OCSP) service. The Dogtag Online Certificate Status Protocol Manager performs the task of an online certificate validation authority by enabling OCSP-compliant clients to do real-time verification of certificates. Note that an online certificate-validation authority is often referred to as an OCSP Responder.
- Although the Dogtag Certificate Authority is already configured with an internal OCSP service. An external OCSP Responder is offered as a separate subsystem in case the user wants the OCSP service provided outside of a firewall while the Dogtag Certificate Authority resides inside of a firewall, or to take the load of requests off of the Dogtag Certificate Authority.
- The Dogtag Online Certificate Status Protocol Manager can receive Certificate Revocation Lists (CRLs) from multiple Dogtag Certificate Authority servers, and clients can query the Dogtag Online Certificate Status Protocol Manager for the revocation status of certificates issued by all of these Dogtag Certificate Authority servers.
- When an instance of Dogtag Online Certificate Status Protocol Manager is set up with an instance of Dogtag Certificate Authority, and publishing is set up to this Dogtag Online Certificate Status Protocol Manager, CRLs are published to it whenever they are issued or updated.
- Registration Authority (RA)
- An optional PKI subsystem that acts as a front-end for authenticating and processing enrollment requests, PIN reset requests, and formatting requests.
- Dogtag Registration Authority communicates over SSL with the Dogtag Certificate Authority to fulfill the user's requests.
- Token Key Service (TKS)
- An optional PKI subsystem that manages the master key(s) and the transport key(s) required to generate and distribute keys for hardware tokens. Dogtag Token Key Service provides the security between tokens and an instance of Dogtag Token Processing System, where the security relies upon the relationship between the master key and the token keys. A Dogtag Token Processing System communicates with a Dogtag Token Key Service over SSL using client authentication.
- Dogtag Token Key Service helps establish a secure channel (signed and encrypted) between the token and the Dogtag Token Processing System, provides proof of presence of the security token during enrollment, and supports key changeover when the master key changes on the Dogtag Token Key Service. Tokens with older keys will get new token keys.
- Because of the sensitivity of the data that Dogtag Token Key Service manages, Dogtag Token Key Service should be set up behind the firewall with restricted access.
- Token Processing System (TPS)
- An optional PKI subsystem that acts as a Registration Authority (RA) for authenticating and processing enrollment requests, PIN reset requests, and formatting requests from the Enterprise Security Client (ESC).
- Dogtag Token Processing System is designed to communicate with tokens that conform to Global Platform's Open Platform Specification.
- Dogtag Token Processing System communicates over SSL with various PKI backend subsystems (including the Dogtag Certificate Authority, the Dogtag Data Recovery Manager, and the Dogtag Token Key Service) to fulfill the user's requests.
- Dogtag Token Processing System also interacts with the token database, an LDAP server that stores information about individual tokens.
- Enterprise Security Client (ESC)
- Enterprise Security Client allows the user to enroll and manage their cryptographic smartcards.
- The ESC client is available on Linux, Macintosh, and Windows platforms.
Dependencies
BuildRequires
Build-time packages already included in Fedora:
- ant
- apr-devel
- apr-util-devel
- cyrus-sasl-devel
- httpd-devel >= 2.2.3
- idm-console-framework
- java-devel >= 1:1.6.0
- jpackage-utils
- jss >= 4.2.6
- ldapjdk
- m4
- make
- mozldap-devel
- nspr-devel >= 4.6.99
- nss-devel >= 3.12.3.99
- pcre-devel
- pkgconfig
- policycoreutils
- selinux-policy-devel
- svrcore-devel
- tomcat5
- velocity
- xalan-j2
- xerces-j2
- zlib
- zlib-devel
Build-time Dogtag packages new to Fedora:
- osutil
- pki-common
- pki-symkey
- pki-util
- tomcatjss
Requires
Runtime packages already included in Fedora:
- idm-console-framework
- java >= 1:1.6.0
- jpackage-utils
- jss >= 4.2.6
- ldapjdk
- mod_nss >= 1.0.7
- mod_perl
- mod_perl >= 1.99_16
- mozldap
- mozldap >= 6.0.2
- mozldap-tools
- nss >= 3.12.3.99
- nss-tools >= 3.12.3.99
- perl-DBD-SQLite
- perl-DBI
- perl-HTML-Parser
- perl-HTML-Tagset
- perl-Parse-RecDescent
- perl-URI
- perl-XML-NamespaceSupport
- perl-XML-Parser
- perl-XML-Simple
- policycoreutils
- selinux-policy-targeted
- sendmail
- sqlite
- tomcat5
- velocity
- xalan-j2
- xerces-j2
Runtime Dogtag packages new to Fedora:
- osutil
- pki-ca-ui
- pki-common
- pki-common-ui
- pki-console-ui
- pki-java-tools
- pki-kra-ui
- pki-native-tools
- pki-ocsp-ui
- pki-ra-ui
- pki-selinux
- pki-setup
- pki-silent
- pki-symkey
- pki-tks-ui
- pki-tps-ui
- pki-util
- tomcatjss
Top-level Dogtag packages new to Fedora:
- pki-ca
- pki-console
- pki-kra
- pki-ocsp
- pki-ra
- pki-tks
- pki-tps
Dogtag Subpackages new to Fedora:
- osutil-debuginfo
- pki-common-javadoc
- pki-java-tools-javadoc
- pki-native-tools-debuginfo
- pki-symkey-debuginfo
- pki-tps-debuginfo
- pki-tps-devel
- pki-util-javadoc
Contingency Plan
N/A as this is a completely new feature and failing to implement it will not affect any other part of the distribution.
Documentation
- Documentation can be found here.
Release Notes
- Release Notes can be found here.