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

At 08:30 AM 11/22/2001 -0800, Ricardo Johnson wrote:
>1. S/MIME is not even a standard for email yet, how can it be adopted as a 
>standard for EDI

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.


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

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.


>5. Security rules for EDI transactions (X 12.58 and EDIFACT) are well 
>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?


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

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 protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464