Re: Last Call: MIME-based Secure EDI to Proposed Standard

[Alan DeRossett <alan@xxxxxxxxxxxxxxxxxxxx>]

As an ISP since 1995 we've designed peer to peer payment systems , inventory
control and
logistics management web sites, A application we may built would be Customer to
Long Distance Carrier Least Cost Call Routing. We hope to see more support for
SSL ,PGP and secured Email. Current EDI software with expensive VAN interfaces
may be ok for the Fortune 500 Companies, but will never work from my PCS phone.
I would like to find an Open source project in perl, java or php to translate
standard SQL data into  the various X12
forms. The Security software will need to changed and patched rapidly and
should not be part of the standard.

Alan DeRossett
Digital Starlight Communications Inc.

Ricardo Johnson wrote:

> Paul, all
>
> You are right on the money. What the EDIINT group is proposing is indeed
> peer-to-peer EDI raped around MIME and, if secured S/MIME. That is a viable
> alternative although self limiting in scope. After the EDIINT group is
> seeking is to expand the use of EDI while reducing the cost and complexity
> of VANs.
> If we wish to reduce the cost of VANs and expand the use of EDI then we
> must substitute, not eliminate, the important functions that VANs provide:
> confidentiality, integrity, non-repudiation of origin and receipt,
> archival, time stamping, tracking, and others. Security software can and
> should replace many of these key functions. That software exists today and
> it is no more complex or expensive than the email protocols being proposed
> by the EDIINT group. Considering what companies are paying for VANs every
> months, the savings could be huge.
>
> My observations may be too late to change anything. However, I agree with
> you: At least the title of the document should be adjusted to "peer-to-peer
> EDI" in order to reflect the limitations of the current AS1 proposal.
> Finally, serious evaluation should be given in the future to X12.58 and
> EDIFACT security as another viable alternative to inter-operable and
> reliable EDI.
>
> Ricardo
>
> 10:58 a.m. 23/11/01 +0000, Paul V Ford-Hutchinson wrote:
> >Ricardo, all
> >
> >I think the issue is that the term "EDI" is not neutral and implicitly
> >conveys different concepts to different readers.  Those of us involved
> >with traditional VANs and their approach to EDI would consider "Secure
> >EDI" somewhat tautological.  We would also consider that EDI conveys a
> >certain business critical approach and requires externally auditable
> >mechanisms such as confidentiality, integrity, audit, archive, tracking,
> >verifiable receipts, reliable, timely delivery and possibly other services
> >such as data transformation.
> >
> >However, when two peer entites are trying to exchange an X.12 or EDIFACT
> >document, they can choose to implement as many of those mechanisms as
> >their needs require and with varying levels of external auditability.
> >Whilst still technically 'doing EDI' the EDI that they are doing is really
> >a new concept.  I think the easiest way to encapsulate that concept is to
> >name it "Peer-Peer EDI".
> >
> >Now, the EDI-INT working group has, by choice, limited itself to define
> >and solve the issues for "Peer-Peer EDI" only.  It has specifically
> >ignored the ability to provide the mechanisms above by trusted third
> >parties and has has specifically ignored the native EDI security
> >mechanisms.  This is perfectly acceptable, as long as it is clearly
> >understood that the recommendations and standards only apply to "Peer-Peer
> >EDI".
> >
> >Whilst it is clear that the proposals of the EDI-INT group do not address
> >all uses of EDI over the Internet, they do address a specific need and, as
> >such, are valuable as long as they are clearly identified as such.  The
> >current tiltles for the EDI-INT documents are all misleading as they imply
> >that this is _the_ way to do EDI over the Internet, whereas it is actually
> >only a way.  And, if I may say so, not an intuitive way for the vast
> >majority of EDI users today.
> >
> >Paul
> >
> >I still think AS1 needs most of the options to be removed though.  We as
> >engineers should be setting a low-watermark for what 'Secure Peer-Peer
> >EDI' means; if only to get the interoperability issues down to a managable
> >level and ensure a certain degree of security.
> >
> >--
> >Paul Ford-Hutchinson :  eCommerce application security :
> >paulfordh@xxxxxxxxxx
> >MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926
> >462005
> >http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
> >
> >
> >Ricardo Johnson wrote:
> >
> >
> >At 09:51 a.m. 19/11/01 -0500, The IESG wrote:
> > >To propose email based security protocols such as S/MIME as a "the
> > >standard" to be used for transmiting EDI messages over the internet is
> > >fundamentally wrong !. Before you advance any further with such a limited
> > >idea your group must evaluate other alternatives and give serious
> > >consideration to the work that has been done by the EDI standards bodies
> > >(ANSI X.12 and EDIFACT) on the matter of security.
> >
> >1. S/MIME is not even a standard for email yet, how can it be adopted as a
> >standard for EDI
> >2. Email protocols such as S/MIME protect entire envelopes not EDI
> >messages
> >or parts thereof. That means that security is dependent on the messaging
> >protocol. Thus messages can not be exchanged among different messaging
> >protocols such as X.400, EDI, and others.
> >3. EDI messages must be secured at the transaction level not the envelope
> >level, so that ISA headers can be read and messages be routed without
> >having to decrypt the message.
> >4. A message should be able to travel from sender A to receiver B
> >encrypted
> >and digitally signed regardless of the mailbox type, messaging protocol,
> >or
> >communications protocol (email, x.400, VAN, etc).
> >5. Security rules for EDI transactions (X 12.58 and EDIFACT) are well
> >defined and adopted standards. The EDI security rules been implemented and
> >proven worldwide (i.e. banks). They are concenced and efficient to handle
> >EDI messages. EDI security standards have obvious benefits over S/MIME.
> >Why
> >then re-invent the wheel ? Let EDI messages be handled by EDI security
> >standards and assure inter-operability (VAN-internet), simplicity
> >(authentication, non repudiation, key management, etc), and evolution (VAN
> >to ISP ?).
> >6. S/MIME is not a good email security protocol. It was simply not
> >conceived to handle EDI transactions and therefore is not well suited for
> >that.
> >
> >Before you conclude that S/MIME or any other protocol should be used as a
> >standard for sending EDI messages over the internet (EDIINT), you should
> >seriously evaluate X 12.58 and EDIFACT security rules as viable and
> >superior alternatives. The long term consequences of disregarding the
> >accomplishments and knowledge that the EDI standards bodies and users have
> >achieved in the security areas over the last 20 years would be a big
> >mistake !
> >
> >Give us the benefit of the doubt, allow us to demonstrate the advantages
> >of
> >EDI security protocols with practical and theoretical examples.
> >Respectfully
> >Dr. Ricardo S. Johnson
> >
> >
> >
> > >The IESG has received a request from the Electronic Data
> > >Interchange-Internet Integration Working Group to consider MIME-based
> > >Secure EDI <draft-ietf-ediint-as1-14.txt> as a Proposed Standard.
> > >
> > >In the same action, the IESG will also consider publication of
> > >  Requirements for Inter-operable Internet EDI
> > ><draft-ietf-ediint-req-09.txt> as an Informational RFC.
> > >
> > >The IESG plans to make a decision in the next few weeks, and solicits
> > >final comments on this action.  Please send any comments to the
> > >iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by December 3, 2001.
> > >
> > >Files can be obtained via
> > >http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-14.txt