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

Marsh Ray marsh at extendedsubset.com
Wed Jun 22 10:16:29 EDT 2011


On 06/22/2011 07:17 AM, Peter Gutmann wrote:
>
> Crypto API designed by an individual or a single organisation:
>
> 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.

> PKCS #11: Someone at RSA (I've heard different stories).

One could do worse.

> JCE: A couple of guys at Sun.

This one underwent breaking changes which, to this day, requires us to 
maintain two sets of code where I work.

> OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim Hudson.

I'll withhold comment on this one until the documentation is complete. :-)

And last but not least let us not forget http://botan.randombit.net/ by 
our gracious email list host!

> Crypto API designed by a committee:
>
> QED, I think.

OK, but when one of the buckets has 0 observations in it what is it 
proving exactly? Maybe simply that most crypto APIs in common use are 
designed by a "handful" or fewer guys. Which probably counts for 
something, but I think it's not so obviously prescriptive.

* Perhaps the effect you're seeing could be explained by a crypto API 
being a relatively straightforward data-in data-out type of thing. Or at 
least that's a workable oversimplification.

* 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.

* Netscape/Mozilla's NSS might be another interesting data point.

WRT IETF involvement:

* A typical IETF spec doesn't seem to have any more authors or 
significant contributors than a "small" engineering team at a big company.

* 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.

* 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

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.

The prior policy of IETF seemed to frown on formal consideration of 
APIs. I think that should definitely change, although it's not really an 
argument in support of this specific proposal.

- Marsh



More information about the cryptography mailing list