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

2016-07-01 Thread John Magne 
ACKED verbally by cfu, with some very minor changes.

Pushed to master:


commit 0f056221d096a30307834265ecd1c527087bb0f7
Author: Jack Magne <jma...@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" <jma...@redhat.com>
To: "pki-devel" <pki-devel@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.

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

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

2016-06-23 Thread John Magne 


[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.From ef5d954d1160002f6ed0ff05894f5968d7982d24 Mon Sep 17 00:00:00 2001
From: Jack Magne 
Date: Mon, 13 Jun 2016 11:27:59 -0700
Subject: [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.
---
 .../src/com/netscape/certsrv/key/KeyData.java  |  17 +-
 .../cms/servlet/csadmin/ConfigurationUtils.java| 252 -
 .../cms/servlet/tks/SecureChannelProtocol.java |   3 +-
 .../com/netscape/cms/servlet/tks/TokenServlet.java |  26 ++-
 .../server/tks/rest/TPSConnectorService.java   | 147 +---
 .../server/tps/processor/TPSProcessor.java |   8 +-
 .../server/tps/rest/TPSInstallerService.java   |  12 +-
 .../com/netscape/cmsutil/crypto/CryptoUtil.java| 157 +
 8 files changed, 426 insertions(+), 196 deletions(-)

diff --git a/base/common/src/com/netscape/certsrv/key/KeyData.java b/base/common/src/com/netscape/certsrv/key/KeyData.java
index 6da4d38..d50c9ec 100644
--- a/base/common/src/com/netscape/certsrv/key/KeyData.java
+++ b/base/common/src/com/netscape/certsrv/key/KeyData.java
@@ -48,7 +48,8 @@ public class KeyData {
 @XmlElement
 Integer size;
 
-String privateData;
+@XmlElement
+String additionalWrappedPrivateData;
 
 public KeyData() {
 // required for JAXB (defaults)
@@ -68,6 +69,14 @@ public class KeyData {
 this.wrappedPrivateData = wrappedPrivateData;
 }
 
+public String getAdditionalWrappedPrivateData() {
+return additionalWrappedPrivateData;
+}
+
+public void setAdditionalWrappedPrivateData(String additionalWrappedPrivateData) {
+this.additionalWrappedPrivateData = additionalWrappedPrivateData;
+}
+
 /**
  * @return the nonceData
  */
@@ -126,11 +135,5 @@ public class KeyData {
 this.size = size;
 }
 
-public String getPrivateData() {
-return privateData;
-}
 
-public void setPrivateData(String privateData) {
-this.privateData = privateData;
-}
 }
diff --git a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
index 2da4e48..56ee9fa 100644
--- a/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
+++ b/base/server/cms/src/com/netscape/cms/servlet/csadmin/ConfigurationUtils.java
@@ -15,7 +15,7 @@
 // (C) 2012 Red Hat, Inc.
 // All rights reserved.
 // --- END COPYRIGHT BLOCK ---
-