Subject: RE: Should ebXML standards be based on XML?
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: firstname.lastname@example.org [mailto:email@example.com] > Sent: Friday, April 14, 2000 11:25 AM > To: David Burdett > Cc: firstname.lastname@example.org; email@example.com; > firstname.lastname@example.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 <email@example.com> > Sent by: firstname.lastname@example.org > 14/04/2000 08:38 AM > > > To: "Kit (Christopher) Lueder" <email@example.com> > cc: ebxml <firstname.lastname@example.org>, > email@example.com > 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:firstname.lastname@example.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: email@example.com > Worse than an unanswered question is an unquestioned answer. > > <snip> > >
Powered by eList eXpress LLC