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

[John Magne]

ACK 201, comments below:

----- Original Message -----
From: "Endi Sukma Dewata" <edewata at redhat.com>
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