RE: Should ebXML standards be based on XML?

[Matthew MacKenzie <matt@xmlglobal.com>]

David,
  The notion of being able to "tunnel" messages through a server without 
decryption is interesting, but I wonder how necessary that is.  Presumably
a message isn't going to be routed through too many hostile servers - I
would imagine communication would be from firewall to firewall (trusted to
trusted), and the majority of routing being done should theoretically be
either on a local trusted network or a remote encrypted VPN.  PKI is an
option - let MIME handle the routing, leave the XML payload encrypted, if
routing through multiple (or any) quasi-trusted hosts is necessary. S/MIME
(from my cursory RFC check), seems to be compatible with OpenPGP and any
other sort of encryption method you can cook up - it may be a viable
option.

Cheers,

--
Matthew MacKenzie
VP R&D / CTO XML Global


On Fri, 14 Apr 2000, David Burdett wrote:

> Matt
> 
> Basically I agree with you - we should use MIME *and* XML - this was the
> effective conclusion of my note. Some comments below.
> 
> David
> 
> -----Original Message-----
> From: matt@xmlglobal.com [mailto:matt@xmlglobal.com]
> Sent: Friday, April 14, 2000 11:25 AM
> To: David Burdett
> Cc: ebxml@lists.oasis-open.org; ebxml-requirements@lists.oasis-open.org;
> kit@mitre.org
> Subject: RE: Should ebXML standards be based on XML?
> 
> 
> Why must issues such as encryption and transport even be contemplated now? 
> >>Since there is a real need for it.<<
>  If we do well in designing the message format by using a combination of 
> MIME and
> XML, it will be trivial to add the transport and encryption mechanisms 
> later.  
> >>I agree<<
> It is only remotely beneficial to waste time on these components 
> for the sake of things that
> should be built in, like content and receipt verification, and process 
> flow.
> 
> If  MIME+XML is specified as the lingua franca for messaging, we already 
> have a transport mechanism that supports both (HTTP).  This transport 
> mechanism also supports
> certificate based encryption, (SSL,TLS, etc.).  Other transport mechanisms 
> can also use SSL.  The SSL approach is nice because the decryption is 
> handled pretty seamlessly, so 
> applications would not be limited to a few headers of elements that were 
> left unencrypted for the routing of processing decision stages.
> >>I agree, but when the message gets to a server, then it is unencrypted.
> There is a need to be able to encrypt documents in a way so that they can
> tunnel through servers without being decrypted - S/MIME handles this
> nicely.<<
> 
> I think the key is to establish a chain of preferred protocols, sort of 
> like how web browsers will often try to negotiate a HTTP/1.1 connection, 
> but can always fall back to HTTP/1.0.  ebXML should
> define a sequence of accepted encryption+transport schemes, and have the 
> sending software able to handle them all.  Then, the receiver can 
> implement what he/she likes for accepting
> transmissions - and the sender can simply reject to send to receivers who 
> do not meet their security baseline.
> >> I think we either need "negotiation" - which means we do it every time we
> make a connection, or we need "discovery" which means there is a standard
> way to discover how to communicate which can then be cached.<<
> 
> my $0.02 (CAD) 
> --
> Matthew MacKenzie
> VP R&D / CTO
> XML Global Technologies, Inc.
> 
> 
> 
> 
> David Burdett <david.burdett@commerceone.com>
> Sent by: owner-ebxml@lists.oasis-open.org
> 14/04/2000 08:38 AM
> 
>  
>         To:     "Kit (Christopher) Lueder" <kit@mitre.org>
>         cc:     ebxml <ebxml@lists.oasis-open.org>, 
> ebxml-requirements@lists.oasis-open.org
>         Subject:        RE: Should ebXML standards be based on XML?
> 
> Kit
> 
> The bottom line on this is that **current** XML standards do not **yet**
> meet **all** our requirements. Please note the emphasis. Specifically, it
> does not support encryption, which is a real business requirement. Below I
> present the choices we have and then an analysis of each one ... which 
> leads
> to a conclusion. 
> 
> If you disgree with any of this reasoning please state clearly the reasons
> why.
> 
> I am also copying this to the Requirements group so that they can also
> understand the choices we are *having* to make.
> 
> Regards
> 
> David
> 
> CHOICES
> We have a few choices for going forward:
> 1. Wait until the W3C develops the standards that we need. On encryption
> this could be 12? 18? months away.
> 2. Develop an ebXML but leave gaps where the w3C cannot (yet) provide
> solutions.
> 3. Develop our own "XML" equivalent to cover the gaps, e.g. for 
> encryption.
> 4. Adopt an existing accepted standard method of encryption as our one and
> only ever solution. The only one I know of is S/MIME.
> 5. Adopt a hybrid approach. Specifically, we do an "XML only solution" 
> when
> encryption is not needed and some other (S/MIME?) when it is.
> 6. Adopt a non-XML solution in the short term, then when the W3C or other
> standards groups have developed technology that meets our needs move 
> towards
> it.
> 
> KIT. Do you agree that this is a comprehensive list of alternatives - 
> please
> suggest others if you think not ?
> 
> ANALYSIS
> Option 1 - Wait for the W3C
> If we wait for the W3C to develop standards before we can completely 
> specify
> ebXML transport, then we should stop NOW, contribute to these other 
> efforts
> to speed them and then reform later when the missing standards are 
> becoming
> more stable. This means that no implementations of ebXML Transport could
> start until say at least 12 months away. This is unacceptable in my view -
> frankly if ebXML is not going to deliver anything useful for 18 months, 
> then
> my company has much better use to make of time.
> 
> Option 2 - Leave gaps until the W3C develops a solution
> Some of the gaps (e.g. encyrption) are reall business requirements (e.g. 
> for
> C1). This means we would have to devise our own separate solution to meet
> the need. However this would non-interoperable with other solutions and
> would require implementers to devise two solutions.
> 
> Option 3 - Develop our own XML technology to cover the gaps
> I would seriously question that the ebXML group has the appropriate skills
> to develop, for example, an XML based encryption approach. If we did try, 
> we
> will probably get it wrong and anyway it would compete with the W3C
> approach. This is also unacceptable as we should only do things we have 
> the
> skill to do and we shouldn't compete with the W3C.
> 
> Option 4 - Adopt an existing standard method as our one and only solution.
> This will allow us to continue working now on ebXML and will have the
> "benefit" that we will never change it ... except that existing standards
> change anyway over time. So even if, for example we only ever wanted to 
> use
> MIME, we would have to change at some point in the future as MIME evolves. 
> I
> think we can't ever commit to a single "standard".
> 
> Option 5 - Adopt a hybrid aproach.
> This is unacceptable, at least in the short term, since it means that
> implementers would *have* to develop two alternative solutions at the same
> time when there is no need. It would also overly complicate the solution 
> and
> delay its adoption.
> 
> Option 6 - Adopt a non-XML solution in the short term.
> This is like Option 3 in that we can continue to move forward immediately.
> However it recognizes that existing standards evolve and new standards are
> developed. Therefore, when "good" new standards are developed that meet 
> our
> requirements, e.g. for encryption. Then they can be adopted.
> 
> CONCLUSION
> It is my honest opinion that the W3C and the XML community in general 
> will,
> over the next 12-18 months, develop XML based solutions that will meet all
> our requirements. I also anticipate that we will more than likely adopt 
> them
> in a new version of the ebXML transport. But until then, we MUST NOT make
> the completion of our work dependent on the development of standards that
> not only do not yet exist - no work has even started on them. I think
> therefore that option 6 is the only viable approach we can take.
> 
> If you disagree with my analysis, please state clearly the reasons why and
> what alternative "choice" you think meets our needs better.
> 
> Regards
> 
> David
> 
> 
> -----Original Message-----
> From: Kit (Christopher) Lueder [mailto:kit@mitre.org]
> Sent: Friday, April 14, 2000 5:39 AM
> To: ebxml
> Cc: ebxml-requirements
> Subject: Should ebXML standards be based on XML?
> 
> 
> There is an active debate currently going on at the ebXML
> Transport/Routing/Packaging list about whether the ebXML standards
> should be based on XML. The current direction of that group is to use
> MIME for the outer envelope, not XML. They are proceeding with a
> specification that will be brought forward for vote, but that seems like
> a pretty late time to ask for a change in direction, if you disagree
> with their approach. If you have any concerns, this may be an opportune
> time to express them.
> Kit Lueder.
> MITRE.
> 
> -- 
>     _/    _/             Kit C. J. Lueder 
>    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
>   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
>  _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
> _/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
> Worse than an unanswered question is an unquestioned answer.
> 
> <snip>
> 
>