#2360 [TPS] externalReg: extra keytype needed in TPS profile for recovering certs
Closed: migrated by dmoluguw. Opened by cfu.

It is observed that in case of externalReg, parameters for extra keytype is needed or the recovery will fail.

e.g.
op.enroll.delegateISEtoken.keyGen.keyType.num=2
op.enroll.delegateISEtoken.keyGen.keyType.value.0=signing
op.enroll.delegateISEtoken.keyGen.keyType.value.1=authentication
...
Where there are only 2 new certs to be issued, then externalReg would "recover" whatever is specified in the user record.
However, if we miss
op.enroll.delegateISEtoken.keyGen.encryption.*
the externalReg based recovery will fail.

Investigation is needed to find out why that is the case, and if it is something that we can either
1. document (preferred)
2. fix (time is probably not allowed for 10.3.3)


Per PKI Bug Council of 06/23/2016: 10.3.4

cfu to investigate

currently setting to no downstream bug

Investigation result shows that at the minimum the following areas are attempting to read off the "encryption" keytype params for the profile in case of externalReg, and in the case when the keytype params are missing, breaks when either defaulting to wrong value or having no value and throw exception.

  • TKSRemoteRequestHandler.java computeSessionKey() - reading xxxx.keyGen.encryption.serverKeygen.enable and got defaulted to "false", which causes TKS to NOT generate drm trans wrapped des key along with others; This is actually the very first thing that breaks.
  • TPSEnrollProcessor.java getCAConnectorID() is called with params that causes it to attemp read under "encryption"
  • TPSEnrollProcessor.java checkForServerSideKeyGen() defaulting to false so the code bails out thinking key recovery is not enabled
  • SecureChannel.java appendPKCS11Attribute() - reading off all public and private key capabilities

There maybe more, but there are enough for us to say that that "encryption" params need to be there as a workaround for now.

Two things though:
1. If there are more than one cert/keys to be recovered for externalReg, they will share the same "encryption" params within the TPS profile.
2. If the "encryption" keytype happens to be one of the enabled keyType.value, then is will have to be doubled as the params for externalReg recovery as well

investigation bug morphing to bug for
1. possible later code improvements.
2. wiki (or sorts) to capture the investigation result

This is the patch that addressed the first 3 bullets listed in comment 2; bullet 4 is captured in one comment where it says: // should default all capabilities to match that of an encryption key
pki-cfu-0141-Ticket-2360-externalReg-extra-keytype-is-needed-in-T.patch

I took a look at this with cfu, and we came to the conclusion that the workaround of having encryption cert settings included in external reg type profiles is fine. The proposed patch was looked at and would just give us some defaults to allow the recovery of external reg certs to finish. This could result in cert properties not expected by the user though. Thus for the short term, it might be better to just keep the settings in the CS.cfg.

Further down the road, we might want a more comprehensive solution that allows the user to specify different attributes on a cert by cert basis in the external reg record somehow.

For now moving this thing out of the current high priority milestone.

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

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/2480

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)

Metadata