OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: S/MIME


Please see below.



Dale Moberg wrote:
> 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).

Quite true. However, let's be sure that there is an understanding
that the MSH is a concept, not an implementation specification. An MSH as a part
of a larger thing, such as a B2BI server can do anything it
deems suitable, including providing an S/MIME encryption service
to the applications or their proxies that use it, providing support
for choreography management, etc. How or what it does in this regard is 
outside the scope of the ebMS specification which is concerned solely with 
the protocol aspects and with certain required processing constraints.

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

Quite likely.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC