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

Ade Lee alee at redhat.com
Tue Feb 25 21:05:39 UTC 2014


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.



> 
> 





More information about the Pki-devel mailing list