[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: S/MIME
Let's distinguish between where the implementation is and who is responsible for invoking it. We are into another of those discussions that result from not having defined the scope of responsibility and the scope of implementation of the MSH. The MSH will be embedded in a large pile of middleware that does many functions for the application. I can well imagine that encryption would be a separate module that might or might not be invoked by the MSH. I suspect that some people are attaching the name "MSH" to the entire set of middleware although I don't think that that is what any of us intends. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David Fischer <david@drummondgroup.com> on 08/17/2001 10:24:14 AM To: Dan Weinreb <dlw@exceloncorp.com> cc: dmoberg@cyclonecommerce.com, ebxml-msg@lists.oasis-open.org Subject: RE: S/MIME 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC