[cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
pgut001 at cs.auckland.ac.nz
Thu Jun 23 02:03:21 EDT 2011
Marsh Ray <marsh at extendedsubset.com> writes:
>> CryptoAPI: A handful of guys at Microsoft
>I always kind of thought this one looked like someone went a little wild with
>the UML modeling tools.
I've been following it since CryptoAPI 1.0, initially it was a fairly
straightforward, basic API, but it's been bloated up over time on the design
principle of of "gimme an API to do X" as required, so it evolved rather than
being designed as such. For example CryptDeriveKey() is really
CryptProcessPasswordForWindows() (or perhaps CryptLoadContextFromHash())
rather than something where you can do PBKDF2, PGP S2K, the TLS and SSH PRFs,
and so on. In addition many of the lower-level functions in CryptoAPI are
realy only useful for implementing higher-level bits of CryptoAPI, but not as
a general-purpose API for crypto. So if your goal is "I want to do crypto the
Windows way" then it's perfectly fine. If OTOH it's "I want to read certs
from the Windows cert store for use in a non-CryptoAPI app" (for example) then
you're in for quite a bit of pain.
>OK, but when one of the buckets has 0 observations in it what is it proving
That no successful crypto API has ever been designed by a committee? We have
(at least) CDSA, TCG, and GSS-API, and none of those have seen any significant
adoption (by "significant" I mean at the same level as CryptoAPI, OpenSSL,
>It would say a lot more if there were some examples of committee-designed
>crypto APIs that nobody wanted to use because of those noticeable effects.
See above. Note that the two lists were of "Successful crypto APIs", not "Any
kind of crypto API". I'm not aware of any designed-by-committee crypto API
that's had any real penetration in the marketplace.
>Netscape/Mozilla's NSS might be another interesting data point.
How much of that is PKCS #11 and how much is non-PKCS #11 NSS? But yeah,
that'd be another example.
>Having a concrete API can keep the design grounded. There are some things in
>TLS that have *no* representation in any sane API. This could only have
>occurred by the design leading the implementation a little too far.
Actually I was surprised during the discussion of adding explicit IVs in TLS
1.1 that people brough up API issues to argue for or against particular
designs. I'd never seen that in other WGs.
>There already are crypto APIs being defined in RFCs, they're just ad-hoc
>and lacking interoperability. E.g.
Does anyone or anything of any significance use that API? I looked at it when
the RFC was published and, not to put too fine a point on it, it didn't seem
to be based on any great implementation experience.
>The purpose of the IETF considering APIs in general isn't *just* that we'll
>all get some huge new API to use and which will be considered a failure if the
>whole world doesn't move to it immediately. Just the process of defining an
>API holds potential to improve the quality of the protocols and specification.
But almost anything (including recreational pharmaceuticals) can act to
"improve the quality of the protocols and specification". Is bringing API
considerations into the design process a suitable cost/benefit tradeoff?
Could you achieve the same (or better) with a few beers worth of analysis?
The biggest factor that would affect IETF protocol design in my opinion is a
requirement to provide legitimate real-world (not gedanken-experiemtn) usage
cases. That requirement alone would instantly halve (or more) the complexity
of most security protocols (and, by extension, improve the quality etc etc).
For my part I'd be absolutely terrified of the IETF trying to specify an API.
The strength of IETF specs is that they're purely functional, so you can
implement them in C, Java, PHP, or by waiting for single event upsets to flip
the appropriate RAM bits, and as long as you get the same bits on the wire
you're OK. OTOH if a WG ever gets asked to design an API it'll make Bosnia
look like a cakewalk. Just the bikeshedding over which language bindings to
use could take years if not decades. Then there's synchronous vs.
asynchronous interfaces (the HW guys want async for performance, the software
guys want sync because async is hard), how do we make things thread-safe (does
the caller have to do it, or should we have abstract locking objects, or does
the code library do it), should we make it more OO or more functional... this
isn't just a bikeshed, it's a twelve-storey bikeshed with a magnificent
entrance hall, carpeting throughout, 24-hour portage, and an enormous sign on
the roof, saying "This Is a Large Bikeshed". See "CDSA" for an example.
More information about the cryptography