Subject: Charter Update

From: "Housley, Russ" <[email-masked]>
Date: Wed, 17 Apr 2002 16:56:54 -0400

The S/MIME WG is very out of date.  I propose the attached charter as a 
replacement.

Note that I have assumed that the use of RSA OAEP key management will be 
published as a separate RFC (not combined with the AES draft).  The 
rationale for this assumption is available in the presentation that I gave 
in Minneapolis.  The slides are on-line at 
http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html.

Please comment on the proposed charter.

Russ
S/MIME WG Chair

---

From: Robert Zuccherato <[email-masked]>
Date: Fri, 19 Apr 2002 10:46:20 -0400

Russ;

Having not attended the Minneapolis meeting I must say that I was very
surprised by your recommendation to drop OAEP as the MUST implement key
transport mechanism with AES in favour of KEM.  It wasn't all that long ago
that you were attempting to get everyone (S/MIME, TLS, X9.44) to agree on
requiring OAEP with AES as a method of transitioning to OAEP from PKCS#1
v1.5.  Partly as a result of that effort, implementations of OAEP have
started to appear (e.g. OpenSSL) and transitions to OAEP can actually now
start to occur.  If we are going to introduce a new MUST algorithm, and thus
additional uncertainty about what to use and how to transition, we really
should have a good reason.

In your presentation you say that KEM has better security proofs.  That may
be, however, OAEP is still secure.  No actual weaknesses in it have been
found.  On RSA's website there is a description of recent results on OAEP
that says "... it makes little sense replacing OAEP with a "more secure"
encoding method, because if a CCA2 adversary is able to break RSAEP-OAEP,
then she will be able to break RSAEP equipped with any encoding method (if
maybe slightly less efficiently)."
(http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.html)  Thus,
there is no need to introduce KEM for security reasons.

Your presentation also lists some standards that already include KEM.
However, all of the ones that are listed except TLS also specify OAEP (ANSI
X9.44, IEEE P1363, ISO/IEC 18033-2, PKCS#1, S/MIME).  TLS, while it
specifies a variant of KEM, doesn't actually use anything that is compatible
with the KEM that S/MIME (and the other groups listed) would be using.  I
would also like to point out that XML Encryption has OAEP as a required key
transport method.  At this point it does seem like OAEP is starting to get
adopted by other groups and thus introducing KEM now seems to be
counterproductive.

It is true that with OAEP the message length is bounded.  However, for our
requirements here, is that really an issue?  

For these reasons I think we should reconsider your proposal to use RSA-KEM
instead of RSA-OAEP in draft-ietf-smime-aes-alg.

Robert Zuccherato
Entrust, Inc.

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 4:57 PM
> To: [email-masked]
> Subject: Charter Update
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 21 Apr 2002 17:26:47 +1200 (NZST)

Robert Zuccherato <[email-masked]> writes:

>transport mechanism with AES in favour of KEM.

This was done to death on the list a few months back.  The consensus seemed to
be that there was little support for OAEP, and a fair bit of opposition to
tying it to AES (see the list archives for the exact details and rationale).

>Partly as a result of that effort, implementations of OAEP have started to
>appear (e.g. OpenSSL)

The OpenSSL OAEP had nothing to do with this, OAEP was added on an experimental
basis in late '98 or early '99 after the first PKCS #1v2 drafts appeared, and
it's stayed at that level ever since.

Peter.

---

From: Robert Zuccherato <[email-masked]>
Date: Mon, 22 Apr 2002 11:11:21 -0400

> tying it to AES (see the list archives for the exact details 

But, it there is little support for OAEP, why replace it with a newer
mechanism that has even less of an installed base?  It seems to me that
there are fewer reasons for using KEM than there are for using OAEP.

	Robert.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 24 Apr 2002 14:44:37 +1200 (NZST)

Robert Zuccherato <[email-masked]> writes:

>mechanism that has even less of an installed base?  It seems to me that there
>are fewer reasons for using KEM than there are for using OAEP.

Oh, you mean AES now *requires* KEM?  (I wasn't at Minneapolis either).  I
agree there, tying KEM to AES is just as bad as tying OAEP to it, for all the
reasons given during the debate some months ago.  Certainly a MAY is OK, but
the best place for it would appear to be in the CMS sundry-algorithms draft.

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 24 Apr 2002 17:14:25 -0400

Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should be in separate, 
independent documents.  This would allow AES to be used with any of the key 
management techniques?

Russ