[Top] [All Lists]

RE: Way Forward

2000-08-08 09:36:24

We encourage additional implementations to participate in the interoperability testing.

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:
Hi Russ

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 RFC
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 specification.

My project is currently based around a mail product called Reflex MailSafe
(  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 here
completely - much of what is discussed quite frankly goes over my head!

I look forward to hearing from you.

Best wishes


Jim Davies
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
Email   JimDavies(_at_)gpm(_dot_)co(_dot_)uk

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.

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Russ Housley
Sent: 31 July 2000 22:05
To: ietf-smime(_at_)imc(_dot_)org
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 implemented.

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
published yet.

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.


<Prev in Thread] Current Thread [Next in Thread>