RE: S/MIME

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Last time I heard this issue discussed
(responsibility for data confidentiality
above transport, e.g, SSL or IPSEC),
I heard people say that there was a
requirement that an already encrypted
payload could be submitted from "the
application" or, alternatively,
digital enveloping could be a service
offered by a MSH, but in offering this
service, the MSH would go beyond the
ebXML message specification (at least,
until some future version when XML encryption
standards were settled). 

I suspected that this situation meant
that any ebXML specification support 
for these options would be through
the CPP/CPA that could document what
packaging was used to obtain data
confidentiality. Also, because MSH
really signs the MSG typically, the
case of an application signing its
payload (and possibly combining that
with digital enveloping of the payload),
would also be documented within the
ebXML framework by a CPA, and not
by anything in the MSG spec. 

So, Marty, I think the MSH-qua-ebxml-MSH
probably does no encryption (until version X.X
when XML encryption is settled). Until then,
a MSH that embodies a superset of ebxml MSH
functionality can follow the directives of
a CPA (in its virtual form) which tells it
how to securely package up its SOAP with
attachments message. 

Anyway, that is my understanding at the
moment. This reflects the idea that a CPA
can specify functionality beyond ebXML MSG
mandated (or even mentioned) functionality
for a MSH. 

Dale Moberg

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, August 15, 2001 6:36 AM
To: christopher ferris
Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: Re: S/MIME



Part of the key question is whether the MSH has to do any encrypting
itself
or whether it expects to get the encrypted payload from above.  I
suspect
the latter but the MS spec should be clear on this.

PKI-related agreements are in scope for the CPPA team and this is on the
very full plate of the security subteam.

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
************************************************************************
*************



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 08/15/2001
09:09:57 AM

Sent by:  Chris.Ferris@Sun.COM


To:   Dan Weinreb <dlw@exceloncorp.com>
cc:   ebxml-msg@lists.oasis-open.org
Subject:  Re: S/MIME



Dan Weinreb wrote:
>
> Chris, in mail some time ago, you said:
>
>    Transient confidentiality may be provided at the transport level
using
>    TLS (SSL), IPSEC or other similar mechanisms which provide for
encryption
>    on the wire. S/MIME may be used to provide for persistent
confidentiality
>    of the payload object(s).
>
> Is it really OK to use S/MIME in this way?  The MS spec doesn't seem
> to say anything about S/MIME.
>
> I have not yet gotten up to speed on S/MIME (so many RFC's, so little
> time) but would we have to specify something about how the key
> exchange is done, analogously to the initial negotiation in TLS?
> There would have to be some way to tell the MSH the avlue of the
> private key and corresponding certificate, no?  I don't really
> know the details, but it seems that if we want to allow S/MIME,
> we have to do more than just say "yes, go ahead, use S/MIME"...
>
> Thanks.
> -- Dan
Dan,

The ebMS spec doesn't say anything about the payload intentionally.
The reference to S/MIME means that the payload, not the overall
"envelope"
can be S/MIME encrypted.

As for key exchange, that is clearly outside our scope. How parties
negotiate their shared PKI is not our concern in designing the
ebMS messaging protocol. That would be in the domain of something like
XKMS.

Cheers,

Chris

----------------------------------------------------------------
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>