[Pki-devel] [PATCH] 194 - Initial work for python client API

[Ade Lee]

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.
>