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

Cross-posted on <cicm@ietf.org>.
This is a discussion that started on the Cryptography mailing list:
http://lists.randombit.net/pipermail/cryptography/2011-June/000940.html

NOTE: You need to be a member to post on either list.
  RandomBit: http://lists.randombit.net/mailman/listinfo/cryptography
  IETF: https://www.ietf.org/mailman/listinfo/cicm

Nico,

On 2011-06-21 14:25, Nico Williams wrote:
> Even so, what value does this add over, any of the APIs and frameworks
> we already have?
>
> If the issue is ensuring that you are able to login to tokens, why not
> add suitable extensions to the GSS-API (basically a single function)?

The issue is much broader.

For example, here's a quote from RFC 2743 (GSS-API v2.1):
> The client generates a data message and passes it to GSS_Wrap().
> GSS_Wrap() performs data origin authentication, data integrity, and
> (optionally) confidentiality processing on the message and
> encapsulates the result into output_message, indicating
> GSS_S_COMPLETE status. The client sends the output_message to the
> server.

This makes sense for many devices and environments. However, high
assurance environments are more varied. For example, you may have two
processes that control (in a mutually exclusive manner) the channel
creation and negotiation (a Controller in CICM-speak) and the data flow
on the channel (Stream).

Another example:
In existing APIs, you can perform two operations by applying each
operation in sequence on the plaintext (e.g., encrypt and sign).
However, high assurance module often support atomic "hybrid" operations
which cannot be accomplished with existing APIs when the data that is
provided to the module does not return back to the calling program.

I understand the desire to avoid creating new APIs when there are so
many existing ones (surely one of them should do the trick!?). However,
the feedback from users and vendors is that the underlying logical 
models of their devices is sufficiently different (and varied) from what
existing APIs assume that it is difficult to retrofit their concepts and
requirements into those APIs. Among other reasons, this is why there is 
such a proliferation of proprietary APIs in these environments (which CICM
is trying to unify, abstract, and standardize).

Lev