In light of these recent discussions about KEM vs. OAEP, I want to make sure
we're all on the same page. ECC, KEM, OAEP, AES, IDEA, CAST-128, ECC,
SHA-256/384/512, etc. etc. are all soon-to-be drafts, drafts and RFCs that
explain how you might use these algorithms and techniques with CMS.
I think there have been two primary questions raised -- "OAEP is sufficient,
why do I need KEM", and "I'm concerned about what this means for the S/MIME
profile of CMS".
As far as the first one goes, there seem to be lots of "redundant" methods
specified for CMS (ECC, Diffie-Hellman, RSA-PKCS for key wrapping, IDEA and
CAST-128 for symmetric algorithms). Each one has some set of
differentiators that make it more appropriate to use one algorithm over
another in a particular scenario. OAEP and KEM are in that category also.
The way I see it, we can specify lots and lots of ways to do things with
CMS, and it doesn't really matter one way or another -- this process
embodies those methods in a specification so that you implement your version
the same way as everyone else, and everything's fine.
Is the concern that faced with all of these options, which one should I
pick? If that's the case, then we're already in that situation with
symmetric algorithms. Profile writers had better know what they're doing
when the make a profile of CMS that uses one or the other.
Is the concern that OAEP is going to be stillborn and KEM is going to
immediately replace it? That seems pretty likely, based on the interest and
discussion about KEM. Write both drafts, make them RFCs and see which one
wins in the new profiles that emerge.
As far as the bearing that all of this has on S/MIME, I think that the
concern is longer term. Because of the relatively wide adoption of the
current flavors of S/MIME, I think we continue to be cautious about
modifying the profile significantly. I'm not sure that any of these recent
discussions impact this, but I thought I'd reiterate it. I share Paul's
concerns that significant changes to deployed profiles would be painful, and
I hope we continue to be conservative in that regard.
Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com