#1375 TPS rewrite: provide cert/key retention for ExternalReg
Closed: Fixed None Opened 8 years ago by cfu.

This ticket is a break off from #1028, where the ExternalReg framework/functionality has been completed.

This ticket should cover:
cert/key retention (allow preserving existing certs/keys on the token)


Per CS/DS meeting of 06/08/2015: 10.2.6

Per Dogtag 10.2.6 TRIAGE meeting of 06/30/2015: 10.3

Per CS/DS Meeting of 07/27/2015: Merge #1509 with #1375

https://fedorahosted.org/pki/ticket/1509 - TPS fails to recover additional certs when the token already has a recovered cert/key

TPS fails to recover additional certs when the token already has a recovered cert/key

Steps to Reproduce:

1. add an user to TPS
dn: uid=pkiuser3,ou=People,dc=pki-tps1
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: top
objectClass: extensibleobject
cn: pkiuser3
sn: pkiuser3
uid: pkiuser3
givenName: pkiuser3
mail: pkiuser3@example.org
firstname: pkiuser3
userPassword:: e1NTSEF9RUtXZzJUSGtzR0NEYzIzNzNIUlc3VzVJNGZ2VncrOHRxK1JQNUE9PQ=
 =
tokenType: externalRegAddToToken
certstoadd: 64,ca1
certstoadd: 65,ca1,13,kra1

cert with (decimal) serial number 64 has already been recovered on the token
cert with serial 65 is the additional cert that needs to be recovered.

2. Enroll a smartcard authenticating as user pkiuser3

Actual results:

enrollment fails, ESC shows the error message "ESC lost connection to smartcard
server)

Expected results:

enrollment should be successful, cert/key should be recovered on the token

Additional info:

Attaching TPS debug log to: Bugzilla Bug #1245757 - TPS fails to recover additional certs when the token already has a recovered cert/key.

commit 9a6a3d1cbf6e347b2cf0737afca4f793a6a0d0ba

From 9a6a3d1cbf6e347b2cf0737afca4f793a6a0d0ba Mon Sep 17 00:00:00 2001
From: Christina Fu cfu@redhat.com
Date: Thu, 3 Dec 2015 15:00:55 -0800
Subject: [PATCH] Ticket #1375 Provide cert/key retention for externalReg
Ticket #1514 TPS: Recovered certs on a token has status expired Ticket #1587
External Registration Recovery only works for 1024 sized keys out of the box
This patch provides the cert/key retention feature for externalReg. If the
certsToAdd field contains (serial,ca#) instead of the full (serial, ca#,
keyId, kra#), then it is expecting the cert/keys to be retained from token
without having to do a full retrieval (recovery); If an exisiting cert (and
its keys) on the token is not explicitly retained then it is deleted. This
patch also fixes the issues reported in #1514 and #1587 as testing of #1375
is easier with those two issues addressed. An issue was found during
development where Coolkey puts limits on the cert/key ids on the token and
make it impossible to inject cert ID higher than 4, as it would then result
in key ids into two digits. Another issue that adds to running into the limit
is that the function that gets the next free certid number does not make any
attempt to search for "holes" to reuse. The cert/key id assignment/limit
issue will be filed as a separte ticket and addressed separately. More
complicated testing will be conducted then.

More extensive tests could be conducted once the following ticket is resolved:
https://fedorahosted.org/pki/ticket/1734

A few example test cases to consider:

  • enroll with delegateISEtoken and "recover" two certs(and their keys) in one shot. e.g.:

tokenType: delegateISEtoken
certstoadd: 61,ca1,7,kra1
certstoadd: 63,ca1,9,kra1
==> that should put 4 certs and their keys on the token

  • with same token, add two certs/keys and retain 3 of the certs from last case. e.g. (assuming the IS certs earlier were serials 70 and 71):

tokenType: externalRegAddToToken
certstoadd: 71,ca1
certstoadd: 70,ca1
certstoadd: 52,ca1,5,kra1
certstoadd: 53,ca1,6,kra1
certstoadd: 61,ca1
== cert serial 63 should be deleted; 61 retained, 52 and 53 loaded, resulting in 5 certs and their keys on the token

  • add/delete more certs/keys to the above token

certstoadd: 71,ca1
certstoadd: 52,ca1
certstoadd: 61,ca
certstoadd: 40,ca1,3,kra1
==> cert 40 will be added; 53 and 70 deleted, resulting in 4 certs and their keys on token

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

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

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.

Login to comment on this ticket.

Metadata