[Pki-devel] [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch

[John Magne]

ACKED verbally by cfu, with some very minor changes.

Pushed to master:


commit 0f056221d096a30307834265ecd1c527087bb0f7
Author: Jack Magne <jmagne at dhcp-16-206.sjc.redhat.com>
Date:   Mon Jun 13 11:27:59 2016 -0700

    Separated TPS does not automatically receive shared secret from remote TKS.
....
....

Closing ticket # 2349




----- Original Message -----
From: "John Magne" <jmagne at redhat.com>
To: "pki-devel" <pki-devel at redhat.com>
Sent: Thursday, June 23, 2016 3:33:44 PM
Subject: [pki-devel][PATCH] 0073-Separated-TPS-does-not-automatically-receive-shared-.patch



[PATCH] Separated TPS does not automatically receive shared secret
 from remote TKS.

Support to allow the TPS to do the following:

1. Request that the TKS creates a shared secret with the proper ID, pointing to the TPS.
2. Have the TKS securely return the shared secret back to the TPS during the end of configuration.
3. The TPS then imports the wrapped shared secret into it's own internal NSS db permanenty and.
4. Given a name that is mapped to the TPS's id string.

Additional fixes:

1. The TKS was modified to actually be able to use multiple shared secrets registered by
multiple TPS instances.

Caveat:

At this point if the same remote TPS instance is created over and over again, the TPS's user
in the TKS will accumulate "userCert" attributes, making the exportation of teh shared secret
not functional. At this point we need to assume that the TPS user has ONE "userCert" registered
at this time.


Tested with a remote TPS talking to a shared TMS system consisting of a TPS, TKS, and KRA .

The shared secret was imported successfully after manually deleting the user representing the TPS from previous installs.
This way I was assured one cert stored for the user, since it had to be created fresh.

Also tested that the TKS can work successfully with the new TPS AND the prior shared TPS on the original instance.
The TKS can now host more than one shared secret in it's db and address the correct one when a given TPS makes a request of it.

Please forgive some spurious changes that happened when formatting a couple of the files in question. Every legit change is related to the shared secret and can be found easily.