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

From: Ricardo Johnson <[email-masked]>
Date: Sat, 24 Nov 2001 07:32:12 -0800

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 :
>[email-masked]
>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
> >[email-masked] or [email-masked] mailing lists by December 3, 2001.
> >
> >Files can be obtained via
> >http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-14.txt

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 Nov 2001 09:20:03 -0800

At 07:32 AM 11/24/2001 -0800, Ricardo Johnson wrote:
>archival, time stamping, tracking, and others.

Users of EDI are not a monolithic set.  Some require the third-party 
services of a VAN.  Others do not.  Some require very high degrees of 
accountability, sufficient for dispute resolution in a court of 
law.  Others do not.

>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.

In fact the EDI-INT specification does not force communications to be 
peer-to-peer.  It may be, but it may not be.

In a strict sense, the fact that it will tend to be email-based guarantees 
that it is not strictly peer-to-peer, since virtually all email is mediated 
by email relays.  It would not be difficult for one or more of those relays 
to also serve as an EDI VAN.

Your concern is that last-hop routing cannot be based on the EDI contents, 
unless the contents are first decrypted.  Your technical assessment is 
correct, but does not represent a problem with the current specification.

The issue of last-hop routing was discussed at the earliest IETF EDI 
meetings -- the EDI working group that preceded the current one -- and 
there was clear consensus to leave that issue outside of the scope the IETF 
effort.  Routing based on email address is sufficient.

If the sender wishes differential routing, they merely need to send to 
different email addresses.  If the receiving wishes differential routing, 
they must first decrypt the contents.  That decryption takes place within 
the security perimeter of the receiving organization.  Hence this 
requirement is entirely reasonable.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Alan DeRossett <[email-masked]>
Date: Thu, 29 Nov 2001 13:22:42 -0800

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.