[Pki-devel] [PATCH] 198-203 patches to address multiple issues in KeyResource server and client code.

[Ade Lee]

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" <alee at redhat.com>
> > > 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