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

Peter Gutmann 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 
>exactly?

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, 
etc).

>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.
>http://tools.ietf.org/html/rfc6234#section-8.1

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.

Peter.



More information about the cryptography mailing list