Cross-posted on <[email protected]>. 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 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
