[cryptography] [cicm] CICM BOF Summary
lnovikov at mitre.org
Wed Aug 3 09:56:44 EDT 2011
NOTE: Cross-posting from cicm at ietf.org to cryptography at randombit.net
(Hat-tip: Kevin Wall)
Last week we had a BOF at IETF 81. Thanks to all who attended (in-person
and via Jabber). For those who couldn't make it, a summary:
--- Begin Summary ---
Dan Harkins and Dan Lanz were the BOF Chairs.
Sean Turner and Stephen Farrell are the Security ADs.
Vincent Roca presented slides about using CICM in a
High Assurance, High Performance Security Gateway.
Lev Novikov presented slides about CICM's logical model and how
security domain separation makes CICM different from other crypto APIs.
There were several points of discussion:
1. What about existing approaches:
* Why can't you extend PKCS#11 so that crypto operations like
encrypt always return TRUE?
A few reasons were given:
(a) CICM needs richer semantics (more and different kinds of
inputs) than what is available in PKCS#11. Previous attempts
at extending PKCS#11 became a mess.
(b) Return values can be more complex than just TRUE (e.g., list
of things that went wrong).
* What about using an existing protocol as an interface?
CICM could sit under such a protocol; it is also intended manage
the crypto (note the large number of management commands), and not
just the pipe (channel).
* Which approach, C-style or object-oriented, was intended? The .NET
crypto classes might be suitable for an object-oriented approach.
CICM is defined in IDL for which one can generate bindings in many
different languages including C, C++, Java, etc. We will have to
investigate the .NET approach further.
** There was a request that folks on the list discuss these issues for
the benefit of the community.
2. The charter is insufficient for a Working Group:
* It was noted that there could be two goals:
(a) to produce multi-vendor support for a standard interface
(b) to introduce these concepts into existing IETF protocols
* The charter appears to be too detailed; it should focus more
on outlining the problem scope well.
* CICM appears to address requirements that are not well explained
in published documents.
* How would CICM work with Authenticated Encryption with
Authenticated Data [RFC 5116], TLS, or IPSEC? What are the
consequences on other protocols?
The major consequence of these points is that we should re-write the
charter and write documents to address the:
* larger problem scope
* logical model (in more generic terms) and requirements
* impact of this logical model on 2-3 existing protocols
* details for an corresponding API (e.g., CICM)
--- End Summary ---
More on this to follow.
More information about the cryptography