I would like to add that RFC 2630 states that future versions will support
OAEP. It says (in the security considerations section):
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
[NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1
Version 2.0 preserves support for the encryption padding format
defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
alternative. To resolve the adaptive chosen ciphertext
vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
is used to provide confidentiality. Designers of protocols and
systems employing CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5
decryption operations is not provided. Support for OAEP will likely
be added to a future version of the CMS specification.
Russ
At 08:45 AM 08/02/2000 -0400, Linn, John wrote:
OAEP's incremental value is particularly applicable to interactive uses of
CMS, many of which may not have S/MIME's established base concerns and which
should take other protocol countermeasures (perhaps implying more
security-relevant complexity and processing to be performed outside the
bounds of the security encapsulation layer) if OAEP isn't applied. I'd like
to recommend OAEP as at least a general SHOULD, making it the presumed mode
unless an application has specific need to profile otherwise; if there's an
S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the
scope of that MUST's applicability be confined to the S/MIME application.
--jl
-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Tuesday, August 01, 2000 7:01 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Way Forward
At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
> > OAEP have been available for years. PKCS#1 v2.0 includes it. I do not
>> think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>with introducing gratuitous incompatibilities.
I'm with Eric on this one. We can add a note about how to avoid the
problem *and* keep compatibility with the established S/MIME base.
The proposal was prompted by S/MIME, not CMS.
--Paul Hoffman, Director
--Internet Mail Consortium