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

David A. McGrew david.a.mcgrew at mindspring.com
Wed Jul 27 14:45:19 EDT 2011


On Jun 21, 2011, at 6:50 AM, Peter Gutmann wrote:

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

plus RFC 5116, an internet standard that defines a simple interface to  
authenticated encryption with associated data, and is used by nine RFC  
and is referenced by 14 current internet drafts.

David

http://www.mindspring.com/~dmcgrew/ic/aead2.html
ftp://ftp.ietf.org/iana/aead-parameters/aead-parameters.xml

>
> 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
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography




More information about the cryptography mailing list