[cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)

Peter Gutmann pgut001 at cs.auckland.ac.nz
Tue Jun 21 09:50:38 EDT 2011

"Novikov, Lev" <lnovikov at mitre.org> writes:

>There is an existing class of devices and environments (e.g., military and
>diplomatic communications) which have particular requirements that are hard
>to retrofit into existing crypto APIs (i.e. the logical models are
>substantially different).
>For example, many of these devices operate in a manner such that the results
>of cryptographic operations are not returned to program that initiate the
>operation--as they are in existing crypto APIs. Rather, the request starts in
>one security domain, is executed by the crypto (which is on the border
>between two domains), and the result emanates in another domain.

I guess my question had insufficient detail :-).  The problem is that
introducing a totally new crypto API today is going to be pretty much
impossible.  The NSA, in the mid to late 1990s, when the only well-established
crypto API around was PKCS #11, published three different reports on crypto
API design, presumably to meet the sorts of goals you're listing, but AFAIK
the work never went anywhere.  Now we have PKCS #11, CryptoAPI, JCE, OpenSSL,
and some others, as well-established, entrenched APIs.

I cannot imagine what size hammer you'd need to wield to convince vendors to
implement a totally new API for their products.  You might be able to add a
new object-type to PKCS #11 (this has been done for some other mechanisms like
additional auth.mechs) to handle this, leveraging the investment in the
existing API, but I just can't imagine how you'd get vendors to support a
completely new API (even for PKCS #11, development has pretty much stagnated
for some time, not through any lack of interest but because you can do pretty
much everything that most users need, so there's not much incentive to push
things in new directions).  The problem really is political, not technical.


More information about the cryptography mailing list