Re: T2 Recursive Behaviors

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

http://ietf.org/rfc/rfc2487.txt

As to whether or not this protocol is widely used/deployed is
another thing altogether. 

However, if the security requirements of the parties are so high
that they impose a requirement that the contents of the ebXML
MessageHeader be made persistently confidential, so as to require
S/MIME encryption of the SOAP:Envelope as well as the payload
objects themselves, one would ask why they are using a relatively
insecure, and for that matter unreliable, transport mechanism 
such as SMTP in the first place!

Cheers,

Chris

David Fischer wrote:
> 
> Very Good Chris, now can you point me to the RFC for SSL over SMTP?
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Tuesday, July 31, 2001 10:05 AM
> To: David Fischer
> Cc: ebXML Msg
> Subject: Re: T2 Recursive Behaviors
> 
> David F,
> 
> We have covered this ad nauseum. The present specification does not
> cover the use case of applying persistent confidentiality (encryption)
> on selective elements of the SOAP envelope BY DESIGN and following a careful
> and thoughtful deliberation by the team. It is not an error of omission
> if that is what you imply.
> 
> This capability will be enabled (and likely described/specified in a
> future version of the specification) once the W3C finishes its work on
> XML Encryption.
> 
> 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).
> 
> I think that rather than attempt to describe what you propose, that a
> primer on use of S/MIME for payload confidentiality between parties
> would be far more useful to a broader audience at this point.
> 
> The team also had many long discussions regarding recursion w/r/t
> message encapsulation. It was the consensus of the team that it added
> significant complexity, more than the team was willing to accept for
> the most part.
> 
> Unless a processing intermediary is involved, use of recursive encapsulation
> as you describe, using S/MIME seems overly complicated and doesn't
> add much value over use of SSL or IPSEC, IMO.
> 
> Cheers,
> 
> Chris
> 
> David Fischer wrote:
> >
> > I am working on creating some specific examples of how to use this spec and
> one
> > of the foremost requirements will be SMIME encryption.  I don't see how anyone
> > can implement without the ability to encrypt and I don't see how to do
> > encryption without this recursive behavior.
> >
> > It is often not sufficient to encrypt just the payload.  In many cases, users
> > will want all information which reveals the content (especially the Manifest)
> to
> > be encrypted.  SMIME must encrypt from boundary to boundary so the entire SOAP
> > envelope will have to be included in order to get the Manifest.  This behavior
> > IMO is required by this spec and should be included.
> >
> > I don't think this has to be a long explanation.  A one sentence statement to
> > include recursion (encapsulation) should be sufficient.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Monday, July 30, 2001 2:32 PM
> > To: 'David Fischer'
> > Cc: ebXML Msg
> > Subject: RE: T2 Recursive Behaviors
> >
> > David
> >
> > I think the process (encapsulation) is a useful one. However I think that
> > this should be a separate spec that describes how to do it - it could be an
> > OASIS TC spec. There are several other useful examples, for example using
> > sequencing to transport very large messages by chopping them into chunks.
> > They are both additional good ideas that can be layered on top of what is
> > already there.
> >
> > David
> >
> > -----Original Message-----
> > From: David Fischer [mailto:david@drummondgroup.com]
> > Sent: Monday, July 23, 2001 7:07 PM
> > To: Burdett, David
> > Cc: ebXML Msg
> > Subject: T2 Recursive Behaviors
> >
> > It seems that there will be no way to avoid occasional recursion within
> > ebXML-MS
> > such as encrypting a message with SMIME and putting the result in a bodypart
> > wrapped by a minimal ebXML header structure.  At the receiving end, the
> > bodypart
> > would then be decrypted and the resulting message resubmitted to the ebXML
> > parser (recursive).
> >
> > This behavior would also solve the concern over potential in-route additions
> > to
> > the Manifest (put the old message in a bodypart, create a new set of headers
> > with additions to the Manifest, then once the new message is parsed then the
> > old
> > message should be resubmitted to the parser (recursive)).
> >
> > While none of this behavior is prohibited by the current spec, neither is it
> > specifically allowed.  Can we add one sentence somewhere to specifically
> > allow
> > this?
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org