Re: S/MIME

[christopher ferris <chris.ferris@east.sun.com>]

+1

Martin W Sachs wrote:
> 
> 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>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>