[kmf-discuss] Changing the API - pros/cons

[Huie-Ying Lee]

Wyllys Ingersoll wrote:
> I think we need to decide pretty soon how we want to develop the API/SPI
> layers going forward.  One goal should be to provide an interface
> that can be extended with minimal disruption to existing consumers
> of the interface.   The current method of changing the parameter
> structures or changing the functions prototype signature is
> pretty disruptive and will not scale well when we move this to
> a more open taxonomy level.
> 
> One way to do this is to move to a PKCS#11 model where we pass
> arrays of Attribute/value pairs.   This works great for extensibility
> since the function prototypes never really have to change.
> However, if we do this we lost the type-checking features
> provided by the compiler and lint tools, which are sometimes
> very useful in identifying potential bugs at build time.
> 

Another advantage of moving to a PKCS#11 model is that an application
can set/get all the attributes in one function call.   If performance
is very important for KMF APIs, the PKCS#11 model earns 1 point here.


> It was also suggested at our ARC review that we either make the
> input *_PARAM blocks opaque or come up with some way to make
> the interface extensible before we expose the interface to the
> world, so we need to fix this soon.
> 

Making the input *_PARAM blocks opaque requires KMF to provide
get/set functions for every fields in the data structure.

This approach will make KMF API  more C++/Java like, which is a
good thing, in term of compatiblity with Java JCE APIs.


> If we change to the A/V pair model, what will we do with the current
> interfaces - would we keep them and come up with a whole new
> set of function names?  We cannot have both, obviously.
> If we go to a new naming convention, what would it look like?
> I am kind of fond of our current scheme, but we did have
> some comments in our reviews about using a different naming
> scheme.  We could go with the "standard" Solaris style -
> ex:  kmf_store_key(), kmf_create_key_pair(), etc...
> 

This sounds good to me.

> I don't care for that style, but it is consistent with alot of
> other Solaris libs and would at least give us a way out of the
> mess.
> 
> I want to resolve this ASAP as I was about to start fixing the
> CreateKeypair problem (don't automatically store the keys), which
> will require adding at least 1 new api - KMF_StoreKey and wanted
> to think about fixing the other APIs before I attack that problem.
> 
> Comments?
>   -Wyllys
> 

I thought about this last night and considered all the pro's and con's
between these 2 solutions.   It is hard to choose still.

Huie-Ying