Automating Encryption Key Recovery; Configuring Enrollment For Replacement Tokens - Red Hat CERTIFICATE SYSTEM 8.0 - ADMINISTRATION Admin Manual

LDAP directory.
auth.instance.1.ui.id.UID.name.en=LDAP User ID
auth.instance.1.ui.id.PASSWORD.name.en=LDAP Password
auth.instance.1.ui.id.UID.description.en=QA LDAP User ID
auth.instance.1.ui.id.PASSWORD.description.en=QA LDAP Password
##########################################################################
• The two format operation profiles are devKey and qaKey.
• The two mapping order 0 refers to the devKey and 1 refers to the qaKey.
• The two authentication instances 0 and 1 correspond to ldap-dev and ldap-qa, respectively.

5.5. Automating Encryption Key Recovery

The Certificate System allows for a semi-automated recovery if a user loses, destroys, or misplaces
a token. The TPS automatically recovers the appropriate encryption keys and certificates for a
permanently or temporarily lost token, depending on the circumstances of the token loss. To prevent
misuse of the recovery feature, the TPS requires that a user must have a single active token.
When a user loses a token, the user must first get a replacement token. If a new enrollment is
attempted with this new token, the TPS blocks the enrollment since the user already has an active
token.
The token status in the database must be changed to lost. This action is performed through the TPS
agent services page. The TPS agent, after affirmatively identifying the user, can search for the user's
ID in the Search tokens link. The TPS agent select the active token and update the status, with the
appropriate reason to recover the key.
Agent Status Option
This token has been physically
damaged.
This token has been
permanently lost.
This token has been
temporarily lost.
Table 5.8. Lost Token Statuses
There are two different schemes for recovery. GenerateNewKey creates a new key and certificate.
This is used for signing keys. RecoverLast recovers the last encryption key and associated certificate.

5.5.1. Configuring Enrollment for Replacement Tokens

The user can enroll for a replacement token. It is preferred that signing keys be generated on the
smart card and not archived so that if the smart card is lost, new signing keys and certificates must be
regenerated on the token, and temporary certificates created.
There is a different policy set for all three lost states, and each policy sets independently the rules for
generating keys. Each policy set is part of the enrollment configuration.
op.enroll.userKey.keyGen.recovery.lost_type
For damaged tokens, the lost_type is destroyed.. For permanently lost tokens, it is
keyCompromised. For temporarily lost tokens, it is onHold.
Configuration Parameter
reason=0
reason=1
reason=6
Automating Encryption Key Recovery
Default Recovery Scheme
RecoverLast
GenerateNewKey
GenerateNewKey
143