Re: T2 Recursive Behaviors

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

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