"Novikov, Lev" <[email protected]> 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. Peter. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
