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

[Wyllys Ingersoll]

Huie-Ying Lee wrote:

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

Yes, that would be nice.  Not sure how important it is, we don't have
any high-performance consumers yet.

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


Yes, but it makes the library alot bigger and we have to support
alot more code.  I don't like this option very much.


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

Yes, I think it will have to do.

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

I'm prototyping the AV-pair model to use with the new "kmf_store_key()"
function. I'll post a webrev later this week once I have it working.

-Wyllys