From Fedora Project Wiki
m (internal link cleaning)
 
(39 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.  -->
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->


= Dogtag Certificate System =
= Dogtag Certificate System =
Line 10: Line 8:


== Owner ==
== Owner ==
<!--This should link to your home wiki page so we know who you are-->
* Name: PKI Developers
* Name: [[User:shaines| Scott Haines]]
* email: pki DASH devel AT redhat DOT com
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
* email: shaines AT redhat DOT com


== Current status ==
== Current status ==
* Targeted release: Fedora 13 <!-- [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  -->
* Targeted release: Fedora 13  
* Last updated: 07-30-2009
* Last updated: 02-04-2010
* Percentage of completion: 0%
* Percentage of completion: 100%
 
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->


== Detailed Description ==
== Detailed Description ==
Line 27: Line 20:


== Benefit to Fedora ==
== Benefit to Fedora ==
All new feature.  Full featured open source Certificate Authority (CA).
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 ==
== Scope ==
Code complete.  Currently focused on modifying existing packages to meet Fedora packaging requirements.
* Code complete.  Awaiting Package Review and fedora-cvs approval on one remaining package:
** pki-tps


== How To Test ==
== How To Test ==
FIX ME <!-- 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.  
 
'''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
** 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.  


Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
Line 48: Line 116:


== User Experience ==
== User Experience ==
FIX ME <!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
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 ==
FIX ME: Requires and build requires
 
'''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 ==
== Contingency Plan ==
In it's current state, Dogtag will work.
 
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 ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
* Documentation can be found [http://pki.fedoraproject.org/wiki/PKI_Documentation here].
* Documentation can be found [http://pki.fedoraproject.org/wiki/PKI_Documentation here].


== 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/ -->
<!-- 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. -->
* Release Notes can be found [http://pki.fedoraproject.org/wiki/PKI_Release_Notes here].
* Release Notes can be found [http://pki.fedoraproject.org/wiki/PKI_Release_Notes here].


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/YourFeatureName]] <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/DogtagCertificateSystem]]


 
[[Category:FeatureAcceptedF13]]
[[Category:FeaturePageIncomplete]]
<!-- 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: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: [[Features/Policy/Process]] -->
 
 
 
[[Category:Wrangler Watch]]

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
    • Certificate enrollment via different types of browsers such as IE and Firefox
    • Smartcard enrollment and format operations


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.

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/DogtagCertificateSystem&oldid=472063"