From edewata at redhat.com Mon Feb 3 17:36:03 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Feb 2014 11:36:03 -0600 Subject: [Pki-devel] [PATCH] 383 Added upgrade script to replace Jettison with Jackson. Message-ID: <52EFD383.2080000@redhat.com> A new upgrade script has been added to replace Jettison links with Jackson links in Tomcat's common library. Ticket #817 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0383-Added-upgrade-script-to-replace-Jettison-with-Jackso.patch Type: text/x-patch Size: 6077 bytes Desc: not available URL: From cfu at redhat.com Mon Feb 3 19:40:31 2014 From: cfu at redhat.com (Christina Fu) Date: Mon, 03 Feb 2014 11:40:31 -0800 Subject: [Pki-devel] [PATCH] 181-188 Adding Symmetric Key generation Service to DRM In-Reply-To: <1391096903.14969.14.camel@aleeredhat.laptop> References: <1391096903.14969.14.camel@aleeredhat.laptop> Message-ID: <52EFF0AF.6020402@redhat.com> Ade, This is my first cut. focus of this review is more on the server side sym key generation part. SymKeyGenService.java: * does IRequest.RESULT not need to be set in request for SymKeyGenService? and also mKRA.getRequestQueue().updateRequest(request); ? * I am actually kind of surprised that the SymKeyGenService doesn't do both key gen and recovery in one shot. That's what asym key server-side-key-generation does --- generating keys, archive, and then return the keys to the caller, all in one shot. If not needed now, we can at least put down as "ToDo" as an option, if the client supplies the kra-transport-wrapped session key. Christina On 01/30/2014 07:48 AM, Ade Lee wrote: > Hi, > > The attached patches add Symmetric Key generation service to the DRM and > refactor the DRM REST interface. Its worthwhile to look at each patch > individually, but there will be many cases where I changed my mind on > how to represent something - for instance, Request -> KeyRequest -> > ResourceMessage. So, the patches should be viewed as a whole. > > Summary of changes: > 1) Added new REST service to generate symmetric keys. > 2) Refactor API to use POST /keyrequests for all request types and using > a generic RequestMessage object. > 3) Refactor PKIException to use RequestMessage object. > 4) Rename some objects in Key and KeyRequest resources. > > I tested all this using the DRMTest code. I needed to comment out a > couple of tests because they were causing problems (including a core > dump on the client side), and I need to investigate why that happened. > Those tests will be restored once I figure out whats going on. > > I'd like to get several eyes on this, please. > > Thanks, > Ade > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Feb 4 03:55:08 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Feb 2014 22:55:08 -0500 Subject: [Pki-devel] [PATCH] 181-188 Adding Symmetric Key generation Service to DRM In-Reply-To: <52EAA1C4.8090202@redhat.com> References: <1391096903.14969.14.camel@aleeredhat.laptop> <52EAA1C4.8090202@redhat.com> Message-ID: <1391486108.25736.32.camel@aleeredhat.laptop> New patch attached to address comments as below. Please apply 189 on top of rest of patches. On Thu, 2014-01-30 at 13:02 -0600, Endi Sukma Dewata wrote: > On 1/30/2014 9:48 AM, Ade Lee wrote: > > Hi, > > > > The attached patches add Symmetric Key generation service to the DRM and > > refactor the DRM REST interface. Its worthwhile to look at each patch > > individually, but there will be many cases where I changed my mind on > > how to represent something - for instance, Request -> KeyRequest -> > > ResourceMessage. So, the patches should be viewed as a whole. > > > > Summary of changes: > > 1) Added new REST service to generate symmetric keys. > > 2) Refactor API to use POST /keyrequests for all request types and using > > a generic RequestMessage object. > > 3) Refactor PKIException to use RequestMessage object. > > 4) Rename some objects in Key and KeyRequest resources. > > > > I tested all this using the DRMTest code. I needed to comment out a > > couple of tests because they were causing problems (including a core > > dump on the client side), and I need to investigate why that happened. > > Those tests will be restored once I figure out whats going on. > > > > I'd like to get several eyes on this, please. > > > > Thanks, > > Ade > > Some comments: > > 1. Minor issue. Please put a space before the curly bracket: > > public static class Data extends ResourceMessage{ > Fixed. > 2. I'm not sure if the ResourceMessage should have a Link attribute. The > PKIException doesn't need it. Probably many other request/resource > objects won't need it either. > Removed Link > 3. The PKIException previously has . Now that it uses > should we start implementing API versioning? > Revert to Attributes > 4. This is actually an existing issue in the current code. The > marshall/unmarshal code currently swallows the exception. We probably > should have thrown the original exception, or if not possible we should > wrap it with a RuntimeException. > Deferring to later patch. > 5. This is also an existing issue. The KeyDataInfo name is probably > redundant. If it's an Info that means it doesn't have the Data, so the > name probably should be KeyInfo. Similarly, the KeyDataInfoCollection > probably can be renamed to KeyInfoCollection. The XmlRootElement should > match too, but this probably requires versioning. > > @XmlRootElement(name = "KeyDataInfos") > public class KeyDataInfoCollection extends DataCollection { > Renamed classes. > 6. The KEYGEN_ALGORITHMS is defined in SymKeyGenerationRequest but it's > only used by the server only. Will the client need this too? Otherwise > we should move it to the server. Maybe the client just needs the list of > alg names instead of the actual objects? > Fixed. > 7. The DRMTest is using constants in PKIService. While this works in dev > env, a real client will not be able to use the server class. We should > move the constants and maybe provide a method in the client library to > strip the header & trailer. Or maybe strip them on the server. > > transportCert = transportCert.substring(PKIService.HEADER.length(), > transportCert.indexOf(PKIService.TRAILER)); > Defer to later patch. > I may have some more comments later. > Also added code to address Christina's comments as below: SymKeyGenService.java: * does IRequest.RESULT not need to be set in request for SymKeyGenService? and also mKRA.getRequestQueue().updateRequest(request); ? Added code to SymKeyGenService etc. * I am actually kind of surprised that the SymKeyGenService doesn't do both key gen and recovery in one shot. That's what asym key server-side-key-generation does --- generating keys, archive, and then return the keys to the caller, all in one shot. If not needed now, we can at least put down as "ToDo" as an option, if the client supplies the kra-transport-wrapped session key. Defer to later patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0189-Address-review-comments.patch Type: text/x-patch Size: 47166 bytes Desc: not available URL: From alee at redhat.com Tue Feb 4 18:30:51 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Feb 2014 13:30:51 -0500 Subject: [Pki-devel] [PATCH] 190 - fix symkey generation, archival and recovery using non-DES3 keys Message-ID: <1391538651.25736.38.camel@aleeredhat.laptop> Fix DRM archival, recovery and generation for non-DES3 keys. In the archival, recovery and generation code for symmetric keys, we use functions that require knowledge of the symmetric keys algorithm and key size. These were hardcoded to DES3, and so only DES3 worked. We added those parameters to the archival request, save them in the KeyRecord and retrive them when recovering the key. Tests have been added to DRMTest for the relevant usages. Thanks to jmagne for doing initial investigation and determining what needed to be done. Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0190-Fix-DRM-archival-recovery-and-generation-for-non-DES.patch Type: text/x-patch Size: 30116 bytes Desc: not available URL: From alee at redhat.com Tue Feb 4 18:43:42 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Feb 2014 13:43:42 -0500 Subject: [Pki-devel] [PATCH] 181-188 Adding Symmetric Key generation Service to DRM In-Reply-To: <1391486108.25736.32.camel@aleeredhat.laptop> References: <1391096903.14969.14.camel@aleeredhat.laptop> <52EAA1C4.8090202@redhat.com> <1391486108.25736.32.camel@aleeredhat.laptop> Message-ID: <1391539422.25736.40.camel@aleeredhat.laptop> Final ack by Endi. Pushed to master: Exit status 0 To ssh://vakwetu at git.fedorahosted.org/git/pki.git 78031e7..cf425df master -> master On Mon, 2014-02-03 at 22:55 -0500, Ade Lee wrote: > New patch attached to address comments as below. > > Please apply 189 on top of rest of patches. > > On Thu, 2014-01-30 at 13:02 -0600, Endi Sukma Dewata wrote: > > On 1/30/2014 9:48 AM, Ade Lee wrote: > > > Hi, > > > > > > The attached patches add Symmetric Key generation service to the DRM and > > > refactor the DRM REST interface. Its worthwhile to look at each patch > > > individually, but there will be many cases where I changed my mind on > > > how to represent something - for instance, Request -> KeyRequest -> > > > ResourceMessage. So, the patches should be viewed as a whole. > > > > > > Summary of changes: > > > 1) Added new REST service to generate symmetric keys. > > > 2) Refactor API to use POST /keyrequests for all request types and using > > > a generic RequestMessage object. > > > 3) Refactor PKIException to use RequestMessage object. > > > 4) Rename some objects in Key and KeyRequest resources. > > > > > > I tested all this using the DRMTest code. I needed to comment out a > > > couple of tests because they were causing problems (including a core > > > dump on the client side), and I need to investigate why that happened. > > > Those tests will be restored once I figure out whats going on. > > > > > > I'd like to get several eyes on this, please. > > > > > > Thanks, > > > Ade > > > > Some comments: > > > > 1. Minor issue. Please put a space before the curly bracket: > > > > public static class Data extends ResourceMessage{ > > > Fixed. > > > 2. I'm not sure if the ResourceMessage should have a Link attribute. The > > PKIException doesn't need it. Probably many other request/resource > > objects won't need it either. > > > Removed Link > > 3. The PKIException previously has . Now that it uses > > should we start implementing API versioning? > > > Revert to Attributes > > > 4. This is actually an existing issue in the current code. The > > marshall/unmarshal code currently swallows the exception. We probably > > should have thrown the original exception, or if not possible we should > > wrap it with a RuntimeException. > > > Deferring to later patch. > > > 5. This is also an existing issue. The KeyDataInfo name is probably > > redundant. If it's an Info that means it doesn't have the Data, so the > > name probably should be KeyInfo. Similarly, the KeyDataInfoCollection > > probably can be renamed to KeyInfoCollection. The XmlRootElement should > > match too, but this probably requires versioning. > > > > @XmlRootElement(name = "KeyDataInfos") > > public class KeyDataInfoCollection extends DataCollection { > > > Renamed classes. > > > 6. The KEYGEN_ALGORITHMS is defined in SymKeyGenerationRequest but it's > > only used by the server only. Will the client need this too? Otherwise > > we should move it to the server. Maybe the client just needs the list of > > alg names instead of the actual objects? > > > Fixed. > > > 7. The DRMTest is using constants in PKIService. While this works in dev > > env, a real client will not be able to use the server class. We should > > move the constants and maybe provide a method in the client library to > > strip the header & trailer. Or maybe strip them on the server. > > > > transportCert = transportCert.substring(PKIService.HEADER.length(), > > transportCert.indexOf(PKIService.TRAILER)); > > > Defer to later patch. > > I may have some more comments later. > > > > Also added code to address Christina's comments as below: > SymKeyGenService.java: > * does IRequest.RESULT not need to be set in request for > SymKeyGenService? and also > mKRA.getRequestQueue().updateRequest(request); ? > > Added code to SymKeyGenService etc. > > * I am actually kind of surprised that the SymKeyGenService doesn't do > both key gen and recovery in one shot. That's what asym key > server-side-key-generation does --- generating keys, archive, and then > return the keys to the caller, all in one shot. > If not needed now, we can at least put down as "ToDo" as an option, if > the client supplies the kra-transport-wrapped session key. > > Defer to later patch. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Tue Feb 4 19:17:17 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 04 Feb 2014 11:17:17 -0800 Subject: [Pki-devel] [PATCH] 190 - fix symkey generation, archival and recovery using non-DES3 keys In-Reply-To: <1391538651.25736.38.camel@aleeredhat.laptop> References: <1391538651.25736.38.camel@aleeredhat.laptop> Message-ID: <52F13CBD.3070807@redhat.com> I just have one suggestion. Your code does not have default algorithm and key size if caller doesn't supply. How about default to, say, AES 128 if not supplied. Christina On 02/04/2014 10:30 AM, Ade Lee wrote: > Fix DRM archival, recovery and generation for non-DES3 keys. > > In the archival, recovery and generation code for symmetric keys, > we use functions that require knowledge of the symmetric keys algorithm > and key size. These were hardcoded to DES3, and so only DES3 worked. > > We added those parameters to the archival request, save them in the > KeyRecord and retrive them when recovering the key. > > Tests have been added to DRMTest for the relevant usages. > > Thanks to jmagne for doing initial investigation and determining what needed to be done. > > Please review, > > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Feb 5 00:19:29 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Feb 2014 18:19:29 -0600 Subject: [Pki-devel] [PATCH] 378 Added checkboxes for selecting table rows. In-Reply-To: <52B19711.8020407@redhat.com> References: <52B19711.8020407@redhat.com> Message-ID: <52F18391.5040200@redhat.com> On 12/18/2013 6:37 AM, Endi Sukma Dewata wrote: > The tables have been modified to provide a checkbox on each row > to select the entry for subsequent operations. The checkbox in > the column header can be used to select/deselect all rows at once. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Feb 5 00:21:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Feb 2014 18:21:26 -0600 Subject: [Pki-devel] [PATCH] 379 Added RCUE files. In-Reply-To: <52E6A87E.8080104@redhat.com> References: <52E6A87E.8080104@redhat.com> Message-ID: <52F18406.6080906@redhat.com> On 1/27/2014 12:42 PM, Endi Sukma Dewata wrote: > New CSS, JavaScript, and font files have been added from RCUE to > provide standardized look and feel. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Feb 5 00:21:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Feb 2014 18:21:52 -0600 Subject: [Pki-devel] [PATCH] 380 Added TPS UI navigation. In-Reply-To: <52E6A94F.4050305@redhat.com> References: <52E6A94F.4050305@redhat.com> Message-ID: <52F18420.9080309@redhat.com> On 1/27/2014 12:45 PM, Endi Sukma Dewata wrote: > A new navigation bar has been added to the top of the page. When > a navigation link is clicked, the target page will be loaded into > the same page. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From alee at redhat.com Wed Feb 5 18:27:26 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Feb 2014 13:27:26 -0500 Subject: [Pki-devel] [PATCH] 191 - Add strength and algorithm to KeyData and KeyInfo Message-ID: <1391624846.7042.3.camel@aleeredhat.laptop> Add strength and algorithm to KeyData and KeyInfo classes Make sure these are updated so that clients can get this information when accessing a symmetric key. Also allow a default for generation requests (but not for archival requests). Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0191-Add-strength-and-algorithm-to-KeyData-and-KeyInfo-cl.patch Type: text/x-patch Size: 9926 bytes Desc: not available URL: From alee at redhat.com Wed Feb 5 18:29:29 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Feb 2014 13:29:29 -0500 Subject: [Pki-devel] [PATCH] 192 - Change retrun type for KeyRequest creation operations Message-ID: <1391624969.7042.5.camel@aleeredhat.laptop> Change the return type for KeyRequest creation operations We will likely want to extend the REST API to allow the immediate return of a generated key, and perhaps of a recovered key in a single step. This change allows us to do that. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0192-Change-the-return-type-for-KeyRequest-creation-opera.patch Type: text/x-patch Size: 29722 bytes Desc: not available URL: From edewata at redhat.com Thu Feb 6 21:25:58 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Feb 2014 15:25:58 -0600 Subject: [Pki-devel] [PATCH] 381 Fixed template deployment. In-Reply-To: <52EC0016.6070007@redhat.com> References: <52EC0016.6070007@redhat.com> Message-ID: <52F3FDE6.8020600@redhat.com> On 1/31/2014 1:57 PM, Endi Sukma Dewata wrote: > The deployment scriptlet has been fixed to copy the templates to the > subsystem web application. This functionality was incorrectly removed > in a previous revision (5952a82975063c4ec27303091a44e586d1386933). ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Feb 6 21:26:14 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Feb 2014 15:26:14 -0600 Subject: [Pki-devel] [PATCH] 382 Replaced Jettison with Jackson. In-Reply-To: <52EC036B.8090507@redhat.com> References: <52EC036B.8090507@redhat.com> Message-ID: <52F3FDF6.2020301@redhat.com> On 1/31/2014 2:11 PM, Endi Sukma Dewata wrote: > The Jettison library has been replaced with Jackson library as > JSON provider for RESTEasy. All class paths and the deployment > tools have been updated accordingly. The Python library and the > TPS UI have been updated as well to use the new JSON format. > > Ticket #817 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Feb 6 21:26:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Feb 2014 15:26:51 -0600 Subject: [Pki-devel] [PATCH] 383 Added upgrade script to replace Jettison with Jackson. In-Reply-To: <52EFD383.2080000@redhat.com> References: <52EFD383.2080000@redhat.com> Message-ID: <52F3FE1B.8030400@redhat.com> On 2/3/2014 11:36 AM, Endi Sukma Dewata wrote: > A new upgrade script has been added to replace Jettison links with > Jackson links in Tomcat's common library. > > Ticket #817 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Feb 7 03:59:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Feb 2014 21:59:35 -0600 Subject: [Pki-devel] [PATCH] 191 - Add strength and algorithm to KeyData and KeyInfo In-Reply-To: <1391624846.7042.3.camel@aleeredhat.laptop> References: <1391624846.7042.3.camel@aleeredhat.laptop> Message-ID: <52F45A27.5050206@redhat.com> On 2/5/2014 12:27 PM, Ade Lee wrote: > Add strength and algorithm to KeyData and KeyInfo classes > > Make sure these are updated so that clients can get this information > when accessing a symmetric key. Also allow a default for generation > requests (but not for archival requests). > > Please review. > > Thanks, > Ade ACK. Feel free to push after addressing these minor issues: 1. Exception messages are meant to be read by human, so it would be better to use a user-friendly name (e.g. client ID) instead of variable name (e.g. clientId). throw new BadRequestException( "Invalid key generation request. Missing clientId"); 2. The following alg/size validation should be done even for the default alg/size to make sure we're not hard-coding invalid values (or if it becomes invalid in the future). KeyGenAlgorithm alg = KeyRequestService.KEYGEN_ALGORITHMS.get(algName); if (alg == null) { throw new BadRequestException("Invalid Algorithm"); } if (!alg.isValidStrength(size)) { throw new BadRequestException( "Invalid key size for this algorithm"); } 3. If the keySize in SymKeyGenerationRequest is optional we should use Integer rather than int. This way we can detect and report missing keySize properly using null. Right now the above code seems to be generating "Invalid key size for this algorithm" on missing keySize since the value will be converted into 0. 4. It would be better to include the offending values in the error message: "Key size {keySize} is invalid for {algorithm} algorithm". 5. The terms "strength" and "size" aren't used consistently. Any preference? -- Endi S. Dewata From edewata at redhat.com Fri Feb 7 03:59:58 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Feb 2014 21:59:58 -0600 Subject: [Pki-devel] [PATCH] 192 - Change retrun type for KeyRequest creation operations In-Reply-To: <1391624969.7042.5.camel@aleeredhat.laptop> References: <1391624969.7042.5.camel@aleeredhat.laptop> Message-ID: <52F45A3E.20100@redhat.com> On 2/5/2014 12:29 PM, Ade Lee wrote: > Change the return type for KeyRequest creation operations > > We will likely want to extend the REST API to allow the immediate return > of a generated key, and perhaps of a recovered key in a single step. > This change allows us to do that. > > Please review. > Thanks, > Ade ACK. -- Endi S. Dewata From edewata at redhat.com Fri Feb 7 19:00:07 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Feb 2014 13:00:07 -0600 Subject: [Pki-devel] [PATCH] 384 Replaced deprecated ClientResponse class. Message-ID: <52F52D37.7020508@redhat.com> The ClientResponse class has been deprecated in RESTEasy 3.0, so most of the code using the class has been modified to use the Response class instead. There are a few remaining references to ClientResponse. They will be removed separately later. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0384-Replaced-deprecated-ClientResponse-class.patch Type: text/x-patch Size: 27982 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 10 15:26:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 09:26:19 -0600 Subject: [Pki-devel] [PATCH] 384 Replaced deprecated ClientResponse class. In-Reply-To: <52F52D37.7020508@redhat.com> References: <52F52D37.7020508@redhat.com> Message-ID: <52F8EF9B.2080009@redhat.com> On 2/7/2014 1:00 PM, Endi Sukma Dewata wrote: > The ClientResponse class has been deprecated in RESTEasy 3.0, so most > of the code using the class has been modified to use the Response class > instead. There are a few remaining references to ClientResponse. They > will be removed separately later. Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0384-1-Replaced-deprecated-ClientResponse-class.patch Type: text/x-patch Size: 28422 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 10 15:27:13 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 09:27:13 -0600 Subject: [Pki-devel] [PATCH] 385 Improved TPS UI page loading. Message-ID: <52F8EFD1.6040709@redhat.com> Previously the TPS UI would reload the JS libraries and CSS files every time a page is opened. The pages have been simplified such that it will only contain the necessary elements of the page. A new Page class has been added to the framework to define page initialization. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0385-Improved-TPS-UI-page-loading.patch Type: text/x-patch Size: 28425 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 10 15:44:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 09:44:27 -0600 Subject: [Pki-devel] [PATCH] 386 Fixed pagination in TPS UI. Message-ID: <52F8F3DB.4070604@redhat.com> The pagination in TPS UI no longer worked due to Jackson change. The Collection class has been fixed to read the correct attribute names for pagination links. The table size has been changed to 5 rows. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0386-Fixed-pagination-in-TPS-UI.patch Type: text/x-patch Size: 7445 bytes Desc: not available URL: From alee at redhat.com Mon Feb 10 16:24:45 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 10 Feb 2014 11:24:45 -0500 Subject: [Pki-devel] [PATCH] 192 - Change retrun type for KeyRequest creation operations In-Reply-To: <52F45A3E.20100@redhat.com> References: <1391624969.7042.5.camel@aleeredhat.laptop> <52F45A3E.20100@redhat.com> Message-ID: <1392049485.26029.1.camel@aleeredhat.laptop> Acked by Endi, Jack and Christina. Pushed to master. On Thu, 2014-02-06 at 21:59 -0600, Endi Sukma Dewata wrote: > On 2/5/2014 12:29 PM, Ade Lee wrote: > > Change the return type for KeyRequest creation operations > > > > We will likely want to extend the REST API to allow the immediate return > > of a generated key, and perhaps of a recovered key in a single step. > > This change allows us to do that. > > > > Please review. > > Thanks, > > Ade > > ACK. > From alee at redhat.com Mon Feb 10 16:25:19 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 10 Feb 2014 11:25:19 -0500 Subject: [Pki-devel] [PATCH] 191 - Add strength and algorithm to KeyData and KeyInfo In-Reply-To: <52F45A27.5050206@redhat.com> References: <1391624846.7042.3.camel@aleeredhat.laptop> <52F45A27.5050206@redhat.com> Message-ID: <1392049519.26029.2.camel@aleeredhat.laptop> Fixed issues. Acked by Endi, Jack and Christina. Pushed to master. On Thu, 2014-02-06 at 21:59 -0600, Endi Sukma Dewata wrote: > On 2/5/2014 12:27 PM, Ade Lee wrote: > > Add strength and algorithm to KeyData and KeyInfo classes > > > > Make sure these are updated so that clients can get this information > > when accessing a symmetric key. Also allow a default for generation > > requests (but not for archival requests). > > > > Please review. > > > > Thanks, > > Ade > > ACK. Feel free to push after addressing these minor issues: > > 1. Exception messages are meant to be read by human, so it would be > better to use a user-friendly name (e.g. client ID) instead of variable > name (e.g. clientId). > > throw new BadRequestException( > "Invalid key generation request. Missing clientId"); > > 2. The following alg/size validation should be done even for the default > alg/size to make sure we're not hard-coding invalid values (or if it > becomes invalid in the future). > > KeyGenAlgorithm alg = > KeyRequestService.KEYGEN_ALGORITHMS.get(algName); > if (alg == null) { > throw new BadRequestException("Invalid Algorithm"); > } > > if (!alg.isValidStrength(size)) { > throw new BadRequestException( > "Invalid key size for this algorithm"); > } > > 3. If the keySize in SymKeyGenerationRequest is optional we should use > Integer rather than int. This way we can detect and report missing > keySize properly using null. Right now the above code seems to be > generating "Invalid key size for this algorithm" on missing keySize > since the value will be converted into 0. > > 4. It would be better to include the offending values in the error > message: "Key size {keySize} is invalid for {algorithm} algorithm". > > 5. The terms "strength" and "size" aren't used consistently. Any preference? > From edewata at redhat.com Mon Feb 10 16:30:16 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 10:30:16 -0600 Subject: [Pki-devel] [PATCH] 387 Fixed problem refreshing table after add. Message-ID: <52F8FE98.7070200@redhat.com> Previously the tables in TPS UI did not refresh properly after adding a new entry. The code has been fixed to reset the collection object to store the newly fetched entries and close the dialog after the add operation is done. The success and error handlers for add and save operations have been reorganized. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0387-Fixed-problem-refreshing-table-after-add.patch Type: text/x-patch Size: 5092 bytes Desc: not available URL: From alee at redhat.com Mon Feb 10 16:34:38 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 10 Feb 2014 11:34:38 -0500 Subject: [Pki-devel] [PATCH] 384 Replaced deprecated ClientResponse class. In-Reply-To: <52F8EF9B.2080009@redhat.com> References: <52F52D37.7020508@redhat.com> <52F8EF9B.2080009@redhat.com> Message-ID: <1392050078.26029.4.camel@aleeredhat.laptop> You'll need to rebase again to merge the changes you have made to my latest commits. But this is a pretty straightforward cleanup. ACK. On Mon, 2014-02-10 at 09:26 -0600, Endi Sukma Dewata wrote: > On 2/7/2014 1:00 PM, Endi Sukma Dewata wrote: > > The ClientResponse class has been deprecated in RESTEasy 3.0, so most > > of the code using the class has been modified to use the Response class > > instead. There are a few remaining references to ClientResponse. They > > will be removed separately later. > > Rebased. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Feb 10 16:57:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 10:57:25 -0600 Subject: [Pki-devel] [PATCH] 388 Removed hard-coded response type. Message-ID: <52F904F5.4010007@redhat.com> Previously some methods were hard-coded to return XML responses. The code has been removed to allow clients to request a different format. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0388-Removed-hard-coded-response-type.patch Type: text/x-patch Size: 22652 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 10 17:20:30 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 11:20:30 -0600 Subject: [Pki-devel] [PATCH] 384 Replaced deprecated ClientResponse class. In-Reply-To: <1392050078.26029.4.camel@aleeredhat.laptop> References: <52F52D37.7020508@redhat.com> <52F8EF9B.2080009@redhat.com> <1392050078.26029.4.camel@aleeredhat.laptop> Message-ID: <52F90A5E.5080702@redhat.com> On 2/10/2014 10:34 AM, Ade Lee wrote: > You'll need to rebase again to merge the changes you have made to my > latest commits. But this is a pretty straightforward cleanup. > > ACK. Rebased and pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Mon Feb 10 17:36:58 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 11:36:58 -0600 Subject: [Pki-devel] [PATCH] 388 Removed hard-coded response type. In-Reply-To: <52F904F5.4010007@redhat.com> References: <52F904F5.4010007@redhat.com> Message-ID: <52F90E3A.5080808@redhat.com> On 2/10/2014 10:57 AM, Endi Sukma Dewata wrote: > Previously some methods were hard-coded to return XML responses. > The code has been removed to allow clients to request a different > format. > > Ticket #554 Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0388-1-Removed-hard-coded-response-type.patch Type: text/x-patch Size: 22889 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 10 17:52:33 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Feb 2014 11:52:33 -0600 Subject: [Pki-devel] [PATCH] 388 Removed hard-coded response type. In-Reply-To: <52F90E3A.5080808@redhat.com> References: <52F904F5.4010007@redhat.com> <52F90E3A.5080808@redhat.com> Message-ID: <52F911E1.8090706@redhat.com> On 2/10/2014 11:36 AM, Endi Sukma Dewata wrote: > On 2/10/2014 10:57 AM, Endi Sukma Dewata wrote: >> Previously some methods were hard-coded to return XML responses. >> The code has been removed to allow clients to request a different >> format. >> >> Ticket #554 > > Rebased. ACKed by Ade. Pushed to master. -- Endi S. Dewata From jmagne at redhat.com Tue Feb 11 02:52:37 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 10 Feb 2014 21:52:37 -0500 (EST) Subject: [Pki-devel] [PATCH] 385 Improved TPS UI page loading. In-Reply-To: <52F8EFD1.6040709@redhat.com> References: <52F8EFD1.6040709@redhat.com> Message-ID: <410013928.2565462.1392087157191.JavaMail.zimbra@redhat.com> Looks nice, ACK. Looks like the many script loads have been moved into one single page. And the individual pages such as certs and tokens now rely upon a new "Page" class with a "load" method instead of being loaded in each individual "certs.html" or "tokens.html". Still progressing on the curve of this UI though. ----- Original Message ----- From: "Endi Sukma Dewata" To: "pki-devel" Sent: Monday, February 10, 2014 7:27:13 AM Subject: [Pki-devel] [PATCH] 385 Improved TPS UI page loading. Previously the TPS UI would reload the JS libraries and CSS files every time a page is opened. The pages have been simplified such that it will only contain the necessary elements of the page. A new Page class has been added to the framework to define page initialization. Ticket #654 -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Feb 11 19:25:56 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Feb 2014 13:25:56 -0600 Subject: [Pki-devel] [PATCH] 385 Improved TPS UI page loading. In-Reply-To: <410013928.2565462.1392087157191.JavaMail.zimbra@redhat.com> References: <52F8EFD1.6040709@redhat.com> <410013928.2565462.1392087157191.JavaMail.zimbra@redhat.com> Message-ID: <52FA7944.8020307@redhat.com> On 2/10/2014 8:52 PM, John Magne wrote: > Looks nice, ACK. Thanks. Pushed to master. > Looks like the many script loads have been moved into one single > page. And the individual pages such as certs and tokens now rely upon > a new "Page" class with a "load" method instead of being loaded in > each individual "certs.html" or "tokens.html". Correct. > Still progressing on the curve of this UI though. Nice progress! -- Endi S. Dewata From jmagne at redhat.com Wed Feb 12 18:39:39 2014 From: jmagne at redhat.com (John Magne) Date: Wed, 12 Feb 2014 13:39:39 -0500 (EST) Subject: [Pki-devel] [PATCH] 386 Fixed pagination in TPS UI. In-Reply-To: <52F8F3DB.4070604@redhat.com> References: <52F8F3DB.4070604@redhat.com> Message-ID: <1029171735.4520881.1392230379891.JavaMail.zimbra@redhat.com> ACK: This change is pretty simple as far as the diff. One question, did moving to jackson cause the table size to move from 3 to 5, or is this unrelated? thanks, jack ----- Original Message ----- From: "Endi Sukma Dewata" To: "pki-devel" Sent: Monday, February 10, 2014 7:44:27 AM Subject: [Pki-devel] [PATCH] 386 Fixed pagination in TPS UI. The pagination in TPS UI no longer worked due to Jackson change. The Collection class has been fixed to read the correct attribute names for pagination links. The table size has been changed to 5 rows. Ticket #654 -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Feb 12 20:01:26 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 12 Feb 2014 15:01:26 -0500 Subject: [Pki-devel] [PATCH] 193 - small patch to fix eclipse warnings Message-ID: <1392235286.4097.6.camel@aleeredhat.laptop> This should be a simple cleanup to clear up some warnings. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0193-Fix-eclipse-warnings.patch Type: text/x-patch Size: 12233 bytes Desc: not available URL: From alee at redhat.com Wed Feb 12 20:41:37 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 12 Feb 2014 15:41:37 -0500 Subject: [Pki-devel] [PATCH] 194 - Initial work for python client API Message-ID: <1392237697.4097.41.camel@aleeredhat.laptop> Hi all, Attached is a patch with some initial work for the Python client library, specifically focused on the interactions between the DRM and the python client, and the functionality exposed in the KeyRequestResource and KeyResource REST APIs. The easiest way to see this code in action is to run the main function in the KRAClient module. I usually run this in Eclipse. You will need to set up a few things first though: 1. Install a CA/KRA. It this is not on the default ports, you will need to modify the connection information in KRAClient.__main__ 2. The python code uses python-requests to talk to the server, and requests uses openssl. That means you need to export your DRM admin cert to a PEM file, so that it can be used for client auth. I did this as follows: openssl pkcs12 -in ~/.dogtag/pki-tomcat/ca_admin_cert.p12 -out temp4.pem -nodes Without any changes, the code in KRAClient.__main__ assumes this file will be in /tmp/temp4.pem. 3. We do some crypto functions using NSS commands (like generating a symmetric key or wrapping using the transport cert). Therefore, we need to create an NSS database and populate it with the transport cert. The code expects it to be at /tmp/drmtest/certdb I did this as follows: mkdir /tmp/drmtest/certdb certutil -N -d /tmp/drmtest/certdb chmod +r /tmp/drmtest/certdb/* certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "transportCert cert-pki-tomcat KRA" -a > transport_cert.txt certutil -A -d /tmp/drmtest/certdb/ -n "kra transport cert" -i ./transport_cert.txt -a -t "u,u,u" 4. Then just run kraclient.__main__ with no arguments. The story is still somewhat incomplete, but its a lot of code - so I want to start getting some eyes on this. Here is what I plan to add in subsequent patches: 1. Extract the NSS functionality into a separate module nssutil.py, and import that module only if python-nss is actually installed. Similarly, only define those functions that need nss if python-nss is installed. The idea here is that the client library does not necessarily require NSS. If NSS (and python-nss) is not installed, then the client needs to provide things like symmetric keys and wrapping etc. This will almost certainly be the case for Barbican, where they will generate their own keys, and do their own wrapping. 2. Complete the generate_pki_archive_options() function, and then test archival. 3. Add logic to handle exceptions. This will almost certainly take the form of decorator classes that handle the various exceptions and return codes expected. 4. The new modules pass most of the PEP8 conventions as detected by pylint. One thing that pylint does not like is having attribute names that are camelCased. The reason those are there is because they represent the actual names/attributes as passed over in JSON by the server. We populate the relevant objects by doing something like this: def from_dict(self, attr_list): ''' Return KeyInfo from JSON dict ''' for key in attr_list: setattr(self, key, attr_list[key]) return self I plan to add a small conversion function that convert camelCased attribute names to camel_cased to conform with PEP8. Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0194-Initial-work-on-python-API.patch Type: text/x-patch Size: 50436 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 12 20:58:29 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Feb 2014 14:58:29 -0600 Subject: [Pki-devel] [PATCH] 386 Fixed pagination in TPS UI. In-Reply-To: <1029171735.4520881.1392230379891.JavaMail.zimbra@redhat.com> References: <52F8F3DB.4070604@redhat.com> <1029171735.4520881.1392230379891.JavaMail.zimbra@redhat.com> Message-ID: <52FBE075.5090103@redhat.com> On 2/12/2014 12:39 PM, John Magne wrote: > ACK: Thanks. Pushed to master. > This change is pretty simple as far as the diff. > > One question, did moving to jackson cause the table size to move from 3 to 5, > or is this unrelated? It's unrelated. It was originally set to 3 just as a proof of concept. Now that it's pretty stable I changed it to 5. We might eventually settle with a larger table. -- Endi S. Dewata From edewata at redhat.com Wed Feb 12 22:15:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Feb 2014 16:15:51 -0600 Subject: [Pki-devel] [PATCH] 389 Updated REST interface for users. Message-ID: <52FBF297.7010604@redhat.com> The REST interface for users has been modified to return Response objects to allow better handling of server responses. Other REST interfaces will be modified in subsequent patches. Once all interfaces are updated, the client library can be updated to use RESTEasy 3.0 API. Clients using the client library or XML/JSON directly are not affected by these changes. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0389-Updated-REST-interface-for-users.patch Type: text/x-patch Size: 18520 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 12 22:16:00 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Feb 2014 16:16:00 -0600 Subject: [Pki-devel] [PATCH] 390 Updated REST interface for certificates. Message-ID: <52FBF2A0.3030404@redhat.com> The REST interface for certificates has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0390-Updated-REST-interface-for-certificates.patch Type: text/x-patch Size: 13662 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 12 22:16:05 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Feb 2014 16:16:05 -0600 Subject: [Pki-devel] [PATCH] 391 Updated REST interface for certificate requests. Message-ID: <52FBF2A5.4090707@redhat.com> The REST interface for certificate requests has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0391-Updated-REST-interface-for-certificate-requests.patch Type: text/x-patch Size: 20130 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 12 22:33:58 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Feb 2014 16:33:58 -0600 Subject: [Pki-devel] [PATCH] 193 - small patch to fix eclipse warnings In-Reply-To: <1392235286.4097.6.camel@aleeredhat.laptop> References: <1392235286.4097.6.camel@aleeredhat.laptop> Message-ID: <52FBF6D6.8090600@redhat.com> On 2/12/2014 2:01 PM, Ade Lee wrote: > This should be a simple cleanup to clear up some warnings. ACK. Just one thing, the commented reference to getRealArgsLength() in CRMFPOPClient.java:118 can be removed as well. It's not going to be needed once we use the Apache Commons CLI library to parse the arguments. -- Endi S. Dewata From edewata at redhat.com Thu Feb 13 17:42:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Feb 2014 11:42:18 -0600 Subject: [Pki-devel] [PATCH] 194 - Initial work for python client API In-Reply-To: <1392237697.4097.41.camel@aleeredhat.laptop> References: <1392237697.4097.41.camel@aleeredhat.laptop> Message-ID: <52FD03FA.5060109@redhat.com> On 2/12/2014 2:41 PM, Ade Lee wrote: > Hi all, > > Attached is a patch with some initial work for the Python client > library, specifically focused on the interactions between the DRM and > the python client, and the functionality exposed in the > KeyRequestResource and KeyResource REST APIs. > > The easiest way to see this code in action is to run the main function > in the KRAClient module. I usually run this in Eclipse. > > You will need to set up a few things first though: > 1. Install a CA/KRA. It this is not on the default ports, you will > need to modify the connection information in KRAClient.__main__ > > 2. The python code uses python-requests to talk to the server, and > requests uses openssl. That means you need to export your DRM admin > cert to a PEM file, so that it can be used for client auth. I did this > as follows: > > openssl pkcs12 -in ~/.dogtag/pki-tomcat/ca_admin_cert.p12 -out temp4.pem -nodes > > Without any changes, the code in KRAClient.__main__ assumes this file > will be in /tmp/temp4.pem. > > 3. We do some crypto functions using NSS commands (like generating a > symmetric key or wrapping using the transport cert). Therefore, we need > to create an NSS database and populate it with the transport cert. The > code expects it to be at /tmp/drmtest/certdb > > I did this as follows: > mkdir /tmp/drmtest/certdb > certutil -N -d /tmp/drmtest/certdb > chmod +r /tmp/drmtest/certdb/* > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "transportCert cert-pki-tomcat KRA" -a > transport_cert.txt > certutil -A -d /tmp/drmtest/certdb/ -n "kra transport cert" -i ./transport_cert.txt -a -t "u,u,u" > > 4. Then just run kraclient.__main__ with no arguments. > > The story is still somewhat incomplete, but its a lot of code - so I > want to start getting some eyes on this. > > Here is what I plan to add in subsequent patches: > > 1. Extract the NSS functionality into a separate module nssutil.py, and > import that module only if python-nss is actually installed. Similarly, > only define those functions that need nss if python-nss is installed. > > The idea here is that the client library does not necessarily require > NSS. If NSS (and python-nss) is not installed, then the client needs to > provide things like symmetric keys and wrapping etc. > > This will almost certainly be the case for Barbican, where they will > generate their own keys, and do their own wrapping. > > 2. Complete the generate_pki_archive_options() function, and then test > archival. > > 3. Add logic to handle exceptions. This will almost certainly take the > form of decorator classes that handle the various exceptions and return > codes expected. > > 4. The new modules pass most of the PEP8 conventions as detected by > pylint. One thing that pylint does not like is having attribute names > that are camelCased. The reason those are there is because they > represent the actual names/attributes as passed over in JSON by the > server. We populate the relevant objects by doing something like this: > > def from_dict(self, attr_list): > ''' Return KeyInfo from JSON dict ''' > for key in attr_list: > setattr(self, key, attr_list[key]) > return self > > I plan to add a small conversion function that convert camelCased > attribute names to camel_cased to conform with PEP8. > > Please review, > Ade Some comments: 1. The 'created' date in cert.py should be updated. 2. The CertId.__init__() doesn't parse the hex number. 3. To be consistent with the Java API, all from_dict() methods probably should be a @staticmethod or @classmethod. 4. To be consistent the decode_from_json() can be called from_json(). Is there any difference between this method and from_dict()? 5. The CertResource should be called CertClient for consistency with Java API. Same thing with KeyResource and KeyRequestResource. The *Resource classes in Java are internal implementation. The classes actually exposed to the client applications are the *Client classes. 6. The following line is executed each time getCert() is called: e.TYPES['CertData'] = CertData() It should be executed just once. See system.py. 7. The TYPES list in #6 holds references to classes, not instances. This is probably related to #3 as well. 8. The listCerts() should have passed the status as a query parameter. 9. As in #6, the following line in searchCerts() should be executed just once: e.TYPES['CertSearchRequest'] = CertSearchRequest 10. I have not tested the code, but searchCerts() doesn't seem to work with the new Jackson-style JSON format. See system.py. 11. The get_transport_cert() is defined in CertResource. In the Java API getTransportCert() is defined in SystemCertResource and used by KRAClient. There's no SystemCertClient yet, but this method should be defined there. 12. KeyRequestResponse.decode_from_json() does not populate keyData attribute. 13. As in #6, in KeyResource.retrieve_key() the e.NOTYPES registration should only be executed once. 14. The key.py's main program is a sample of a client application using the Python library, but it does the e.NOTYPES registrations. Although the registrations are only executed once, any client application should not need to do these registrations. The Python library itself should do the registrations automatically. See system.py. 15. It would be better to move the main programs in these Python library into a separate test folder because they become functional tests and contain hard-coded test configuration (e.g. hostname, port, path, request ID, client ID). Please include the instruction to setup the test environment as mentioned in the above email. 16. From client application's perspective, it would be better if the kraclient.generate_sym_key() can take a list of usages, instead of requiring the client app to join the usages manually. 17. Ideally the Key/KeyRequest-specific methods in KRAClient should be moved into KeyClient/KeyRequestClient classes to avoid cluttering up the KRAClient class. In the Java client library user-specific methods are grouped into UserClient under KRAClient. 18. Instead of adding barbican_encode() which basically wraps generate_sym_key(), the KeyRequestResponse could provide get_key_id() which will get the key ID from the requestInfo so the client app can call generate_sym_key() directly: response = kraclient.generate_sym_key(...) key_id = response.get_key_id() 19. Instead of adding barbican_decode(), the KRAClient could provide a more generic method that can be used by other client applications. Something like this: class KRAClient(object): def retrieve_key(self, key_id): response = request_recovery(key_id) approve_request(response.get_request_id()) transport_cert = get_transport_cert() session_key = generate_session_key(...) wrapped_session_key = wrap_session_key(...) request = KeyRecoveryRequest(key_id, ...) response = key_client.retrieve_key(request) return unwrap_key(response.wrappedPrivateData, ...)) Client apps such as Barbican would be able to subclass and override the generate_session_key() to provide its own key, possibly using other crypto library. -- Endi S. Dewata From edewata at redhat.com Thu Feb 13 19:21:16 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Feb 2014 13:21:16 -0600 Subject: [Pki-devel] [PATCH] 387 Fixed problem refreshing table after add. In-Reply-To: <1624964833.5224846.1392253959887.JavaMail.zimbra@redhat.com> References: <52F8FE98.7070200@redhat.com> <1624964833.5224846.1392253959887.JavaMail.zimbra@redhat.com> Message-ID: <52FD1B2C.8010506@redhat.com> On 2/12/2014 7:12 PM, John Magne wrote: > ACK Thanks. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Feb 14 18:17:54 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Feb 2014 12:17:54 -0600 Subject: [Pki-devel] [PATCH] 392 Updated REST interface for groups. Message-ID: <52FE5DD2.1060806@redhat.com> The REST interface for groups has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0392-Updated-REST-interface-for-groups.patch Type: text/x-patch Size: 12205 bytes Desc: not available URL: From edewata at redhat.com Fri Feb 14 18:18:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Feb 2014 12:18:52 -0600 Subject: [Pki-devel] [PATCH] 393 Updated REST interface for account. Message-ID: <52FE5E0C.8000308@redhat.com> The REST interface for account has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0393-Updated-REST-interface-for-account.patch Type: text/x-patch Size: 4530 bytes Desc: not available URL: From edewata at redhat.com Fri Feb 14 18:24:12 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Feb 2014 12:24:12 -0600 Subject: [Pki-devel] [PATCH] 394 Updated REST interface for audit. Message-ID: <52FE5F4C.5010409@redhat.com> The REST interface for audit has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0394-Updated-REST-interface-for-audit.patch Type: text/x-patch Size: 3328 bytes Desc: not available URL: From edewata at redhat.com Fri Feb 14 20:08:45 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Feb 2014 14:08:45 -0600 Subject: [Pki-devel] [PATCH] 395 Updated REST interface for self tests. Message-ID: <52FE77CD.7070701@redhat.com> The REST interface for self tests has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0395-Updated-REST-interface-for-self-tests.patch Type: text/x-patch Size: 6623 bytes Desc: not available URL: From edewata at redhat.com Fri Feb 14 20:09:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Feb 2014 14:09:35 -0600 Subject: [Pki-devel] [PATCH] 396 Updated REST interface for TPS connectors. Message-ID: <52FE77FF.8030703@redhat.com> The REST interface for TPS connectors has been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0396-Updated-REST-interface-for-TPS-connectors.patch Type: text/x-patch Size: 17693 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 17 15:11:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Feb 2014 09:11:18 -0600 Subject: [Pki-devel] 397-404 Updated REST interfaces for TPS Message-ID: <53022696.1090705@redhat.com> All REST interfaces for TPS have been modified to return Response objects. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0397-Updated-REST-interface-for-TPS-activities.patch Type: text/x-patch Size: 5425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0398-Updated-REST-interface-for-TPS-authenticators.patch Type: text/x-patch Size: 8120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0399-Updated-REST-interface-for-TPS-certificates.patch Type: text/x-patch Size: 5286 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0400-Updated-REST-interface-for-TPS-configuration.patch Type: text/x-patch Size: 3264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0401-Updated-REST-interface-for-TPS-connections.patch Type: text/x-patch Size: 7748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0402-Updated-REST-interface-for-TPS-profiles.patch Type: text/x-patch Size: 7263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0403-Updated-REST-interface-for-TPS-profile-mappings.patch Type: text/x-patch Size: 8150 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0404-Updated-REST-interface-for-TPS-tokens.patch Type: text/x-patch Size: 7214 bytes Desc: not available URL: From alee at redhat.com Mon Feb 17 17:36:13 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 17 Feb 2014 12:36:13 -0500 Subject: [Pki-devel] [PATCH] 194 - Initial work for python client API In-Reply-To: <52FD03FA.5060109@redhat.com> References: <1392237697.4097.41.camel@aleeredhat.laptop> <52FD03FA.5060109@redhat.com> Message-ID: <1392658573.25872.2.camel@aleeredhat.laptop> See inline below: On Thu, 2014-02-13 at 11:42 -0600, Endi Sukma Dewata wrote: > On 2/12/2014 2:41 PM, Ade Lee wrote: > > Hi all, > > > > Attached is a patch with some initial work for the Python client > > library, specifically focused on the interactions between the DRM and > > the python client, and the functionality exposed in the > > KeyRequestResource and KeyResource REST APIs. > > > > The easiest way to see this code in action is to run the main function > > in the KRAClient module. I usually run this in Eclipse. > > > > You will need to set up a few things first though: > > 1. Install a CA/KRA. It this is not on the default ports, you will > > need to modify the connection information in KRAClient.__main__ > > > > 2. The python code uses python-requests to talk to the server, and > > requests uses openssl. That means you need to export your DRM admin > > cert to a PEM file, so that it can be used for client auth. I did this > > as follows: > > > > openssl pkcs12 -in ~/.dogtag/pki-tomcat/ca_admin_cert.p12 -out temp4.pem -nodes > > > > Without any changes, the code in KRAClient.__main__ assumes this file > > will be in /tmp/temp4.pem. > > > > 3. We do some crypto functions using NSS commands (like generating a > > symmetric key or wrapping using the transport cert). Therefore, we need > > to create an NSS database and populate it with the transport cert. The > > code expects it to be at /tmp/drmtest/certdb > > > > I did this as follows: > > mkdir /tmp/drmtest/certdb > > certutil -N -d /tmp/drmtest/certdb > > chmod +r /tmp/drmtest/certdb/* > > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "transportCert cert-pki-tomcat KRA" -a > transport_cert.txt > > certutil -A -d /tmp/drmtest/certdb/ -n "kra transport cert" -i ./transport_cert.txt -a -t "u,u,u" > > > > 4. Then just run kraclient.__main__ with no arguments. > > > > The story is still somewhat incomplete, but its a lot of code - so I > > want to start getting some eyes on this. > > > > Here is what I plan to add in subsequent patches: > > > > 1. Extract the NSS functionality into a separate module nssutil.py, and > > import that module only if python-nss is actually installed. Similarly, > > only define those functions that need nss if python-nss is installed. > > > > The idea here is that the client library does not necessarily require > > NSS. If NSS (and python-nss) is not installed, then the client needs to > > provide things like symmetric keys and wrapping etc. > > > > This will almost certainly be the case for Barbican, where they will > > generate their own keys, and do their own wrapping. > > > > 2. Complete the generate_pki_archive_options() function, and then test > > archival. > > > > 3. Add logic to handle exceptions. This will almost certainly take the > > form of decorator classes that handle the various exceptions and return > > codes expected. > > > > 4. The new modules pass most of the PEP8 conventions as detected by > > pylint. One thing that pylint does not like is having attribute names > > that are camelCased. The reason those are there is because they > > represent the actual names/attributes as passed over in JSON by the > > server. We populate the relevant objects by doing something like this: > > > > def from_dict(self, attr_list): > > ''' Return KeyInfo from JSON dict ''' > > for key in attr_list: > > setattr(self, key, attr_list[key]) > > return self > > > > I plan to add a small conversion function that convert camelCased > > attribute names to camel_cased to conform with PEP8. > > > > Please review, > > Ade > > Some comments: > > 1. The 'created' date in cert.py should be updated. > Done - also added a note that the implementation in cert.py is incomplete and needs to be tested. > 2. The CertId.__init__() doesn't parse the hex number. > Will be fixed in subsequent patch. > 3. To be consistent with the Java API, all from_dict() methods probably > should be a @staticmethod or @classmethod. > Done. > 4. To be consistent the decode_from_json() can be called from_json(). Is > there any difference between this method and from_dict()? > Done. > 5. The CertResource should be called CertClient for consistency with > Java API. Same thing with KeyResource and KeyRequestResource. The > *Resource classes in Java are internal implementation. The classes > actually exposed to the client applications are the *Client classes. > Done. > 6. The following line is executed each time getCert() is called: > e.TYPES['CertData'] = CertData() > It should be executed just once. See system.py. > Done. > 7. The TYPES list in #6 holds references to classes, not instances. This > is probably related to #3 as well. > Done. > 8. The listCerts() should have passed the status as a query parameter. > Will be fixed in subsequent patch when certs are addressed. > 9. As in #6, the following line in searchCerts() should be executed just > once: > e.TYPES['CertSearchRequest'] = CertSearchRequest > Done. > 10. I have not tested the code, but searchCerts() doesn't seem to work > with the new Jackson-style JSON format. See system.py. > Will be fixed in subsequent patch when cert.py is fixed. > 11. The get_transport_cert() is defined in CertResource. In the Java API > getTransportCert() is defined in SystemCertResource and used by > KRAClient. There's no SystemCertClient yet, but this method should be > defined there. > Done > 12. KeyRequestResponse.decode_from_json() does not populate keyData > attribute. > Fixed. > 13. As in #6, in KeyResource.retrieve_key() the e.NOTYPES registration > should only be executed once. > Fixed. > 14. The key.py's main program is a sample of a client application using > the Python library, but it does the e.NOTYPES registrations. Although > the registrations are only executed once, any client application should > not need to do these registrations. The Python library itself should do > the registrations automatically. See system.py. > Fixed. > 15. It would be better to move the main programs in these Python library > into a separate test folder because they become functional tests and > contain hard-coded test configuration (e.g. hostname, port, path, > request ID, client ID). Please include the instruction to setup the test > environment as mentioned in the above email. > Done - put into kra/functional/drmtest.py and added drmtest.readme.txt. Also changed the name of drmclient.py and its readme to drmclient_deprecated.py. We will remove these files as soon as we have extracted all the useful code out of them. > 16. From client application's perspective, it would be better if the > kraclient.generate_sym_key() can take a list of usages, instead of > requiring the client app to join the usages manually. > Done > 17. Ideally the Key/KeyRequest-specific methods in KRAClient should be > moved into KeyClient/KeyRequestClient classes to avoid cluttering up the > KRAClient class. In the Java client library user-specific methods are > grouped into UserClient under KRAClient. > > 18. Instead of adding barbican_encode() which basically wraps > generate_sym_key(), the KeyRequestResponse could provide get_key_id() > which will get the key ID from the requestInfo so the client app can > call generate_sym_key() directly: > > response = kraclient.generate_sym_key(...) > key_id = response.get_key_id() > Done > 19. Instead of adding barbican_decode(), the KRAClient could provide a > more generic method that can be used by other client applications. > Something like this: > > class KRAClient(object): > def retrieve_key(self, key_id): > > response = request_recovery(key_id) > approve_request(response.get_request_id()) > > transport_cert = get_transport_cert() > session_key = generate_session_key(...) > wrapped_session_key = wrap_session_key(...) > > request = KeyRecoveryRequest(key_id, ...) > response = key_client.retrieve_key(request) > > return unwrap_key(response.wrappedPrivateData, ...)) > > Client apps such as Barbican would be able to subclass and override the > generate_session_key() to provide its own key, possibly using other > crypto library. > OK - there have been a bunch of changes to address this. I have also extracted the crypto functionality. See the commit message. Attached is a new patch. Please apply this on top of the previous patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0195-Additional-changes-as-per-review.patch Type: text/x-patch Size: 68809 bytes Desc: not available URL: From alee at redhat.com Mon Feb 17 17:38:13 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 17 Feb 2014 12:38:13 -0500 Subject: [Pki-devel] [PATCH] 196 - Add decorator to handle exceptions Message-ID: <1392658693.25872.4.camel@aleeredhat.laptop> Added decorator to handle exceptions Decorator catches HttpErrorExceptions from Requests and extracts the relevant PKIException object, and rethrows it. Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0196-Added-decorator-to-handle-exceptions.patch Type: text/x-patch Size: 36195 bytes Desc: not available URL: From edewata at redhat.com Tue Feb 18 16:39:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Feb 2014 10:39:19 -0600 Subject: [Pki-devel] [PATCH] 389 Updated REST interface for users. In-Reply-To: <52FBF297.7010604@redhat.com> References: <52FBF297.7010604@redhat.com> Message-ID: <53038CB7.7070502@redhat.com> On 2/12/2014 4:15 PM, Endi Sukma Dewata wrote: > The REST interface for users has been modified to return Response > objects to allow better handling of server responses. Other REST > interfaces will be modified in subsequent patches. Once all interfaces > are updated, the client library can be updated to use RESTEasy 3.0 API. > Clients using the client library or XML/JSON directly are not affected > by these changes. > > Ticket #554 Ade ACKed patch #389-404. Pushed everything to master. -- Endi S. Dewata From edewata at redhat.com Tue Feb 18 18:02:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Feb 2014 12:02:24 -0600 Subject: [Pki-devel] [PATCH] 194 - Initial work for python client API In-Reply-To: <1392658573.25872.2.camel@aleeredhat.laptop> References: <1392237697.4097.41.camel@aleeredhat.laptop> <52FD03FA.5060109@redhat.com> <1392658573.25872.2.camel@aleeredhat.laptop> Message-ID: <5303A030.9090108@redhat.com> On 2/17/2014 11:36 AM, Ade Lee wrote: >> 4. To be consistent the decode_from_json() can be called from_json(). Is >> there any difference between this method and from_dict()? >> > Done. For consistency should they all be called from_json()? >> 16. From client application's perspective, it would be better if the >> kraclient.generate_sym_key() can take a list of usages, instead of >> requiring the client app to join the usages manually. > > Done In key.py, the SymKeyGenerationRequest constructor takes a list of key_usages string to be concatenated later, but in the main program it's taking an already concatenated list of usages. >> 17. Ideally the Key/KeyRequest-specific methods in KRAClient should be >> moved into KeyClient/KeyRequestClient classes to avoid cluttering up the >> KRAClient class. In the Java client library user-specific methods are >> grouped into UserClient under KRAClient. The KRAClient still has key-specific operations such as retrieve_key(), generate_sym_key(), etc. Should they be moved into KeyClient as well? 20. As mentioned on IRC, the drmtest setup requires manually importing the transport cert. Also the KRAClient constructor takes the transport cert nickname. Shouldn't the KRAClient get the transport cert directly from the server and import it to the client database? 21. Also already discussed on IRC, the NSSCryptoUtil contains hardcoded nonce_iv default value. It probably should be random. 22. The symmetric_unwrap() takes base-64-encoded data and nonce_iv parameters. I think usually the caller would have to provide undecoded data. -- Endi S. Dewata From edewata at redhat.com Tue Feb 18 19:55:45 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Feb 2014 13:55:45 -0600 Subject: [Pki-devel] [PATCH] 196 - Add decorator to handle exceptions In-Reply-To: <1392658693.25872.4.camel@aleeredhat.laptop> References: <1392658693.25872.4.camel@aleeredhat.laptop> Message-ID: <5303BAC1.2070505@redhat.com> On 2/17/2014 11:38 AM, Ade Lee wrote: > Added decorator to handle exceptions > > Decorator catches HttpErrorExceptions from Requests > and extracts the relevant PKIException object, and rethrows > it. ACK. Just some comments: 1. In EXCEPTION_MAPPINGS is it possible to map to the exception class directly? For example: EXCEPTION_MAPPINGS = { "com.netscape.certsrv.base.BadRequestException": pki.BadRequestException, ... } This way it's not necessary to interpret the string class name. 2. I'm thinking we may not need the individual NotFoundException for Cert, Group, Profile, and User. So far I don't see a lot of benefit in the Java version. We might be able to just use the base ResourceNotFoundException. -- Endi S. Dewata From edewata at redhat.com Tue Feb 18 20:49:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Feb 2014 14:49:28 -0600 Subject: [Pki-devel] [PATCH] 405-407 Remaining REST changes Message-ID: <5303C758.90901@redhat.com> The REST client/interface for CA profiles, system certificates, and keys have been modified to return Response objects to allow better handling of server responses. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0405-Updated-REST-interface-for-CA-profiles.patch Type: text/x-patch Size: 13258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0406-Added-REST-client-for-system-certificates.patch Type: text/x-patch Size: 7197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0407-Updated-REST-interface-for-keys.patch Type: text/x-patch Size: 43070 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 19 16:13:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Feb 2014 10:13:21 -0600 Subject: [Pki-devel] [PATCH] 405-407 Remaining REST changes In-Reply-To: <5303C758.90901@redhat.com> References: <5303C758.90901@redhat.com> Message-ID: <5304D821.5080902@redhat.com> On 2/18/2014 2:49 PM, Endi Sukma Dewata wrote: > The REST client/interface for CA profiles, system certificates, and keys > have been modified to return Response objects to allow better handling > of server responses. > > Ticket #554 ACKed by Ade. Pushed to master. Renamed getActiveKey() into getActiveKeyInfo() and fixed the return type to KeyInfo. The KeyRequestResource update will be added in a separate patch. -- Endi S. Dewata From edewata at redhat.com Wed Feb 19 16:29:38 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Feb 2014 10:29:38 -0600 Subject: [Pki-devel] [PATCH] 408-409 More REST changes Message-ID: <5304DBF2.2090707@redhat.com> Attached are some changes to the key requests REST interface and group member processor. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0408-Updated-REST-interface-for-key-requests.patch Type: text/x-patch Size: 8494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0409-Refactored-GroupMemberProcessor.patch Type: text/x-patch Size: 3090 bytes Desc: not available URL: From alee at redhat.com Wed Feb 19 17:26:03 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Feb 2014 12:26:03 -0500 Subject: [Pki-devel] [PATCH] 197 - Add getKeyInfo and modifyKeyStatus Message-ID: <1392830763.16167.9.camel@aleeredhat.laptop> Added methods to get key info and modify key status (along with python and java tests). Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0197-Add-methods-to-getKeyInfo-and-change-key-status.patch Type: text/x-patch Size: 22193 bytes Desc: not available URL: From edewata at redhat.com Wed Feb 19 17:52:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Feb 2014 11:52:25 -0600 Subject: [Pki-devel] [PATCH] 408-409 More REST changes In-Reply-To: <5304DBF2.2090707@redhat.com> References: <5304DBF2.2090707@redhat.com> Message-ID: <5304EF59.4020408@redhat.com> On 2/19/2014 10:29 AM, Endi Sukma Dewata wrote: > Attached are some changes to the key requests REST interface and group > member processor. ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Wed Feb 19 18:18:20 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Feb 2014 13:18:20 -0500 Subject: [Pki-devel] [PATCH] 197 - Add getKeyInfo and modifyKeyStatus In-Reply-To: <1392830763.16167.9.camel@aleeredhat.laptop> References: <1392830763.16167.9.camel@aleeredhat.laptop> Message-ID: <1392833900.27598.0.camel@aleeredhat.laptop> Acked my Endi with changes as detailed on IRC. Pushed to master. On Wed, 2014-02-19 at 12:26 -0500, Ade Lee wrote: > Added methods to get key info and modify key status (along with python > and java tests). > > Please review. > > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Feb 19 18:25:04 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Feb 2014 13:25:04 -0500 Subject: [Pki-devel] [PATCH] 196 - Add decorator to handle exceptions In-Reply-To: <5303BAC1.2070505@redhat.com> References: <1392658693.25872.4.camel@aleeredhat.laptop> <5303BAC1.2070505@redhat.com> Message-ID: <1392834304.27598.2.camel@aleeredhat.laptop> Pushed to master. Will address comment 1 in separate patch. Comment 2 deferred to later discussion. On Tue, 2014-02-18 at 13:55 -0600, Endi Sukma Dewata wrote: > On 2/17/2014 11:38 AM, Ade Lee wrote: > > Added decorator to handle exceptions > > > > Decorator catches HttpErrorExceptions from Requests > > and extracts the relevant PKIException object, and rethrows > > it. > > ACK. Just some comments: > > 1. In EXCEPTION_MAPPINGS is it possible to map to the exception class > directly? For example: > > EXCEPTION_MAPPINGS = { > "com.netscape.certsrv.base.BadRequestException": > pki.BadRequestException, > ... > } > > This way it's not necessary to interpret the string class name. > > 2. I'm thinking we may not need the individual > NotFoundException for Cert, Group, Profile, and User. So far I > don't see a lot of benefit in the Java version. We might be able to just > use the base ResourceNotFoundException. > From alee at redhat.com Wed Feb 19 18:26:51 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Feb 2014 13:26:51 -0500 Subject: [Pki-devel] [PATCH] 194 - Initial work for python client API In-Reply-To: <5303A030.9090108@redhat.com> References: <1392237697.4097.41.camel@aleeredhat.laptop> <52FD03FA.5060109@redhat.com> <1392658573.25872.2.camel@aleeredhat.laptop> <5303A030.9090108@redhat.com> Message-ID: <1392834411.27598.4.camel@aleeredhat.laptop> So we can see the status of things, pushed to master. Will address issues below in a separate patch. Also, will address jmagne suggestion to make the functions in CrytoUtil more generic - in particular generate_symmetric_key Ade On Tue, 2014-02-18 at 12:02 -0600, Endi Sukma Dewata wrote: > On 2/17/2014 11:36 AM, Ade Lee wrote: > >> 4. To be consistent the decode_from_json() can be called from_json(). Is > >> there any difference between this method and from_dict()? > >> > > Done. > > For consistency should they all be called from_json()? > > >> 16. From client application's perspective, it would be better if the > >> kraclient.generate_sym_key() can take a list of usages, instead of > >> requiring the client app to join the usages manually. > > > > Done > > In key.py, the SymKeyGenerationRequest constructor takes a list of > key_usages string to be concatenated later, but in the main program it's > taking an already concatenated list of usages. > > >> 17. Ideally the Key/KeyRequest-specific methods in KRAClient should be > >> moved into KeyClient/KeyRequestClient classes to avoid cluttering up the > >> KRAClient class. In the Java client library user-specific methods are > >> grouped into UserClient under KRAClient. > > The KRAClient still has key-specific operations such as retrieve_key(), > generate_sym_key(), etc. Should they be moved into KeyClient as well? > > 20. As mentioned on IRC, the drmtest setup requires manually importing > the transport cert. Also the KRAClient constructor takes the transport > cert nickname. Shouldn't the KRAClient get the transport cert directly > from the server and import it to the client database? > > 21. Also already discussed on IRC, the NSSCryptoUtil contains hardcoded > nonce_iv default value. It probably should be random. > > 22. The symmetric_unwrap() takes base-64-encoded data and nonce_iv > parameters. I think usually the caller would have to provide undecoded data. > From klamb at redhat.com Thu Feb 20 17:44:58 2014 From: klamb at redhat.com (Kent Lamb) Date: Thu, 20 Feb 2014 12:44:58 -0500 Subject: [Pki-devel] [PATCH] NIST SP800-108 KDF Message-ID: Hi all, The attached patches allow for newer NIST approved stronger algorithms for KDF. See NIST Special Publication 800-108. Most of the impact is in symkey. Additional mods were required for some backwards compatibility for existing card stocks that are in use under the current RHCS8.x diversification scheme. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-tks_nistSP800-108KDF.patch Type: application/octet-stream Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: symkey_nistSP800-108KDF_invocationLogic_keyVersionDecodeFix_miscFixes.patch Type: application/octet-stream Size: 62946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: symkey_nistSP800-108KDF_makefile.patch Type: application/octet-stream Size: 5899 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: symkey_nistSP800-108KDF_newSourceFiles.patch Type: application/octet-stream Size: 29232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: symkey_nistSP800-108KDF_signatureChange.patch Type: application/octet-stream Size: 18525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-common_nistSP800-108KDF_keyVersionDecodeFix.patch Type: application/octet-stream Size: 82751 bytes Desc: not available URL: -------------- next part -------------- Thanks Kent From klamb at redhat.com Thu Feb 20 17:48:19 2014 From: klamb at redhat.com (Kent Lamb) Date: Thu, 20 Feb 2014 12:48:19 -0500 Subject: [Pki-devel] [PATCH] GP Key Sanity Checks Message-ID: Hi, The attached TPS patch is for GP Key checks as will be required by an upcoming DoD spec doc. Doc is currently in early draft stages. -kent -------------- next part -------------- A non-text attachment was scrubbed... Name: cuid.patch Type: application/octet-stream Size: 85948 bytes Desc: not available URL: From klamb at redhat.com Thu Feb 20 17:52:12 2014 From: klamb at redhat.com (Kent Lamb) Date: Thu, 20 Feb 2014 12:52:12 -0500 Subject: [Pki-devel] [PATCH] pki-common key fixes Message-ID: <8D8BC508-7F63-47AA-A68D-CA447DD92FCB@redhat.com> Hi, In working for the NIST SP800-108 and GP key sanity check patches, some additional items were found with ComputeSessionKey error reporting and DiversifyKey mkmappings -kent -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-common_processComputeSessionKey_fixedErrorReporting.patch Type: application/octet-stream Size: 2021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-common_processDiversifyKey_fixedmkmappings.patch Type: application/octet-stream Size: 987 bytes Desc: not available URL: From edewata at redhat.com Thu Feb 20 17:52:57 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Feb 2014 11:52:57 -0600 Subject: [Pki-devel] [PATCH] 410 Upgraded RESTEasy client library. Message-ID: <530640F9.3080606@redhat.com> The Dogtag client library has been modified to use RESTEasy 3.0 client library. A new upgrade script has been added to update existing servers. The JAXB annotation in ResourceMessage has been modified to require explicit property mapping. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0410-Upgraded-RESTEasy-client-library.patch Type: text/x-patch Size: 32637 bytes Desc: not available URL: From edewata at redhat.com Thu Feb 20 17:54:20 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Feb 2014 11:54:20 -0600 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. Message-ID: <5306414C.8060007@redhat.com> A new CLI parameter has been added to specify the format of the HTTP messages exchanged between the client and server. This is done by setting the default consumes and produces when creating the proxy. For this to work the @Consumes and @Produces annotations will be removed in the subsequent patch. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0411-Added-CLI-parameter-to-select-message-format.patch Type: text/x-patch Size: 8406 bytes Desc: not available URL: From edewata at redhat.com Thu Feb 20 17:56:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Feb 2014 11:56:18 -0600 Subject: [Pki-devel] [PATCH] 412 Removed @Consumes and @Provides. Message-ID: <530641C2.2070709@redhat.com> The @Consumes and @Provides annotations have been removed from all methods (except from methods that consume forms) to allow client to use the default consumes and provides specified in the proxy. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0412-Removed-Consumes-and-Provides.patch Type: text/x-patch Size: 57484 bytes Desc: not available URL: From nkinder at redhat.com Thu Feb 20 21:37:40 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 20 Feb 2014 13:37:40 -0800 Subject: [Pki-devel] [PATCH] pki-common key fixes In-Reply-To: <8D8BC508-7F63-47AA-A68D-CA447DD92FCB@redhat.com> References: <8D8BC508-7F63-47AA-A68D-CA447DD92FCB@redhat.com> Message-ID: <530675A4.6040308@redhat.com> On 02/20/2014 09:52 AM, Kent Lamb wrote: > Hi, > > In working for the NIST SP800-108 and GP key sanity check patches, some additional items were found with ComputeSessionKey error reporting and DiversifyKey mkmappings Hi Kent, We should file trac tickets for the issues that these patches address. This will allos us to target a Dogtag release and track these items. Would you mind creating tickets here?: https://fedorahosted.org/pki/ Thanks! -NGK > > -kent > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From edewata at redhat.com Thu Feb 20 22:31:09 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Feb 2014 16:31:09 -0600 Subject: [Pki-devel] [PATCH] 412 Removed @Consumes and @Provides. In-Reply-To: <530641C2.2070709@redhat.com> References: <530641C2.2070709@redhat.com> Message-ID: <5306822D.8070105@redhat.com> On 2/20/2014 11:56 AM, Endi Sukma Dewata wrote: > The @Consumes and @Provides annotations have been removed from all > methods (except from methods that consume forms) to allow client > to use the default consumes and provides specified in the proxy. > > Ticket #554 Added missing changes. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0412-1-Removed-Consumes-and-Provides.patch Type: text/x-patch Size: 57985 bytes Desc: not available URL: From klamb at redhat.com Fri Feb 21 13:23:43 2014 From: klamb at redhat.com (Kent Lamb) Date: Fri, 21 Feb 2014 08:23:43 -0500 Subject: [Pki-devel] [PATCH] pki-common key fixes In-Reply-To: <530675A4.6040308@redhat.com> References: <8D8BC508-7F63-47AA-A68D-CA447DD92FCB@redhat.com> <530675A4.6040308@redhat.com> Message-ID: <1982F952-E9D3-4C35-A5A8-8025F3AA3765@redhat.com> Trac ticket 864 thanks On Feb 20, 2014, at 4:37 PM, Nathan Kinder wrote: > On 02/20/2014 09:52 AM, Kent Lamb wrote: >> Hi, >> >> In working for the NIST SP800-108 and GP key sanity check patches, some additional items were found with ComputeSessionKey error reporting and DiversifyKey mkmappings > > Hi Kent, > > We should file trac tickets for the issues that these patches address. > This will allos us to target a Dogtag release and track these items. > Would you mind creating tickets here?: > > https://fedorahosted.org/pki/ > > Thanks! > -NGK > >> >> -kent >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel >> > Kent Lamb Manager, Public Sector Strategic Customer Engagement 919-754-4909 (office) 919-818-7595 (cell) From klamb at redhat.com Fri Feb 21 13:24:06 2014 From: klamb at redhat.com (Kent Lamb) Date: Fri, 21 Feb 2014 08:24:06 -0500 Subject: [Pki-devel] [PATCH] NIST SP800-108 KDF In-Reply-To: References: Message-ID: Trac ticket 864 On Feb 20, 2014, at 12:44 PM, Kent Lamb wrote: > Hi all, > > The attached patches allow for newer NIST approved stronger algorithms for KDF. See NIST Special Publication 800-108. Most of the impact is in symkey. Additional mods were required for some backwards compatibility for existing card stocks that are in use under the current RHCS8.x diversification scheme. > > > > Thanks > > Kent > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Kent Lamb Manager, Public Sector Strategic Customer Engagement 919-754-4909 (office) 919-818-7595 (cell) From klamb at redhat.com Fri Feb 21 13:25:33 2014 From: klamb at redhat.com (Kent Lamb) Date: Fri, 21 Feb 2014 08:25:33 -0500 Subject: [Pki-devel] [PATCH] GP Key Sanity Checks In-Reply-To: References: Message-ID: Trac ticket 865 On Feb 20, 2014, at 12:48 PM, Kent Lamb wrote: > The attached TPS patch is for GP Key checks as will be required by an upcoming DoD spec doc. Doc is currently in early draft stages. From klamb at redhat.com Fri Feb 21 13:27:50 2014 From: klamb at redhat.com (Kent Lamb) Date: Fri, 21 Feb 2014 08:27:50 -0500 Subject: [Pki-devel] [PATCH] pki-common key fixes In-Reply-To: <1982F952-E9D3-4C35-A5A8-8025F3AA3765@redhat.com> References: <8D8BC508-7F63-47AA-A68D-CA447DD92FCB@redhat.com> <530675A4.6040308@redhat.com> <1982F952-E9D3-4C35-A5A8-8025F3AA3765@redhat.com> Message-ID: <77897DA6-D858-4FE8-B157-1A3E38A54F5B@redhat.com> sorry - correct trac number is 866 On Feb 21, 2014, at 8:23 AM, Kent Lamb wrote: > Trac ticket 864 > > thanks > > > On Feb 20, 2014, at 4:37 PM, Nathan Kinder wrote: > >> On 02/20/2014 09:52 AM, Kent Lamb wrote: >>> Hi, >>> >>> In working for the NIST SP800-108 and GP key sanity check patches, some additional items were found with ComputeSessionKey error reporting and DiversifyKey mkmappings >> >> Hi Kent, >> >> We should file trac tickets for the issues that these patches address. >> This will allos us to target a Dogtag release and track these items. >> Would you mind creating tickets here?: >> >> https://fedorahosted.org/pki/ >> >> Thanks! >> -NGK >> >>> >>> -kent >>> >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >> > > From edewata at redhat.com Sat Feb 22 03:49:53 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 21 Feb 2014 21:49:53 -0600 Subject: [Pki-devel] [PATCH] 413 Reorganized REST service classes. Message-ID: <53081E61.1030604@redhat.com> The REST service classes have been moved into org.dogtagpki.server namespace. A new upgrade script has been added to update existing instances. Ticket #114 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0413-Reorganized-REST-service-classes.patch Type: text/x-patch Size: 86419 bytes Desc: not available URL: From alee at redhat.com Sat Feb 22 05:52:18 2014 From: alee at redhat.com (Ade Lee) Date: Sat, 22 Feb 2014 00:52:18 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. Message-ID: <1393048338.14191.25.camel@aleeredhat.laptop> Endi, Jack and I met to discuss various improvements to the Key/KeyResource client/server parts. Some of these are addressed in the attached patches. Some will be handled in separate tickets. Separate Tickets to be filed: 1. Add nonce mechanism for approvals. 2. Add openssl subclass for CryptoUtil 3. Extend generate_session_key() to return key in same call 4. Allow CLI to call python? (to be filed as separate ticket) Done in attached patches: 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key and extend to allow addition of trans_wrapped_session_key. 6. Add getActiveKey() to python client. 7. client_id -> client_key_id 8. constants in python API for key status 9. Add sanity checks to python client code 10. Move functions out of KRAClient.py and into key.py 11. from_dict() -> from)json() 12. Add methods to create nss certdb and import transport cert 13. All inputs/outputs from CryptoUtil are unencoded. 14. Fix usages in main function of SymKeyGenerationRequest 15. Fix bugs when retrieving invalid keyId. 16. Fix bugs when generating key with only clientID provided. To be done in next patch: 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and provide a more restricted convenience function generate_session_key() To be considered further: 1. rename session_key -> encryption_key/ wrapping_key? 2. revamp archival to not require client to generate PkiArchiveOptions object. 3. should retrieve functions return unwrapped key? Please review attached patches. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0198-Fix-minor-issues-from-review.patch Type: text/x-patch Size: 10460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0199-Add-methods-to-create-nss-certdb-and-import-cert.patch Type: text/x-patch Size: 9977 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0203-Added-error-checking-in-python-client-calls.patch Type: text/x-patch Size: 26479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0202-Moved-key-functions-out-of-kraclient.py.patch Type: text/x-patch Size: 40611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0201-reame-client_id-to-client_key_id.patch Type: text/x-patch Size: 65514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0200-Add-getActiveKey-to-the-python-client.patch Type: text/x-patch Size: 2844 bytes Desc: not available URL: From edewata at redhat.com Mon Feb 24 17:27:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Feb 2014 11:27:52 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <530B8118.1090105@redhat.com> On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade ACK for patch #198. Just some minor comments: 1. The get_class() may not be needed anymore. 2. Instead of json_value['KeyData'] should we use json_value.KeyData? 3. SymKeyGenerationRequest.DECRYPT_USAGE is kind of long and limited o generation request. Maybe we should have something like SymKey.DECRYPT_USAGE? Still reviewing the other patches. -- Endi S. Dewata From edewata at redhat.com Mon Feb 24 20:53:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Feb 2014 14:53:37 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <530BB151.3060401@redhat.com> On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade Patch #199: 1. The setup_database() throws a ValueError if the database already exists. raise exceptions.ValueError( "Directory already exists and over_write is false") I'm not sure it's an appropriate exception: http://docs.python.org/2/library/exceptions.html#exceptions.ValueError. We probably could just throw a generic Exception. 2. The error message probably should just say "Directory already exists". The end user should not see a variable name in the error message. If the program ends with this error the user would know that an existing database causes a conflict, so either they will remove it or use a different path or overwrite it with a flag. 3. Since we're storing password, in NamedTemporaryFile() we probably should specify some params to use user's temp dir instead of global temp dir, and delete the temp file after closing. See: http://docs.python.org/2/library/tempfile.html. 4. Minor thing. The data param in symmetric_unwrap() doc is followed by a colon, which is inconsistent with the other params in that doc. :param data: Data to be unwrapped Is there a standard way of documenting params? 5. The "!=" operator could be replaced with "is not". if transport_cert_nick is not None: 6. I think ideally client shouldn't be required to encode/decode the trans_wrapped_session_key, wrappedPrivateData, nonceData, transport_cert, etc. The base64 encoding should only be part of marshalling/unmarshalling, hidden from the client. Thoughts? 7. Can these 3 invocations be combined: cryptoutil.NSSCryptoUtil.setup_database( certdb_dir, certdb_password, over_write=True) crypto = cryptoutil.NSSCryptoUtil(certdb_dir, certdb_password) crypto.initialize_db() into this? crypto = cryptoutil.NSSCryptoUtil( certdb_dir, certdb_password, over_write=True) Just a question, is it possible to use 2 different NSS databases at the same time? -- Endi S. Dewata From edewata at redhat.com Mon Feb 24 20:58:08 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Feb 2014 14:58:08 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <530BB260.4050900@redhat.com> On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade ACK for patch #200. Just one comment, get_key_info() throws KeyNotFoundException and get_active_key_info() throws ResourceNotFoundException. I think they should be consistent. Also consider removing the resource-specific *NotFoundExceptions. -- Endi S. Dewata From edewata at redhat.com Mon Feb 24 21:27:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Feb 2014 15:27:21 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <530BB939.5020509@redhat.com> On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade ACK for patch #201. Some comments: 1. Are we going to change the attribute name in the LDAP database? If so do we need to upgrade the existing database? 2. The "client" options in the CLIs probably should be renamed to "client-key". 3. In drmtest.py the label should be changed to "Client Key ID: ". print "Client ID: " + str(key_info.clientKeyID) 4. Is this supposed to be removed? #client_key_id = "Vek #1" + time.strftime('%X %x %Z') client_key_id = "abcxyz" 5. Existing issue, the toString() is redundant. clientKeyId = "UUID: 123-45-6789 VEK " + Calendar.getInstance().getTime().toString(); On the second thought, what do you think about using "key label" instead of "client key ID"? So Key ID would remain the unique identifier for the key, and the Key Label would be an identifier but it's not unique. No need to redo the whole patch, just search & replace the patch. I can help with this. -- Endi S. Dewata From jmagne at redhat.com Mon Feb 24 22:20:10 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Feb 2014 17:20:10 -0500 (EST) Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530BB151.3060401@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB151.3060401@redhat.com> Message-ID: <1574717522.16150680.1393280410975.JavaMail.zimbra@redhat.com> I'll piggy back on this ACK. Just a few comments interspersed. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: alee at redhat.com, pki-devel at redhat.com > Sent: Monday, February 24, 2014 12:53:37 PM > Subject: Re: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > On 2/21/2014 11:52 PM, Ade Lee wrote: > > Endi, Jack and I met to discuss various improvements to the > > Key/KeyResource client/server parts. Some of these are addressed in the > > attached patches. Some will be handled in separate tickets. > > > > Separate Tickets to be filed: > > 1. Add nonce mechanism for approvals. > > 2. Add openssl subclass for CryptoUtil > > 3. Extend generate_session_key() to return key in same call > > 4. Allow CLI to call python? (to be filed as separate ticket) > > > > Done in attached patches: > > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > > and extend to allow addition of trans_wrapped_session_key. > > 6. Add getActiveKey() to python client. > > 7. client_id -> client_key_id > > 8. constants in python API for key status > > 9. Add sanity checks to python client code > > 10. Move functions out of KRAClient.py and into key.py > > 11. from_dict() -> from)json() > > 12. Add methods to create nss certdb and import transport cert > > 13. All inputs/outputs from CryptoUtil are unencoded. > > 14. Fix usages in main function of SymKeyGenerationRequest > > 15. Fix bugs when retrieving invalid keyId. > > 16. Fix bugs when generating key with only clientID provided. > > > > To be done in next patch: > > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > > provide a more restricted convenience function generate_session_key() > > > > To be considered further: > > 1. rename session_key -> encryption_key/ wrapping_key? > > 2. revamp archival to not require client to generate PkiArchiveOptions > > object. > > 3. should retrieve functions return unwrapped key? > > > > Please review attached patches. > > > > Ade > > Patch #199: > > 1. The setup_database() throws a ValueError if the database already exists. > > raise exceptions.ValueError( > "Directory already exists and over_write is false") > > I'm not sure it's an appropriate exception: > http://docs.python.org/2/library/exceptions.html#exceptions.ValueError. > We probably could just throw a generic Exception. > > 2. The error message probably should just say "Directory already > exists". The end user should not see a variable name in the error > message. If the program ends with this error the user would know that an > existing database causes a conflict, so either they will remove it or > use a different path or overwrite it with a flag. For this db exists already? Is this really the end of the world? Could we just go ahead and open it for them and move on? For instance nss now has the notion of a completely common db where one could conceivably just add to it. > > 3. Since we're storing password, in NamedTemporaryFile() we probably > should specify some params to use user's temp dir instead of global temp > dir, and delete the temp file after closing. See: > http://docs.python.org/2/library/tempfile.html. > > 4. Minor thing. The data param in symmetric_unwrap() doc is followed by > a colon, which is inconsistent with the other params in that doc. > > :param data: Data to be unwrapped > > Is there a standard way of documenting params? > > 5. The "!=" operator could be replaced with "is not". > > if transport_cert_nick is not None: > > 6. I think ideally client shouldn't be required to encode/decode the > trans_wrapped_session_key, wrappedPrivateData, nonceData, > transport_cert, etc. The base64 encoding should only be part of > marshalling/unmarshalling, hidden from the client. Thoughts? > > 7. Can these 3 invocations be combined: > > cryptoutil.NSSCryptoUtil.setup_database( > certdb_dir, certdb_password, over_write=True) > crypto = cryptoutil.NSSCryptoUtil(certdb_dir, certdb_password) > crypto.initialize_db() > > into this? I agree with this, if it's feasible. This way they don't have to worry about initializing anything, they just put in the params to identify the db. > > crypto = cryptoutil.NSSCryptoUtil( > certdb_dir, certdb_password, over_write=True) > > Just a question, is it possible to use 2 different NSS databases at the > same time? > > -- > Endi S. Dewata > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From jmagne at redhat.com Mon Feb 24 22:33:41 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Feb 2014 17:33:41 -0500 (EST) Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530BB260.4050900@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB260.4050900@redhat.com> Message-ID: <439691465.16209578.1393281221446.JavaMail.zimbra@redhat.com> ACK #200, comment below: ----- Original Message ----- > From: "Endi Sukma Dewata" > To: alee at redhat.com, pki-devel at redhat.com > Sent: Monday, February 24, 2014 12:58:08 PM > Subject: Re: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > On 2/21/2014 11:52 PM, Ade Lee wrote: > > Endi, Jack and I met to discuss various improvements to the > > Key/KeyResource client/server parts. Some of these are addressed in the > > attached patches. Some will be handled in separate tickets. > > > > Separate Tickets to be filed: > > 1. Add nonce mechanism for approvals. > > 2. Add openssl subclass for CryptoUtil > > 3. Extend generate_session_key() to return key in same call > > 4. Allow CLI to call python? (to be filed as separate ticket) > > > > Done in attached patches: > > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > > and extend to allow addition of trans_wrapped_session_key. > > 6. Add getActiveKey() to python client. > > 7. client_id -> client_key_id > > 8. constants in python API for key status > > 9. Add sanity checks to python client code > > 10. Move functions out of KRAClient.py and into key.py > > 11. from_dict() -> from)json() > > 12. Add methods to create nss certdb and import transport cert > > 13. All inputs/outputs from CryptoUtil are unencoded. > > 14. Fix usages in main function of SymKeyGenerationRequest > > 15. Fix bugs when retrieving invalid keyId. > > 16. Fix bugs when generating key with only clientID provided. > > > > To be done in next patch: > > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > > provide a more restricted convenience function generate_session_key() > > > > To be considered further: > > 1. rename session_key -> encryption_key/ wrapping_key? > > 2. revamp archival to not require client to generate PkiArchiveOptions > > object. > > 3. should retrieve functions return unwrapped key? > > > > Please review attached patches. > > > > Ade > > ACK for patch #200. Just one comment, get_key_info() throws > KeyNotFoundException and get_active_key_info() throws > ResourceNotFoundException. I think they should be consistent. Also > consider removing the resource-specific *NotFoundExceptions. But do the resource specific exceptions reveal more info as to what has not been found. Will the generic one be able to convey that info? Just a question. > > -- > Endi S. Dewata > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From jmagne at redhat.com Mon Feb 24 22:47:38 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Feb 2014 17:47:38 -0500 (EST) Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530BB939.5020509@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB939.5020509@redhat.com> Message-ID: <149479911.16266541.1393282058386.JavaMail.zimbra@redhat.com> ACK 201, comments below: ----- Original Message ----- From: "Endi Sukma Dewata" To: alee at redhat.com, pki-devel at redhat.com Sent: Monday, February 24, 2014 1:27:21 PM Subject: Re: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade ACK for patch #201. Some comments: 1. Are we going to change the attribute name in the LDAP database? If so do we need to upgrade the existing database? I can see a case for leaving this the same. The user won't have big use to look at the ldap. 2. The "client" options in the CLIs probably should be renamed to "client-key". 3. In drmtest.py the label should be changed to "Client Key ID: ". print "Client ID: " + str(key_info.clientKeyID) 4. Is this supposed to be removed? #client_key_id = "Vek #1" + time.strftime('%X %x %Z') client_key_id = "abcxyz" 5. Existing issue, the toString() is redundant. clientKeyId = "UUID: 123-45-6789 VEK " + Calendar.getInstance().getTime().toString(); On the second thought, what do you think about using "key label" instead of "client key ID"? So Key ID would remain the unique identifier for the key, and the Key Label would be an identifier but it's not unique. No need to redo the whole patch, just search & replace the patch. I can help with this. I think alee has done enough. The new name sounds fine to me. :) I don't think having ID in the name automatically implies that the uniqueness on the key itself. It's more for the client to identify a set of keys with one being the active one. -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Mon Feb 24 23:35:10 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Feb 2014 18:35:10 -0500 (EST) Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.com > Sent: Friday, February 21, 2014 9:52:18 PM > Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Patch #201 Looks like simple moving functionality from one class to another.... ACK Just one caveat. We now appear to have a "keys" property of the client to make calls having to do with keys such as: kraclient.keys.list_keys I wonder if some of the methods of "KeyClient" now have a redundant portion of "keys" in the method names. Now that we know we are dealing with keys, perhaps some adjustment could be made there. For instance list_keys could become list. From jmagne at redhat.com Mon Feb 24 23:36:17 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Feb 2014 18:36:17 -0500 (EST) Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> Message-ID: <873993721.16281664.1393284977599.JavaMail.zimbra@redhat.com> Sorry, This is for patch #202. ----- Original Message ----- From: "John Magne" To: alee at redhat.com Cc: pki-devel at redhat.com Sent: Monday, February 24, 2014 3:35:10 PM Subject: Re: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.com > Sent: Friday, February 21, 2014 9:52:18 PM > Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Patch #201 Looks like simple moving functionality from one class to another.... ACK Just one caveat. We now appear to have a "keys" property of the client to make calls having to do with keys such as: kraclient.keys.list_keys I wonder if some of the methods of "KeyClient" now have a redundant portion of "keys" in the method names. Now that we know we are dealing with keys, perhaps some adjustment could be made there. For instance list_keys could become list. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Feb 25 17:20:19 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 25 Feb 2014 12:20:19 -0500 Subject: [Pki-devel] [PATCH] 204, 205 - Additional changes to Key, KeyRequests Message-ID: <1393348819.16432.3.camel@aleeredhat.laptop> Two patches attached which do as follows: Patch 205: Add ability to archive without sending pkiArchiveOptions object. With this patch, you can now either send a pkiArchiveOptions object or the exploded parameters. This reduces the processing required on the client side. Patch 204: Make generate_symmetric_key more generic. Added a method generate_session_key() which should be used when wrapping secrets for the drm. For now, this has to be a 168-bit 3DES symmetric key. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0205-Add-ability-to-archive-without-sending-pkiArchiveOpt.patch Type: text/x-patch Size: 41350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0204-Make-generate_symmetric_key-more-generic.patch Type: text/x-patch Size: 5731 bytes Desc: not available URL: From edewata at redhat.com Tue Feb 25 20:08:11 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 14:08:11 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1574717522.16150680.1393280410975.JavaMail.zimbra@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB151.3060401@redhat.com> <1574717522.16150680.1393280410975.JavaMail.zimbra@redhat.com> Message-ID: <530CF82B.2070808@redhat.com> On 2/24/2014 4:20 PM, John Magne wrote: > I'll piggy back on this ACK. Just a few comments interspersed. > >> Patch #199: >> >> 2. The error message probably should just say "Directory already >> exists". The end user should not see a variable name in the error >> message. If the program ends with this error the user would know that an >> existing database causes a conflict, so either they will remove it or >> use a different path or overwrite it with a flag. > > For this db exists already? Is this really the end of the world? > Could we just go ahead and open it for them and move on? For instance > nss now has the notion of a completely common db where one could > conceivably just add to it. Not sure how up-to-date this page is, but here's what it says: https://wiki.mozilla.org/NSS_Library_Init "We intended to go to a single user/machine configuration for most applications and libraries, ... One problem with this approach is that not all NSS applications run on systems which will have a 'system configured' NSS. In addition, there are still cases where the user may want to keep multiple different configurations for testing ..." I think there would be cases where the client wants to use a separate database and make sure it's not overwriting an existing one. >> 7. Can these 3 invocations be combined: >> >> cryptoutil.NSSCryptoUtil.setup_database( >> certdb_dir, certdb_password, over_write=True) >> crypto = cryptoutil.NSSCryptoUtil(certdb_dir, certdb_password) >> crypto.initialize_db() >> >> into this? > > I agree with this, if it's feasible. This way they don't have to worry about > initializing anything, they just put in the params to identify the db. As discussed with Ade, it might not be possible now since importing the transport cert is done using certutil instead of python-nss. Since the nss database can't be shared among multiple processes, the import has to be done first using certutil, then python-nss can intialize the database after that. Ideally the import has to be done with python-nss as well, but we don't know if the functionality is exposed in python-nss. -- Endi S. Dewata From edewata at redhat.com Tue Feb 25 20:11:54 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 14:11:54 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <439691465.16209578.1393281221446.JavaMail.zimbra@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB260.4050900@redhat.com> <439691465.16209578.1393281221446.JavaMail.zimbra@redhat.com> Message-ID: <530CF90A.2020901@redhat.com> On 2/24/2014 4:33 PM, John Magne wrote: > > ACK #200, comment below: > >> ACK for patch #200. Just one comment, get_key_info() throws >> KeyNotFoundException and get_active_key_info() throws >> ResourceNotFoundException. I think they should be consistent. Also >> consider removing the resource-specific *NotFoundExceptions. > > But do the resource specific exceptions reveal more info as to what has not been found. > Will the generic one be able to convey that info? Just a question. So far the resource-specific exceptions only contain the resource ID and the client already knows that since it's the one initiating the operation. A generic ResourceNotFoundException will still contain the resource ID as part of the error message. -- Endi S. Dewata From edewata at redhat.com Tue Feb 25 20:16:00 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 14:16:00 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <149479911.16266541.1393282058386.JavaMail.zimbra@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB939.5020509@redhat.com> <149479911.16266541.1393282058386.JavaMail.zimbra@redhat.com> Message-ID: <530CFA00.4030502@redhat.com> On 2/24/2014 4:47 PM, John Magne wrote: > ACK 201, comments below: > > ACK for patch #201. Some comments: > > 1. Are we going to change the attribute name in the LDAP database? If so > do we need to upgrade the existing database? > > I can see a case for leaving this the same. The user won't have big use > to look at the ldap. Yeah, we don't have to upgrade the database now. But in the long term it would be nice to have an attribute name that matches the client API. > On the second thought, what do you think about using "key label" instead > of "client key ID"? So Key ID would remain the unique identifier for the > key, and the Key Label would be an identifier but it's not unique. No > need to redo the whole patch, just search & replace the patch. I can > help with this. > I think alee has done enough. The new name sounds fine to me. :) I don't think > having ID in the name automatically implies that the uniqueness on the key itself. > It's more for the client to identify a set of keys with one being the active one. Either name is fine. I just thought "label" is simpler. If we decided to use label I can help make the changes, no extra work for alee :) -- Endi S. Dewata From edewata at redhat.com Tue Feb 25 20:24:13 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 14:24:13 -0600 Subject: [Pki-devel] [PATCH] 414 Direct deployment for TPS. Message-ID: <530CFBED.60605@redhat.com> The deployment tool has been modified to deploy TPS directly from the share folder. This way the TPS UI can be upgraded automatically with RPM upgrade without having to write upgrade scripts. For this to work, the TPS web application files cannot contain any customization. So, the cfgPath parameter has been removed from web.xml, and the CMSStartServlet has been modified such that if the parameter is missing it would generate a default path matching the original value in web.xml. Also, the velocity.properties has been modified to use a fixed value for the file.resource.loader.path parameter pointing to the share folder. In the future other subsystems may be modified to use the same deployment mechanism. Ticket #748, #752, #499 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0414-Direct-deployment-for-TPS.patch Type: text/x-patch Size: 18876 bytes Desc: not available URL: From alee at redhat.com Tue Feb 25 21:05:39 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 25 Feb 2014 16:05:39 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> Message-ID: <1393362339.16432.10.camel@aleeredhat.laptop> On Mon, 2014-02-24 at 18:35 -0500, John Magne wrote: > > > > ----- Original Message ----- > > From: "Ade Lee" > > To: pki-devel at redhat.com > > Sent: Friday, February 21, 2014 9:52:18 PM > > Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > > > Endi, Jack and I met to discuss various improvements to the > > Key/KeyResource client/server parts. Some of these are addressed in the > > attached patches. Some will be handled in separate tickets. > > > > Separate Tickets to be filed: > > 1. Add nonce mechanism for approvals. > > 2. Add openssl subclass for CryptoUtil > > 3. Extend generate_session_key() to return key in same call > > 4. Allow CLI to call python? (to be filed as separate ticket) > > > > Done in attached patches: > > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > > and extend to allow addition of trans_wrapped_session_key. > > 6. Add getActiveKey() to python client. > > 7. client_id -> client_key_id > > 8. constants in python API for key status > > 9. Add sanity checks to python client code > > 10. Move functions out of KRAClient.py and into key.py > > 11. from_dict() -> from)json() > > 12. Add methods to create nss certdb and import transport cert > > 13. All inputs/outputs from CryptoUtil are unencoded. > > 14. Fix usages in main function of SymKeyGenerationRequest > > 15. Fix bugs when retrieving invalid keyId. > > 16. Fix bugs when generating key with only clientID provided. > > > > To be done in next patch: > > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > > provide a more restricted convenience function generate_session_key() > > > > To be considered further: > > 1. rename session_key -> encryption_key/ wrapping_key? > > 2. revamp archival to not require client to generate PkiArchiveOptions > > object. > > 3. should retrieve functions return unwrapped key? > > > > Please review attached patches. > > > > Ade > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > Patch #201 > > Looks like simple moving functionality from one class to another.... > > ACK > > Just one caveat. > > We now appear to have a "keys" property of the client to make calls having to do with keys such as: > > kraclient.keys.list_keys > > I wonder if some of the methods of "KeyClient" now have a redundant portion of "keys" in the method names. > Now that we know we are dealing with keys, perhaps some adjustment could be made there. For instance > list_keys could become list. > > Not really, KeyClient contain methods to list and perform operations on Keys and KeyRequests. You need the extra bits to see what you are listing. Note that in the latest code, I do something like this: keyclient = kraclient.keys keyclient.list_keys() etc. > > From edewata at redhat.com Tue Feb 25 22:48:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 16:48:21 -0600 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393048338.14191.25.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> Message-ID: <530D1DB5.30002@redhat.com> On 2/21/2014 11:52 PM, Ade Lee wrote: > Endi, Jack and I met to discuss various improvements to the > Key/KeyResource client/server parts. Some of these are addressed in the > attached patches. Some will be handled in separate tickets. > > Separate Tickets to be filed: > 1. Add nonce mechanism for approvals. > 2. Add openssl subclass for CryptoUtil > 3. Extend generate_session_key() to return key in same call > 4. Allow CLI to call python? (to be filed as separate ticket) > > Done in attached patches: > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > and extend to allow addition of trans_wrapped_session_key. > 6. Add getActiveKey() to python client. > 7. client_id -> client_key_id > 8. constants in python API for key status > 9. Add sanity checks to python client code > 10. Move functions out of KRAClient.py and into key.py > 11. from_dict() -> from)json() > 12. Add methods to create nss certdb and import transport cert > 13. All inputs/outputs from CryptoUtil are unencoded. > 14. Fix usages in main function of SymKeyGenerationRequest > 15. Fix bugs when retrieving invalid keyId. > 16. Fix bugs when generating key with only clientID provided. > > To be done in next patch: > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > provide a more restricted convenience function generate_session_key() > > To be considered further: > 1. rename session_key -> encryption_key/ wrapping_key? > 2. revamp archival to not require client to generate PkiArchiveOptions > object. > 3. should retrieve functions return unwrapped key? > > Please review attached patches. > > Ade Some comments for #203: 1. It looks like TypeError is more common to indicate missing argument rather than ValueError: http://stackoverflow.com/questions/8297526/proper-exception-to-raise-if-none-encountered-as-argument 2. It might be better for end users to see a descriptive error message rather than variable name, for example: raise ValueError("Request ID must be specified") 3. I don't think we should mask invalid data. If there's an error the exception will provide information to troubleshoot the problem. public Integer getKeySize() { try { return new Integer(attributes.get(KEY_SIZE)); } catch (NumberFormatException e) { return null; } } -- Endi S. Dewata From edewata at redhat.com Tue Feb 25 23:40:46 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Feb 2014 17:40:46 -0600 Subject: [Pki-devel] [PATCH] 204, 205 - Additional changes to Key, KeyRequests In-Reply-To: <1393348819.16432.3.camel@aleeredhat.laptop> References: <1393348819.16432.3.camel@aleeredhat.laptop> Message-ID: <530D29FE.5060509@redhat.com> ACK for #204 and #205 with some comments below: On 2/25/2014 11:20 AM, Ade Lee wrote: > Patch 205: > Add ability to archive without sending pkiArchiveOptions object. > > With this patch, you can now either send a pkiArchiveOptions object > or the exploded parameters. This reduces the processing required on > the client side. In KeyClient.archive_key() the doc says: 3. wrapped_private_data which consists of a PKIArchiveOptions structure. Is it supposed to be pki_archive_options? Another question, can "TransWrappedSessionKey" be replaced with "WrappedSessionKey"? I suppose in this case the session key can only be wrapped with the transport key, so adding "Trans" is redundant. Existing issue, ArchiveOptions.toArchiveOptions() cannot return null so the null checking is redundant. > Patch 204: > > Make generate_symmetric_key more generic. > > Added a method generate_session_key() which should be used when > wrapping secrets for the drm. For now, this has to be a 168-bit > 3DES symmetric key. The method seems to be too DRM-specific to be added into CryptoUtil. Should this be added to KRAClient then it will call CryptoUtil's generate_symmetric_key() with the appropriate parameters? -- Endi S. Dewata From mharmsen at redhat.com Wed Feb 26 01:31:50 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 25 Feb 2014 17:31:50 -0800 Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] Message-ID: <530D4406.6010709@redhat.com> This patch causes the 'sslserver' certificate for a CA clone to be signed by its associated master CA during configuration, and resolves the following bug: * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca This was necessary to avoid any changes which may have been made to the X500Name directory string encoding order (i. e. - creating a Cloned CA on Fedora 20 from a Master CA on Fedora 19). The code was tested (applying the CAVEAT below) via end-to-end 'pkispawn' installation and batch-based configuration; it has not yet been tested with GUI-based configuration. *CAVEAT:* During the preparation of this patch it was discovered that an end-to-end test of functionality cannot be accomplished due to the 389 TRAC Ticket #47721 - Schema Replication Issue which prevents the '99user.ldif' file from being properly replicated from the Master CA to the Cloned CA. However, I verified that this code does work by shutting down DS on the cloned CA machine, manually replacing '/etc/dirsrv/slapd-/schema/99user.ldif' with '/etc/dirsrv/slapd-/schema/99user.ldif, restarting DS and the Cloned CA, and successfully performing a test enrollment. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20140225-CA-clone-sslserver-cert.patch Type: text/x-patch Size: 4854 bytes Desc: not available URL: From mharmsen at redhat.com Wed Feb 26 01:33:57 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 25 Feb 2014 17:33:57 -0800 Subject: [Pki-devel] Fwd: [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] In-Reply-To: <530D4406.6010709@redhat.com> References: <530D4406.6010709@redhat.com> Message-ID: <530D4485.1080500@redhat.com> Note: This patch is intended for Dogtag 10.1. Once approved, it will also need to be applied to the 'master' branch. -------- Original Message -------- Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] Date: Tue, 25 Feb 2014 17:31:50 -0800 From: Matthew Harmsen To: pki-devel This patch causes the 'sslserver' certificate for a CA clone to be signed by its associated master CA during configuration, and resolves the following bug: * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca This was necessary to avoid any changes which may have been made to the X500Name directory string encoding order (i. e. - creating a Cloned CA on Fedora 20 from a Master CA on Fedora 19). The code was tested (applying the CAVEAT below) via end-to-end 'pkispawn' installation and batch-based configuration; it has not yet been tested with GUI-based configuration. *CAVEAT:* During the preparation of this patch it was discovered that an end-to-end test of functionality cannot be accomplished due to the 389 TRAC Ticket #47721 - Schema Replication Issue which prevents the '99user.ldif' file from being properly replicated from the Master CA to the Cloned CA. However, I verified that this code does work by shutting down DS on the cloned CA machine, manually replacing '/etc/dirsrv/slapd-/schema/99user.ldif' with '/etc/dirsrv/slapd-/schema/99user.ldif, restarting DS and the Cloned CA, and successfully performing a test enrollment. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20140225-CA-clone-sslserver-cert.patch Type: text/x-patch Size: 4854 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Feb 26 15:07:18 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:07:18 -0500 Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] In-Reply-To: <530D4406.6010709@redhat.com> References: <530D4406.6010709@redhat.com> Message-ID: <1393427238.26529.1.camel@aleeredhat.laptop> Matt, Have you done a cloning test without the above patch? You can do so by implementing the workaround. In this case, does the DS replication issue still arise? Ade On Tue, 2014-02-25 at 17:31 -0800, Matthew Harmsen wrote: > This patch causes the 'sslserver' certificate for a CA clone to be > signed by its associated master CA during configuration, and resolves > the following bug: > * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after > installation of ipa replica with ca > This was necessary to avoid any changes which may have been made to > the X500Name directory string encoding order (i. e. - creating a > Cloned CA on Fedora 20 from a Master CA on Fedora 19). > > The code was tested (applying the CAVEAT below) via end-to-end > 'pkispawn' installation and batch-based configuration; it has not yet > been tested with GUI-based configuration. > > CAVEAT: > During the preparation of this patch it was discovered that an > end-to-end test of functionality cannot be accomplished due to > the 389 TRAC Ticket #47721 - Schema Replication Issue which > prevents the '99user.ldif' file from being properly replicated > from the Master CA to the Cloned CA. However, I verified that > this code does work by shutting down DS on the cloned CA > machine, manually replacing > '/etc/dirsrv/slapd-/schema/99user.ldif' with > '/etc/dirsrv/slapd-/schema/99user.ldif, restarting DS > and the Cloned CA, and successfully performing a test > enrollment. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Feb 26 15:08:54 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:08:54 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530CF82B.2070808@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB151.3060401@redhat.com> <1574717522.16150680.1393280410975.JavaMail.zimbra@redhat.com> <530CF82B.2070808@redhat.com> Message-ID: <1393427334.26529.2.camel@aleeredhat.laptop> Issues addressed and pushed to master. On Tue, 2014-02-25 at 14:08 -0600, Endi Sukma Dewata wrote: > On 2/24/2014 4:20 PM, John Magne wrote: > > I'll piggy back on this ACK. Just a few comments interspersed. > > > >> Patch #199: > >> > >> 2. The error message probably should just say "Directory already > >> exists". The end user should not see a variable name in the error > >> message. If the program ends with this error the user would know that an > >> existing database causes a conflict, so either they will remove it or > >> use a different path or overwrite it with a flag. > > > > For this db exists already? Is this really the end of the world? > > Could we just go ahead and open it for them and move on? For instance > > nss now has the notion of a completely common db where one could > > conceivably just add to it. > > Not sure how up-to-date this page is, but here's what it says: > https://wiki.mozilla.org/NSS_Library_Init > > "We intended to go to a single user/machine configuration for most > applications and libraries, ... One problem with this approach is that > not all NSS applications run on systems which will have a 'system > configured' NSS. In addition, there are still cases where the user may > want to keep multiple different configurations for testing ..." > > I think there would be cases where the client wants to use a separate > database and make sure it's not overwriting an existing one. > > >> 7. Can these 3 invocations be combined: > >> > >> cryptoutil.NSSCryptoUtil.setup_database( > >> certdb_dir, certdb_password, over_write=True) > >> crypto = cryptoutil.NSSCryptoUtil(certdb_dir, certdb_password) > >> crypto.initialize_db() > >> > >> into this? > > > > I agree with this, if it's feasible. This way they don't have to worry about > > initializing anything, they just put in the params to identify the db. > > As discussed with Ade, it might not be possible now since importing the > transport cert is done using certutil instead of python-nss. Since the > nss database can't be shared among multiple processes, the import has to > be done first using certutil, then python-nss can intialize the database > after that. > > Ideally the import has to be done with python-nss as well, but we don't > know if the functionality is exposed in python-nss. > From alee at redhat.com Wed Feb 26 15:09:29 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:09:29 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530CF90A.2020901@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB260.4050900@redhat.com> <439691465.16209578.1393281221446.JavaMail.zimbra@redhat.com> <530CF90A.2020901@redhat.com> Message-ID: <1393427369.26529.3.camel@aleeredhat.laptop> Pushed to master. Removing resource specific exceptions will be relegated to another patch. On Tue, 2014-02-25 at 14:11 -0600, Endi Sukma Dewata wrote: > On 2/24/2014 4:33 PM, John Magne wrote: > > > > ACK #200, comment below: > > > >> ACK for patch #200. Just one comment, get_key_info() throws > >> KeyNotFoundException and get_active_key_info() throws > >> ResourceNotFoundException. I think they should be consistent. Also > >> consider removing the resource-specific *NotFoundExceptions. > > > > But do the resource specific exceptions reveal more info as to what has not been found. > > Will the generic one be able to convey that info? Just a question. > > So far the resource-specific exceptions only contain the resource ID and > the client already knows that since it's the one initiating the > operation. A generic ResourceNotFoundException will still contain the > resource ID as part of the error message. > From alee at redhat.com Wed Feb 26 15:10:09 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:10:09 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <530CFA00.4030502@redhat.com> References: <1393048338.14191.25.camel@aleeredhat.laptop> <530BB939.5020509@redhat.com> <149479911.16266541.1393282058386.JavaMail.zimbra@redhat.com> <530CFA00.4030502@redhat.com> Message-ID: <1393427409.26529.4.camel@aleeredhat.laptop> Sticking with client_key_id. Pushed to master. On Tue, 2014-02-25 at 14:16 -0600, Endi Sukma Dewata wrote: > On 2/24/2014 4:47 PM, John Magne wrote: > > ACK 201, comments below: > > > > ACK for patch #201. Some comments: > > > > 1. Are we going to change the attribute name in the LDAP database? If so > > do we need to upgrade the existing database? > > > > I can see a case for leaving this the same. The user won't have big use > > to look at the ldap. > > Yeah, we don't have to upgrade the database now. But in the long term it > would be nice to have an attribute name that matches the client API. > > > On the second thought, what do you think about using "key label" instead > > of "client key ID"? So Key ID would remain the unique identifier for the > > key, and the Key Label would be an identifier but it's not unique. No > > need to redo the whole patch, just search & replace the patch. I can > > help with this. > > > I think alee has done enough. The new name sounds fine to me. :) I don't think > > having ID in the name automatically implies that the uniqueness on the key itself. > > It's more for the client to identify a set of keys with one being the active one. > > Either name is fine. I just thought "label" is simpler. If we decided to > use label I can help make the changes, no extra work for alee :) > From alee at redhat.com Wed Feb 26 15:10:34 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:10:34 -0500 Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. In-Reply-To: <1393362339.16432.10.camel@aleeredhat.laptop> References: <1393048338.14191.25.camel@aleeredhat.laptop> <1248458130.16281375.1393284910356.JavaMail.zimbra@redhat.com> <1393362339.16432.10.camel@aleeredhat.laptop> Message-ID: <1393427434.26529.5.camel@aleeredhat.laptop> Pushed to master. On Tue, 2014-02-25 at 16:05 -0500, Ade Lee wrote: > On Mon, 2014-02-24 at 18:35 -0500, John Magne wrote: > > > > > > > > ----- Original Message ----- > > > From: "Ade Lee" > > > To: pki-devel at redhat.com > > > Sent: Friday, February 21, 2014 9:52:18 PM > > > Subject: [Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code. > > > > > > Endi, Jack and I met to discuss various improvements to the > > > Key/KeyResource client/server parts. Some of these are addressed in the > > > attached patches. Some will be handled in separate tickets. > > > > > > Separate Tickets to be filed: > > > 1. Add nonce mechanism for approvals. > > > 2. Add openssl subclass for CryptoUtil > > > 3. Extend generate_session_key() to return key in same call > > > 4. Allow CLI to call python? (to be filed as separate ticket) > > > > > > Done in attached patches: > > > 5. Change kraclient.generate_sym_key -> kraclient.generate_symmetric_key > > > and extend to allow addition of trans_wrapped_session_key. > > > 6. Add getActiveKey() to python client. > > > 7. client_id -> client_key_id > > > 8. constants in python API for key status > > > 9. Add sanity checks to python client code > > > 10. Move functions out of KRAClient.py and into key.py > > > 11. from_dict() -> from)json() > > > 12. Add methods to create nss certdb and import transport cert > > > 13. All inputs/outputs from CryptoUtil are unencoded. > > > 14. Fix usages in main function of SymKeyGenerationRequest > > > 15. Fix bugs when retrieving invalid keyId. > > > 16. Fix bugs when generating key with only clientID provided. > > > > > > To be done in next patch: > > > 17. Rewrite cryptoutil.generate_symmetric_key() to be more generic and > > > provide a more restricted convenience function generate_session_key() > > > > > > To be considered further: > > > 1. rename session_key -> encryption_key/ wrapping_key? > > > 2. revamp archival to not require client to generate PkiArchiveOptions > > > object. > > > 3. should retrieve functions return unwrapped key? > > > > > > Please review attached patches. > > > > > > Ade > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > Patch #201 > > > > Looks like simple moving functionality from one class to another.... > > > > ACK > > > > Just one caveat. > > > > We now appear to have a "keys" property of the client to make calls having to do with keys such as: > > > > kraclient.keys.list_keys > > > > I wonder if some of the methods of "KeyClient" now have a redundant portion of "keys" in the method names. > > Now that we know we are dealing with keys, perhaps some adjustment could be made there. For instance > > list_keys could become list. > > > > > Not really, KeyClient contain methods to list and perform operations on > Keys and KeyRequests. You need the extra bits to see what you are > listing. > > Note that in the latest code, I do something like this: > > keyclient = kraclient.keys > keyclient.list_keys() > > etc. > > > > > > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Feb 26 15:12:15 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Feb 2014 10:12:15 -0500 Subject: [Pki-devel] [PATCH] 204, 205 - Additional changes to Key, KeyRequests In-Reply-To: <530D29FE.5060509@redhat.com> References: <1393348819.16432.3.camel@aleeredhat.laptop> <530D29FE.5060509@redhat.com> Message-ID: <1393427535.26529.8.camel@aleeredhat.laptop> Issues addressed - pushed to master. On Tue, 2014-02-25 at 17:40 -0600, Endi Sukma Dewata wrote: > ACK for #204 and #205 with some comments below: > > On 2/25/2014 11:20 AM, Ade Lee wrote: > > Patch 205: > > Add ability to archive without sending pkiArchiveOptions object. > > > > With this patch, you can now either send a pkiArchiveOptions object > > or the exploded parameters. This reduces the processing required on > > the client side. > > In KeyClient.archive_key() the doc says: > > 3. wrapped_private_data which consists of a > PKIArchiveOptions structure. > > Is it supposed to be pki_archive_options? > > Another question, can "TransWrappedSessionKey" be replaced with > "WrappedSessionKey"? I suppose in this case the session key can only be > wrapped with the transport key, so adding "Trans" is redundant. > > Existing issue, ArchiveOptions.toArchiveOptions() cannot return null so > the null checking is redundant. > > > Patch 204: > > > > Make generate_symmetric_key more generic. > > > > Added a method generate_session_key() which should be used when > > wrapping secrets for the drm. For now, this has to be a 168-bit > > 3DES symmetric key. > > The method seems to be too DRM-specific to be added into CryptoUtil. > Should this be added to KRAClient then it will call CryptoUtil's > generate_symmetric_key() with the appropriate parameters? > We can discuss this one, but its not straightforward. From edewata at redhat.com Wed Feb 26 23:22:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 26 Feb 2014 17:22:25 -0600 Subject: [Pki-devel] [PATCH] 415 Fixed CLI exceptions. Message-ID: <530E7731.4060305@redhat.com> Previously if the CLI requires SSL but the security database doesn't exist it would throw an IOException. Now it has been replaced with an Error. The exception handler also has been modified to generate better error messages. Ticket #821 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0415-Fixed-CLI-exceptions.patch Type: text/x-patch Size: 2856 bytes Desc: not available URL: From jmagne at redhat.com Thu Feb 27 03:22:05 2014 From: jmagne at redhat.com (John Magne) Date: Wed, 26 Feb 2014 22:22:05 -0500 (EST) Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <528941377.19835807.1393471236494.JavaMail.zimbra@redhat.com> Message-ID: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> First cut at Java TPS Buffer class and APDU classes. 1. Also simple framework for working with APDU commands. 2. Implemented a few APDU commands in TPS_Processor class. 3. Can now attempt a format operation with TPS client. The code can perform a few apdu's talking to the client and return a success "EndOp" apdu to terminate the conversation. 4. APDU are being encoded/decoded properly to appease tpsclient. More info. 1. Patch is large but most of it consists of many similar apdu and msg classes. 2. APDU and msg classes are now bare bones and may need more work. Will address when class is needed. 3. A test tpsclient script call it (format.tst) to test this out is as follows: op=var_set name=ra_host value=localhost op=var_set name=ra_port value=8080 op=var_set name=ra_uri value=/tps/tps op=token_set cuid=40906145C76224192D2B msn=0120304 app_ver=6FBBC105 key_info=0101 major_ver=1 minor_ver=1 op=token_set auth_key=404142434445464748494a4b4c4d4e4f op=token_set mac_key=404142434445464748494a4b4c4d4e4f op=token_set kek_key=404142434445464748494a4b4c4d4e4f op=ra_format uid=jmagne pwd=redhat new_pin=rehat num_threads=1 op=exit 4: Execute as follows: tpsclient < format.tst -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch Type: text/x-patch Size: 175837 bytes Desc: not available URL: From edewata at redhat.com Thu Feb 27 15:41:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Feb 2014 09:41:02 -0600 Subject: [Pki-devel] [PATCH] 412 Removed @Consumes and @Provides. In-Reply-To: <5306822D.8070105@redhat.com> References: <530641C2.2070709@redhat.com> <5306822D.8070105@redhat.com> Message-ID: <530F5C8E.9040005@redhat.com> On 2/20/2014 4:31 PM, Endi Sukma Dewata wrote: > On 2/20/2014 11:56 AM, Endi Sukma Dewata wrote: >> The @Consumes and @Provides annotations have been removed from all >> methods (except from methods that consume forms) to allow client >> to use the default consumes and provides specified in the proxy. >> >> Ticket #554 > > Added missing changes. Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0412-2-Removed-Consumes-and-Provides.patch Type: text/x-patch Size: 58006 bytes Desc: not available URL: From alee at redhat.com Thu Feb 27 16:02:18 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Feb 2014 11:02:18 -0500 Subject: [Pki-devel] [PATCH] 410 Upgraded RESTEasy client library. In-Reply-To: <530640F9.3080606@redhat.com> References: <530640F9.3080606@redhat.com> Message-ID: <1393516938.4040.5.camel@localhost.localdomain> 1. The log message "Getting old cookie" in ConfigurationUtils.java is a little deceptive, because that function is only called in a failure case. We should probably consider how to simply this function. Some of the failure cases here may no longer apply. 2. In GetCookie.java, its not necessary to log the exception in processImpl() and also log it in process(). 3. Whats the effect of setting @XmlAccessorType(XmlAccessType.NONE) ? Ade On Thu, 2014-02-20 at 11:52 -0600, Endi Sukma Dewata wrote: > The Dogtag client library has been modified to use RESTEasy 3.0 client > library. A new upgrade script has been added to update existing servers. > > The JAXB annotation in ResourceMessage has been modified to require > explicit property mapping. > > Ticket #554 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Feb 27 16:04:28 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Feb 2014 11:04:28 -0500 Subject: [Pki-devel] [PATCH] 410 Upgraded RESTEasy client library. In-Reply-To: <1393516938.4040.5.camel@localhost.localdomain> References: <530640F9.3080606@redhat.com> <1393516938.4040.5.camel@localhost.localdomain> Message-ID: <1393517068.4040.6.camel@localhost.localdomain> Also, in operations, why are we not updating the debian link too? On Thu, 2014-02-27 at 11:02 -0500, Ade Lee wrote: > 1. The log message "Getting old cookie" in ConfigurationUtils.java is a > little deceptive, because that function is only called in a failure > case. We should probably consider how to simply this function. Some of > the failure cases here may no longer apply. > > 2. In GetCookie.java, its not necessary to log the exception in > processImpl() and also log it in process(). > > 3. Whats the effect of setting @XmlAccessorType(XmlAccessType.NONE) ? > > Ade > On Thu, 2014-02-20 at 11:52 -0600, Endi Sukma Dewata wrote: > > The Dogtag client library has been modified to use RESTEasy 3.0 client > > library. A new upgrade script has been added to update existing servers. > > > > The JAXB annotation in ResourceMessage has been modified to require > > explicit property mapping. > > > > Ticket #554 > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Thu Feb 27 16:40:39 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Feb 2014 11:40:39 -0500 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <5306414C.8060007@redhat.com> References: <5306414C.8060007@redhat.com> Message-ID: <1393519239.4040.27.camel@localhost.localdomain> 1. Typo in MainCLI.java : Mesage format 2. There appears to be no code to enforce the input to be "json or xml". What if someone puts in "XML" or "Json" or "foo" in the CLI command line? 3. So, it looks like we have decided to remove all the Produces/Consumes and basically provide all servlets as XML and JSON by default. What that means though is that we are taking the logic of deciding which format to return from the framework code. I'm a little confused as to why this is needed. Doesn't the framework already do this work for us? What if the client requests a format like "application/atom-xml" - and nothing else. If we follow your code, we will end up returning the results in whatever format the request came in as. This seems wrong - we should reject the request with a code 406 (not acceptable). And more importantly - we should reject this prior to processing which is presumably what the framework would do - rather than post-processing when generating the response which is what your code does. Ade On Thu, 2014-02-20 at 11:54 -0600, Endi Sukma Dewata wrote: > A new CLI parameter has been added to specify the format of the HTTP > messages exchanged between the client and server. This is done by > setting the default consumes and produces when creating the proxy. > For this to work the @Consumes and @Produces annotations will be > removed in the subsequent patch. > > Ticket #554 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Feb 27 16:42:19 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Feb 2014 11:42:19 -0500 Subject: [Pki-devel] [PATCH] 412 Removed @Consumes and @Provides. In-Reply-To: <530F5C8E.9040005@redhat.com> References: <530641C2.2070709@redhat.com> <5306822D.8070105@redhat.com> <530F5C8E.9040005@redhat.com> Message-ID: <1393519339.4040.28.camel@localhost.localdomain> NACK - based on comment on patch 411. On Thu, 2014-02-27 at 09:41 -0600, Endi Sukma Dewata wrote: > On 2/20/2014 4:31 PM, Endi Sukma Dewata wrote: > > On 2/20/2014 11:56 AM, Endi Sukma Dewata wrote: > >> The @Consumes and @Provides annotations have been removed from all > >> methods (except from methods that consume forms) to allow client > >> to use the default consumes and provides specified in the proxy. > >> > >> Ticket #554 > > > > Added missing changes. > > Rebased. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Feb 27 18:50:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Feb 2014 12:50:51 -0600 Subject: [Pki-devel] [PATCH] 410 Upgraded RESTEasy client library. In-Reply-To: <1393517068.4040.6.camel@localhost.localdomain> References: <530640F9.3080606@redhat.com> <1393516938.4040.5.camel@localhost.localdomain> <1393517068.4040.6.camel@localhost.localdomain> Message-ID: <530F890B.8070805@redhat.com> ACKed on IRC. Pushed to master. On 2/27/2014 10:04 AM, Ade Lee wrote: > Also, in operations, why are we not updating the debian link too? Fixed. >> 1. The log message "Getting old cookie" in ConfigurationUtils.java is a >> little deceptive, because that function is only called in a failure >> case. We should probably consider how to simply this function. Some of >> the failure cases here may no longer apply. The message has been removed. As discussed over IRC, the simplification will be done another time. >> 2. In GetCookie.java, its not necessary to log the exception in >> processImpl() and also log it in process(). The ones that rethrow the exception have been removed. The ones that swallow the exception have been kept to make sure we see the exception in the debug log. >> 3. Whats the effect of setting @XmlAccessorType(XmlAccessType.NONE) ? As discussed, it means JAXB mapping has to be done explicitly, so it prevents unintended mapping of the setter/getter methods. -- Endi S. Dewata From edewata at redhat.com Thu Feb 27 19:56:33 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Feb 2014 13:56:33 -0600 Subject: [Pki-devel] [PATCH] 413 Reorganized REST service classes. In-Reply-To: <53081E61.1030604@redhat.com> References: <53081E61.1030604@redhat.com> Message-ID: <530F9871.2010708@redhat.com> On 2/21/2014 9:49 PM, Endi Sukma Dewata wrote: > The REST service classes have been moved into org.dogtagpki.server > namespace. A new upgrade script has been added to update existing > instances. > > Ticket #114 Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0413-1-Reorganized-REST-service-classes.patch Type: text/x-patch Size: 86573 bytes Desc: not available URL: From cfu at redhat.com Thu Feb 27 20:13:10 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 27 Feb 2014 12:13:10 -0800 Subject: [Pki-devel] [PATCH] 413 Reorganized REST service classes. In-Reply-To: <530F9871.2010708@redhat.com> References: <53081E61.1030604@redhat.com> <530F9871.2010708@redhat.com> Message-ID: <530F9C56.7040407@redhat.com> My review is on the tps-tomcat part on moving things under appropriate directories: config, rest, and dbs. ACK thanks, Christina On 02/27/2014 11:56 AM, Endi Sukma Dewata wrote: > On 2/21/2014 9:49 PM, Endi Sukma Dewata wrote: >> The REST service classes have been moved into org.dogtagpki.server >> namespace. A new upgrade script has been added to update existing >> instances. >> >> Ticket #114 > > Rebased. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Thu Feb 27 19:40:27 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 27 Feb 2014 11:40:27 -0800 Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> Message-ID: <530F94AB.7060301@redhat.com> First of all, this is a first cut so I am not going to be overly critical of little details as things will change and start to take form as we go on. My comments are on some overall things: * I see most everything are sticking to what we planned, that is, close to the old tps. That's good. it helps make things move faster. * Nothing you (Jack) need to do now, but it's a reminder for Endi per our agreement on irc, you are to move your stuff under the directories we agreed upon. Once Jack checks in his stuff, the tps directory is getting really messy, and your stuff have names that are misleading Anyway, great Job on the first cut TPS rewrite. My feeling is as long as it doesn't mess up anything ( not much additional Eclipse warnings unless absolutely necessary, etc.), it compiles and does what you claimed to do, its fine. Jack just gave me a quick demo too. ACK. Christina On 02/26/2014 07:22 PM, John Magne wrote: > First cut at Java TPS Buffer class and APDU classes. > > 1. Also simple framework for working with APDU commands. > 2. Implemented a few APDU commands in TPS_Processor class. > 3. Can now attempt a format operation with TPS client. > The code can perform a few apdu's talking to the client > and return a success "EndOp" apdu to terminate the conversation. > 4. APDU are being encoded/decoded properly to appease tpsclient. > > More info. > > 1. Patch is large but most of it consists of many similar apdu and msg classes. > 2. APDU and msg classes are now bare bones and may need more work. Will address when class is needed. > 3. A test tpsclient script call it (format.tst) to test this out is as follows: > > op=var_set name=ra_host value=localhost > op=var_set name=ra_port value=8080 > op=var_set name=ra_uri value=/tps/tps > op=token_set cuid=40906145C76224192D2B msn=0120304 app_ver=6FBBC105 key_info=0101 major_ver=1 minor_ver=1 > op=token_set auth_key=404142434445464748494a4b4c4d4e4f > op=token_set mac_key=404142434445464748494a4b4c4d4e4f > op=token_set kek_key=404142434445464748494a4b4c4d4e4f > op=ra_format uid=jmagne pwd=redhat new_pin=rehat num_threads=1 > op=exit > > 4: Execute as follows: > > tpsclient < format.tst > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Feb 28 04:04:45 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Feb 2014 23:04:45 -0500 Subject: [Pki-devel] [PATCH] 413 Reorganized REST service classes. In-Reply-To: <530F9871.2010708@redhat.com> References: <53081E61.1030604@redhat.com> <530F9871.2010708@redhat.com> Message-ID: <1393560285.14075.0.camel@aleeredhat.laptop> Looks good to me, and I see you got acks on irc from cfu and jmagne. ACK. On Thu, 2014-02-27 at 13:56 -0600, Endi Sukma Dewata wrote: > On 2/21/2014 9:49 PM, Endi Sukma Dewata wrote: > > The REST service classes have been moved into org.dogtagpki.server > > namespace. A new upgrade script has been added to update existing > > instances. > > > > Ticket #114 > > Rebased. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Feb 28 18:19:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Feb 2014 12:19:18 -0600 Subject: [Pki-devel] [PATCH] 413 Reorganized REST service classes. In-Reply-To: <1393560285.14075.0.camel@aleeredhat.laptop> References: <53081E61.1030604@redhat.com> <530F9871.2010708@redhat.com> <1393560285.14075.0.camel@aleeredhat.laptop> Message-ID: <5310D326.6080106@redhat.com> On 2/27/2014 10:04 PM, Ade Lee wrote: > Looks good to me, and I see you got acks on irc from cfu and jmagne. > > ACK. Thanks all for the ACKs. Pushed to master. -- Endi S. Dewata From alee at redhat.com Fri Feb 28 21:48:12 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 28 Feb 2014 16:48:12 -0500 Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140225] In-Reply-To: <1393427238.26529.1.camel@aleeredhat.laptop> References: <530D4406.6010709@redhat.com> <1393427238.26529.1.camel@aleeredhat.laptop> Message-ID: <1393624092.14075.73.camel@aleeredhat.laptop> Matt, The patch itself is relatively straightfoward and does roughly what I would have expected the patch to do. It is, however, somewhat confusing - in no small part because the code in this section is quite convoluted. and not easy to understand. 1. In the initial part of the patch, you retrieve and temporarily store one CS,cfg value, modify a few others and set some values for this particular cert object - but only if you are cloning a CA. I think its clearer to something like this: String selection = config.getString(...) String csType = config.getString(...) if csType.equals("CA") && selection.equals("clone") && certTag.equals("sslserver") { rather than using nested if statements. 2. You set some parameters like preop.cert.signing.type and preop.cert.signing.profile in this code, but do not unset them once processing the sslserver cert. Now this function is called for each certificate in the cert.list. That means that these parameters will have different values (potentially) depending on the order of parameters in the cert.list. Does this happen? Does it matter? 3. You set a value preop.ca.type to "master_ca", and essentially copy the section for "sdca", substituting the master hostname and port for the CA hostname and port. As we already discussed in #irc, "sdca" does not mean "security domain ca". It means "ca which is in the security domain". As such, the clone circumstance is just a special case of "sdca". A better approach might be to not create a new section for "master_ca", but rather to reuse the "sdca" section, using a boolean to set the correct ca hostname. Something like this perhaps (in pseudo-code) if (select == "clone") && (csType == "ca") && (certTag == "sslServer") { // set relevant parameters cloningCA = true; } ... if caType.equals("remote") { ... if (certTag == subsystem) { ... -> go security domain CA } else if (sdca) { if cloningCA { set hostname = ca master hostname set port = ca master port } else { ... } ... if (cloningCA) { revert any needed params? } 4. Of course, we need to figure out why its not working with the UI side. Ade On Wed, 2014-02-26 at 10:07 -0500, Ade Lee wrote: > Matt, > > Have you done a cloning test without the above patch? You can do so by > implementing the workaround. In this case, does the DS replication > issue still arise? > > Ade > > On Tue, 2014-02-25 at 17:31 -0800, Matthew Harmsen wrote: > > This patch causes the 'sslserver' certificate for a CA clone to be > > signed by its associated master CA during configuration, and resolves > > the following bug: > > * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after > > installation of ipa replica with ca > > This was necessary to avoid any changes which may have been made to > > the X500Name directory string encoding order (i. e. - creating a > > Cloned CA on Fedora 20 from a Master CA on Fedora 19). > > > > The code was tested (applying the CAVEAT below) via end-to-end > > 'pkispawn' installation and batch-based configuration; it has not yet > > been tested with GUI-based configuration. > > > > CAVEAT: > > During the preparation of this patch it was discovered that an > > end-to-end test of functionality cannot be accomplished due to > > the 389 TRAC Ticket #47721 - Schema Replication Issue which > > prevents the '99user.ldif' file from being properly replicated > > from the Master CA to the Cloned CA. However, I verified that > > this code does work by shutting down DS on the cloned CA > > machine, manually replacing > > '/etc/dirsrv/slapd-/schema/99user.ldif' with > > '/etc/dirsrv/slapd-/schema/99user.ldif, restarting DS > > and the Cloned CA, and successfully performing a test > > enrollment. > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel