Glad to get involved. Unless I am missing a trick - Reflex MailSafe
implements both RSA and D-H - which enables it to be both backward
compatible if dealing with mail from S/MIME v2 users and forward compatible
for S/MIME v3. My question was really - unless I am missing the point - why
therefore dilute the S/MIME v3 standard?
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: 08 August 2000 17:39
Subject: RE: Way Forward
We encourage additional implementations to participate in the
I understand the concern that you raise about changes in the
mandatory-to-implement algorithms. This is why we are having a discussion
before any action is taken. Other implementors support RSA and do not
support D-H. These folks would like to see S/MIME v2 and S/MIME v3 have an
interoperable mandatory-to-implement algorithm.
At 02:51 PM 08/08/2000 +0100, Jim Davies wrote:
I am a recipient of the mailings in this group - as someone with limited
technical knowledge but a business interest in PKI - and S/MIME 3 standards
in particular. Please make allowances therefore if any of my questions or
comments are totally off beam!
I have been following the discussions prompted by the proposals below on
2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3
Certificate handling - and RFC 2633: S/MIME Version 3 Message
My project is currently based around a mail product called Reflex MailSafe
(http://www.reflex-magnetics.com). It offers full S/MIME 3 compatibility
and can use either DH or RSA for generating key pairs. A "cut down" 56 bit
version is available at the web site - other than key length it is fully
functional. At present there is only a mail client - in due course it is
planned to offer various network features.
To my mind - the use of DH keys is preferable to RSA. I had assumed that -
as a result of using DH keys - S/MIME 2 products would not be able to read
S/MIME 3 encrypted - and DSA signed - messages.
I am concerned that what appears to be happening is a downgrading or
watering down of S/MIME 3 in order to enable interoperability with S/MIME 2
products. It seems particularly curious when there is a mail client
available that - so far as I can tell - provides the previously stated
functionality. I need to be able to make sound business planning
decisions - and this debate has thrown me into a bit of a spin.
Am I mis-reading what appears to be going on - or do I have a genuine need
to re-consider my planning? Also - were you aware of Reflex MailSafe -
which I believe to be the first product available that offers full S/MIME 3
compatibility? If not - does any of the above have any impact on the
proposed changes to the standards?
As I said at the outset - please disabuse me if I have missed the point
completely - much of what is discussed quite frankly goes over my head!
I look forward to hearing from you.
Director - GPM Ltd.
82 Dartmouth Park Hill
London N19 5HU
Tel. +44 (0) 20 72810123
Fax +44 (0) 20 75611666
Mobile +44 (0)7958 523479
This e-mail transmission (and any attachment) is strictly confidential
and intended solely for the person or organisation to whom it is
addressed. It may contain privileged and confidential information and
if you are not the intended recipient, you must not copy, distribute or
take any action in reliance on it. If you have received this e-mail in
error, please notify us as soon as possible and delete it.
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Russ
Sent: 31 July 2000 22:05
Subject: Way Forward
At the face-to-face meeting today, we had a fair amount of discussion about
the best way to proceed. This message states each of the issues and the
proposed way forward. This message is intended to give everyone an
opportunity to provide their input, even if they were unable to attend the
RFC 2630 Interoperability Testing
Issue: Two implementations have been tested for EnvelopedData and
SignedData. These two data structures are required to implement S/MIME, so
this is not surprising. RFC 2630 includes other data structure that are
MUST implement(EncryptedData, DigestedData, and AuthenticatedData). We do
not have two implementations for these data structures.
Proposed way forward: Change the implementation requirements so that:
- EnvelopedData and SignedData MUST be implemented; and
- EncryptedData, DigestedData, and AuthenticatedData MAY be
Mandatory To Implement Algorithms
Issue: Since the RSA patent is about to expire, Blake Ramsdell suggested
that the RSA algorithm become the mandatory to implement algorithm for key
management and signature. It was pointed out that the current RSA key
management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
should be employed instead. While we were discussing algorithms, it was
suggested that AES should be the mandatory to implement symmetric cipher
instead of Triple-DES. About half of the people thought that this was a
good idea. The other half was concerned that the AES has not been
Proposed way forward: Change the mandatory to implement algorithm set to:
One-way Hash: SHA-1 (no change)
Signature: Both DSA and RSA (PKCS#1 v1.5)
Key Mgmt: RSA (OAEP)
Eencryption: Triple-DES in CBC mode
All comments on either of these proposals is most welcome.