#1659 [RFE] Add granularity to TPS for granular certificate management on token
Closed: migrated 3 years ago by dmoluguw. Opened 8 years ago by dsirrine.

Problem:

When tokens are marked as Reuse (formerly terminate), actions are
taken against certificates to add them to the CRL. The certificates
are suggested to be added to the CRL with the superseded reason code.
This is not always the intended action or proper revocation reason
since a token must be moved into the Reuse state before the token
can be reformatted for reuse and/or zeroized to conform to private
key destruction requirements.

Recommended Fix:

Suggest adding a drop down to the Reuse function with multiple actions
that can be taken against the token itself and/or the certificates.
The certificate actions can be from taking no action against the
certificate(s) or adding the certificate(s) to the CRL with the proper 
revocation reason which is not always superseded.

* Suspend    - Token Suspended, Certificate(s) revoked and marked as
               "Certificate On Hold"
* Restore    - Token Restored, Certificate(s) removed from CRL
* Compromise - Token Black Listed, Certificate(s) revoked and marked as
               "Key Compromise"
* Lost       - Token Black Listed, Certificate(s) revoked and marked as
               "Key Compromise"
* Failed     - Token Reuse, Certificate(s) revoked and marked as
               "Cessation of Operation" or "Certificate Superseded"
* Damaged    - Token Black Listed, Certificate(s) revoked and marked as
               "Cessation of Operation" or "Certificate Superseded"
* ReUse      - Token ReUse, Certificate marked as:

               * "No action"               - no action taken against 
                                             certificate(s) associated
                                             with token certificates will
                                             naturally expire or direct
                                             action on the CA must be taken
               * "Affiliation Change"      - Certificate(s) revoked and
                                             marked with Affiliation
                                             Change reason (Service change)
               * "Certificate Superseded"  - Certificate(s) revoked and
                                             marked with the Certificate
                                             Superseded reason (Reissuance)
               * "Cessation of Operations" - Certificate(s) revoked and
                                             marked with the Cessation of
                                             Operations reason
                                             (Operation/Training/etc.
                                             has ended)
               * "Unspecified"             - Certificate(s) revoked and
                                             marked with the Unspecified
                                             reason (All other reasons)

Additional Benefits:

The following system enhancements are associated with the addition of the
versatility of the Token ReUse state:

- The addition of the "No Action" Token ReUse option allows marking
  tokens as ReUse without performing any action on expired certificate(s).

- The addition of the "No Action" Token ReUse option allows for
  Code Signing certificate(s) to be marked as ReUse without revoking
  an active certificate(s) which allows the token to be reformatted
  (zeroizing) to destroy the private key(s) of the code signing
  certificate(s). This will allow code signing tokens to be reused
  after their active code signing capability and allow the
  certificate(s) to remain active for the possible full certificate
  lifecycle.

- The addition of the other reason codes allows certificates to be
  properly marked on the CRL for the corresponding action that was
  taken against the token. This will provide a more accurate
  portrayal of a certificate lifecycle.

Per CS/DS meeting of 11/02/2015: 10.3

Metadata Update from @dsirrine:
- Issue assigned to cfu
- Issue set to the milestone: UNTRIAGED

7 years ago

Metadata Update from @mharmsen:
- Custom field feature adjusted to ''
- Custom field proposedmilestone adjusted to ''
- Custom field proposedpriority adjusted to ''
- Custom field reviewer adjusted to ''
- Custom field version adjusted to ''
- Issue close_status updated to: None
- Issue set to the milestone: 10.4 (was: UNTRIAGED)

7 years ago

Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.

Metadata Update from @mharmsen:
- Issue set to the milestone: FUTURE (was: 10.4)

6 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2218

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata