RE: S/MIME

[David Fischer <david@drummondgroup.com>]

OK, we don't need to write it into the spec, but companies are implementing now.
When vendor's ask if encryption should be included in the MSH, we need to give
them an answer.  I think the answer, even now, has to be Yes.  Since vendors are
already implementing SMIME encryption and since much of this is done through
Security Toolkits, I don't think this is a lot of work since those same toolkits
are likely to be reused for XMLencryption.  I do foresee, however, that we will
have to support both SMIME and XMLencryption (when it is ready), at least for a
while.  Since SMIME is in the payload, we should probably support it
indefinitely -- its just another payload (which unfortunately impacts the
Manifest).

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Friday, August 17, 2001 7:54 AM
To: david@drummondgroup.com
Cc: dmoberg@cyclonecommerce.com; ebxml-msg@lists.oasis-open.org
Subject: Re: S/MIME


   Date: Thu, 16 Aug 2001 19:51:56 -0500
   From: David Fischer <david@drummondgroup.com>

	      I'm not comfortable with the idea that each Application has to
   include an encryption/decryption module.

Certainly, I would expect that everybody agrees with you about that.
EbXML MS should, in principle, provide encryption/decryption.

Evidently, the problem is that in the long run, we want encryption to
be provided by ebXML MS, but the encryption standard that we want to
build ebXML MS upon, namely XML Encryption, is still being developed.

   I'm not sure we want to say encryption will be in our scope in the future but
it
   isn't now.

If we know that in the long run, we want to base our encryption on the
XML Encryption standard, then to add encryption based on some other
standard temporarily (e.g. S/MIME) would be "planned obsolescence",
and create a lot of work that will just have to be thrown away in the
relatively near future.

-- DAn