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

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