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

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


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