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

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Wed, 21 Nov 2001 10:58:33 +0000

I have two comments:

1) Is there any disagreement to re-titling the document "MIME-based Secure 
Peer-Peer EDI" ?

2) There are too many options. 

Although the document lists 8 permutations, I can actually count 23.  One 
document defining 23 modes of operation is an interoperability nightmare.

And one of the ennumerated modes of operation in this "Secure EDI" 
document is "Sender sends un-encrypted data, does NOT request a receipt". 
How is this "Secure EDI" ?

Paul

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

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Wed, 21 Nov 2001 18:35:50 +0000

Greg Vesper wrote:
>'Secure EDI' is misleading for a spec that allows content types of 
> EDI, XML, binary..
>We do a lot of non-edi transactions using AS1 and AS2.  EDIINT is a
>misleading name..

Interesting, what MIME types do you identify your XML and Binary data by ?

Paul

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Thu, 22 Nov 2001 09:51:20 +0000

Greg Vesper wrote:
>AS2 accomodates XML content types.

This discussion is about AS1.  Now, if you are suggesting that AS1 should 
be delayed until it is brought in line with AS2 ......

>EDI is a way of doing business that encompasses more than just X12 and
>EDIFACT documents.

That's as maybe, AS1 doesn't define how they should interoperate though.

BTW, I'm still not sure what point you are trying to make.  Was it 
anything to do with the issues I raised ? 

With apologies to the tech. folks on this list,  reading the AS1 document 
reads like a licence to Market and not a technical description of an 
interoperable mode of operations.  Heck, according to this, telnet to port 
25 is AS1 compliant.

Paul

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Fri, 23 Nov 2001 10:58:35 +0000

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.

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: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Mon, 26 Nov 2001 10:00:17 +0000

Please remember, on this point, I am not saying AS-1 is bad; I am saying 
that the document title should reflect the narrowed scope of 
applicability.

Dave Crocker wrote:
>At 07:32 AM 11/24/2001 -0800, Ricardo Johnson wrote:
>>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.
>
>Users of EDI are not a monolithic set. 

I think that's what I was trying to say.

>Some require the third-party services of a VAN. 

And these users are excluded by design from the EDI-INT proposals.

>Others do not.  Some require very high degrees of
>accountability, sufficient for dispute resolution in a court of
>law.  Others do not.

But they are all doing EDI.  My problem is that the EDI-INT group has 
reduced the applicability of its' solution to such a degree that it cannot 
claim to be "How to do EDI over the Internet".  As a corollary, if I were 
trying to deploy protocols to 'do' EDI over the Internet in my environment 
(using 3rd party VAN services - by far the largest slice of the EDI pie 
today), AS-1 would not be a useful starting point.

>
>>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.
>
>In fact the EDI-INT specification does not force communications to be
>peer-to-peer.  It may be, but it may not be.

Oh, dear - my fault - I replaced one implicit meaning-laden term (EDI) 
with another (Peer-Peer).  In my defence, I would claim that this is the 
fault of EDI, by putting routing information at the application layer.  To 
my mind "Peer-Peer EDI" can only possibly mean "Peer application to Peer 
application", the ins and outs of the journey of the packets of bits are 
inconsequential.  Any suggestions for a better term ?

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

It would be impossible for those relays to serve as an EDI VAN.  They 
could be an SMTP VAN; let's not get into a "what's the difference between 
EDI and email" debate please.

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

I'm interested in what is 'last-hop' about EDI routing ?  Surely the point 
of defining routing information is for it to be available throughout the 
journey of the message.  If you encrypt it between the application 
end-points - it has gone.

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

Nobody is arguing that AS-1 does not solve the problem as specified.  What 
I am arguing is that the problem that you are solving is not general EDI 
over the Internet, but has had its' scope reduced to such a degree as to 
be inapplicable to the way EDI is done today by the vast majority of EDI 
users.

>If the sender wishes differential routing, they merely need to send to
>different email addresses. 

Agreed one _can_ layer all sorts of conventions and OOB mechanisms onto 
this spec to make it generally useful.  But I thought the whole point of a 
protocol spec was to define the conventions, not skirt around them.

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

Fine, but that assumes the receiver is the EDI Peer to the sender and not 
an application/transport layer third party.  An acceptable assumption, but 
not one that is true for traditional, VAN based, EDI.

Paul

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Mon, 26 Nov 2001 10:00:17 +0000

with
AS1

guarantees
mediated
relays

contents,

IETF

Paul