[kmf-discuss] Extension to the API

[Wyllys Ingersoll]

Massimiliano Pala wrote:
> Darren J Moffat wrote:
> [ pkcs11 ]
>>
>> Nice and easy and no need to duplicate this API into KMF space.
>>
> 
> That is true, but requires me (as app developer) to either:
> - restrict my application to use a pkcs11 store only, or
> - setup a pkcs11 additional store when I need those functionality

Generating a hash or pulling random numbers is not a keystore-specific
operation, so it shouldn't matter where your keys are stored, you
can always generate a hash or pull random bits via the crypto-framework
and still use a different store to actually store the keys and certs.


> So, for example, if I have a store which provides me with hardware
> acceleration and I am already using it (but it is not a pkcs11 one),
> then I will have to setup a pkcs11 one and use the software
> implementation ?
> Moreover, AFAIK in the API documentation the functionality you specify are
> not even listed, e.g. KMF_GetPK11Handle() or C_GenerateRandom().


KMF_GetPK11Handle will be documented next time I update the spec.
C_GenerateRandom is a standard PKCS#11 interface and is documented
in the docs referring to the crypto framework.


> I guess the basic point of KMF is to provide a consistent API which will
> take care about the store details. In this vision I would expect KMF to
> provide me with:
> - hardware implementation of functionality if the store supports it
> - software fallback implementation if the hardware does not support that
>   feature

You are describing the Crypto Framework (PKCS#11) design moreso than KMF.
KMF gives you the same result when you use the PKCS#11 keystore
type.  If you have hardware that is not plugged into the crypto framework
(i.e., there is no PKCS#11 provider), then I don't know how
KMF or any other framework would be able to use it without special code
being written.

> In this way I can actually abstract from the type of store so that I can
> use the same application with different stores and not have to tune to
> support a specific feature that would work only on a specific type of
> store. Otherwise I would go for pkcs11 and not use KMF, this would also
> guarantee my application to be working with a broad range of hardware
> tokens.

KMF is only for Key Management and PKI related objects.  Generating a
hash is a more general crypto operation and pulling random bits
is really not specific to key management either, that is why we
don't put it all under the KMF API umbrella.  We have existing
APIs that cover those operations quite well, so it wouldn't make
sense to duplicate those interfaces.


> From my point of view, then, a ``duplication'' of the APIs in KMF space is
> not a duplicate, but a requirement for store usage and API consistency.

Why is it a requirement?  Our goal was never to force all crypto
and key operations to go through a KMF operation.  Our goal was to
bridge gaps that are missing and provide some higher level interface
functionality for PKI objects that PKCS#11 doesn't provide and to
make the hide the details of interacting with different keystores
(OpenSSL, PKCS#11, and NSS).  No functionality is missing, you just
have to choose the right APIs depending on the operation being done.

It is perfectly acceptable to mix KMF and PKCS#11 function calls
if necessary.   KMF was never designed to provide complete coverage
for PKCS#11 (or OpenSSL).

> 
> The other option I have is to implement wrapper functions over the pkcs11
> as you suggested over the pkcs11 store, but I might be loosing the hardware
> implementation in same cases.

I think there is some misunderstanding here.  Using PKCS#11 to do the
Digest and Random number operation ensures that you *WILL* get
the benefits of hardware if the hardware is properly plugged
into the crypto framework.    Don't use the libmd interfaces
as I suggested earlier, use C_Digest (and friends) instead.


-Wyllys