Blake & Peter,
Sorry for not getting back on this issue sooner, but I had other fish
that needed to be fried.
In this message I am attempting to summarize you arguments and put in my
responses.
1. [Peter] Everybody has already implemented this.
- Three responses to this point:
1. I don't actually believe that this is true. While there are quite
likely several different individuals who have implement this (you and
Getronics be examples) I don't think the "major" e-mail vendors have yet
rolled this out for general usage. This is not yet an option in my
version of Microsoft Outlook anyway.
2. It does not really matter if people pre-implement the documents we
are writing. The introductory paragraphs say that we reserve the right
to mess with you head if you implement a draft document.
3. I don't believe the current absence of hardware for doing OAEP
will last very long if it is adopted in a standardized way. (I think
that PSS will be coming very soon as well.)
2. [Peter] It does not matter what we say, people are going to use
PKCS#1 v1.5 anyway.
- People do a lot of stupid things a great deal of the time (myself
included). I don't believe this is a reason for us to "bless" things
that we think could be done in a better way at very little cost.
3. [Peter, Blake & Dean] The Bleichenbacher attack is not a problem for
S/MIME.
- First, CMS is not S/MIME. I agree that this is not a huge issue for
an S/MIME implementation, however should this be an issue that needs to
be covered in every single protocol that uses AES (i.e. should CMC have
this as a huge concern). There are going to be interactive protocols
that use CMS, if we can nip this attack in the bud for all of those
protocols, I consider this effort well spent.
4. [Blake] Specification purity says that key management and content
encryption documents should not restrict each other.
- Blake - I just completely disagree on this issue. I think that each
type of algorithm can put restrictions and updates on usage for the
other type. I believe that it is perfectly reasonable for a content
encryption algorithm to impose limitations on what key management
algorithms are allowed. It could also modify the algorithms as
necessary (for example the original drafts change the key derivation
algorithm used with AES and D-H). I can get behind the purity of one
algorithm-one document, but not that they cannot put restrictions on
each other.
Jim