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

From: The IESG <[email-masked]>
Date: Mon, 19 Nov 2001 09:51:13 -0500

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: Ricardo Johnson <[email-masked]>
Date: Thu, 22 Nov 2001 08:30:49 -0800

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Nov 2001 15:57:06 -0800

>1. S/MIME is not even a standard for email yet, how can it be adopted as a 

All of the following specifications are standards track:

RFC2634
Enhanced Security Services for S/MIME P. Hoffman, Ed. June 1999 ASCII 
PROPOSED STANDARD RFC2633
S/MIME Version 3 Message Specification B. Ramsdell, Ed. June 1999 ASCII 
PROPOSED STANDARD RFC2632
S/MIME Version 3 Certificate Handling B. Ramsdell, Ed. June 1999 ASCII 
PROPOSED STANDARD

That status is entirely sufficient for use within other IETF protocols that 
are entering Proposed Standard status.  Hence, your assessment is incorrect.

>2. Email protocols such as S/MIME protect entire envelopes not EDI 
>messages or parts thereof.

S/MIME does not protect "envelopes".  The closest the Internet has to email 
envelopes is SMTP command parameters.

S/MIME protects MIME body-parts.  That is, after all, what the "MIME" in 
"S/MIME" means.

>having to decrypt the message.

There are many different types and levels of security.  No one solution 
fits all circumstances.

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

A laudable ideal.  Like most ideals in the world, it serves better as a 
goal than a practicality.

However, do feel free to pursue it, but please permit others to choose an 
easier, "intermediate" solution, until your goal is achieved.

>defined and adopted standards.

In some venues, but not in others.  Note that there would not have been a 
multi-year EDI security effort, in the IETF, if all portions of the EDI 
community agreed with your assessment.

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

In that case, the of EDI within S/MIME will fail, and you have nothing to 
worry about.

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

On the other hand, why not allow EDI to be carried and secured by the same 
mechanisms that carry many other documents?  Security technology is 
difficult and expensive.

Why should EDI have its own flavor of security, and be different from all 
other document carriage mechanisms?

>conceived to handle EDI transactions and therefore is not well suited for that.

Your assessment is notably lacking in details.  Especially given that 
others clearly disagree with both of your assessments, here, those details 
are required in order to evaluate your conclusions.

What are the deficiencies of S/MIME for email security?  What are the 
special requirements for EDI transaction security that S/MIME fails to satisfy?

d/

ps.  You did not mention PGP, although both your concerns and errors apply 
to it, as well.

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