headers
Dave Darnell | 2 Jul 1996 14:27

Re: EDI on the Internet

Diana,

You are welcome.  Thanks for your kind comments!

>Thank you ... this was one of the best explanations of the problems (and
>solutions) for EDI on the Internet I have seen!  It's very hard to get clear
>information on this subject, since often folks tend to get rather emotional
>about their opinion.

Diana, you state in a later message:

>> Orin Rehorst
>
>> Perhaps you are correct. But if you are correct, then are we ready to do EDI
>> over the Internet? It seems to me there must be a open standard, with the
>> possible exception of a fee paid to the firm whose encryption STANDARD we
>> use (not their software).
>
>I agree 100%.  And I don't think we're ready ... yet.
>

I do think that many are ready.  I just completed teaching 3 seminars in
June for EDI WORLD on EDI over the Internet and I saw an extremely high
level of interest from companies from all levels.  Why are they interested?
One company in my last seminar is paying VAN fees exceeding $400,000 per
month, another over $100,000, others over $10,000.  There is a huge
immediate benefit (right through to the bottom line) to implementing
Internet EDI if companies can achieve security and reliability -- I believe
this is not only possible, but being done by a large growing number of
companies.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 2 Jul 1996 14:27

Re: EDI on the Internet

Hi Tom,

You are right, since S/MIME does not have AUTACK then any package other than
Templar will not have this feature - "proprietary" because only Premenos has
chosen to implement it.

We have talked about a couple of problems (through the ietf-ediint list)
with S/MIME that many will find unacceptable:  digital signature unprotected
by the encryption envelope and small bit lengths on the encryption keys (on
export version).  Anybody can check the digital signature of a S/MIME
message by trying public keys until they hit the right one.  And the export
limitations on the encryption software limit the bit lengths of the
encryption keys to a level easily susceptible to "brute-force attack".

I hope anybody, especially in the international community, will consider
using PGP for encryption and digital signature with FTP or SMTP/MIME or HTTP
for transport.  

Why could PGP be better?  You can get a legal international version of PGP
(see http://www.ifi.uio.no/~staalesc/PGP/  )
and not worry about export violations - if you are outside the USA. And PGP
wraps the digital signature up in the encryption envelope for protection.  

And PGP offers up to 2048 bits on the public key and 128 bits on the
symmetrical (private) key algorithm, IDEA. This level of encryption is
considered very very safe against brute force attack.

If you use PGP with FTP then you automatically get a Non-repudiation of
Receipt through FTP (a virtual direct connect) logging and do not have to
worry about the AUTACK functionality in the SMTP based transport.  A
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 2 Jul 1996 14:27

Re: EDI on the Internet

Hi Orin,

You are right about Templar's current version, however, since I just talked
to some the Premenos people at the Montreal ietf, their next release will be
S/MIME compatible, so it should talk to any software that is S/MIME
compatible - e.g. Deming, ConnectSoft, NorTel Entrust, etc.  

Interoperability testing has not been completed (as far as I know), so do
not count on this until proof is presented, but at least it appears EDI on
the Internet is heading in the right direction here.

Just a note of advice - before committing to the Templar product you should
evaluate other approaches like PGP/MIME, FTP of encrypted files, HTTP
transfer using SSL, etc.  

Regards,
dave_d

At 10:26 AM 6/29/96 -0500, Orin Rehorst wrote:
>Beware of proprietary software! I believe Premenos software must be used by
each
>of the companies, limiting the spread of EDI over the Internet.
>
>>Hello Everybody :
>>
>>We are leading an EDI on the Internet national project in Costa Rica. The
>>porpuse is connect 20 companies over the Internet using the Templar software
>>of Premenos. If you know something about this product, any reference or
>>experience on this kind of solution for EDI, please send us a message, we
>>will apreciate your help on the project.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 2 Jul 1996 14:27

Re: X12 TS 841 for Document Delivery

Darren and Paul,

If you try to move the 841 through a VAN I hate to think of the magnitude of
your VAN costs.  IMHO - the internet offers the best and least expensive
transport for the 841.  You could secure the document with PGP or some other
encryption software (encrypt and digitally sign).  A digital signature would
provide authentication, non-repudiation of origin, and integrity with the
encryption providing confidentiality.

I hope you will consider the Internet before sending the 841 through a VAN.

Regards,
dave_d

At 10:34 PM 6/28/96 GMT, Paul McGhee wrote:
>"<Darren G. Ross" <DarrenMan <at> AOL.COM> wrote:
>
>>Is anyone using the transaction set 841 (X12) for document delivery ? I am
>>interested in details as to what type of documents (MS Word, Excel,
>>WordPerfect, etc.), any file size limitations, whether or not the files are
>>attachments, typical VAN costs for transmission / storage, and so forth. If
>>anyone is using this ts for a similar purpose, I would really appreciate any
>>feedback on the issue.
>
>The federal government is using the 841 to transmit technical drawings
>and other graphical elements associated with requests for proposals.
>I'm not sure of the format they're using. It's not something common,
>like TIFF or JPEG. That would make too much sense, I guess.
>
>There are two problems we've run into so far: the first is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 2 Jul 1996 16:02

Report for EDIINT WG / Project Stages

MEMO
DATE:        2-Jul-96
FROM:       Rik Drummond, The Drummond Group
SUBJECT:  Report for EDIINT WG / Project Stages

The trip consisted of four events with respect to the EDIINT workgroup:

(1) Attendance of the RECEIPT WG to discuss how we can "adjust/extend" the
current draft and receive guidance on direction for our construction of the
"signed-read-receipt" --   in essence the Non-repudiation of Receipt. We
gave a short presentation showing different ways we could use the
specification to accomplish our goals. Feedback was lively and well
conceived. We also had lunch with the editor and chairperson of the WG. The
results are:

(a) We requested (they have not committed) to add a new header field that
allows one to request responses such as read receipts, signed receipts,
delivery notifications and signed delivery notifications. At this time
there is no way to request any of this in an obvious manner.

(b) We Chuck Shih, Mats Jansson and I spent several hours defining a
structure for a content-type= multipart/report; report-type=
signed-receipt. It is based on RFC1847, RFC1892 and the current RECEIPTS
draft. We will propose three alternatives and let the RECEITPS workgroup
and our Area Chairs suggest the most appropriate one.  (AUTOACK may also be
appropriate for our purposes.)

(2) A working session with Chuck, Mats and I to define the (1b) above.

(3) A dinner so that the workgroup contributors could meet and discuss the
(Continue reading)

Permalink | Reply | 1 comment |
headers
RANDY_VANDENBRINK | 3 Jul 1996 17:03
Picon

(unknown)

Item Subject: cc:Mail Text
     Rik,

       I'm having problems with your attachment. Does this file exist on 
     the server and if so can you give me the reference.

     Thanks,

     Randy VandenBrink  
     vandenbr <at> corp.hp.com

     
     ______________________________ Reply Separator 
     _________________________________
     Subject: EDIINT Starting Discussion new edim fields
     Author:  Non-HP-drummond (drummond <at> onramp.net) at HP-PaloAlto,mime1
     Date:    7/3/96 7:50 AM

     
     Now is time to start the discussion on the EDIINT list for the need 
     for the additiona fields you all requested about a month ago. Please 
     direct the stuff to ietf-ediint <at> imc.org.  I have attached your 
     document to this message.

     Thanks for waiting until after the IETF meeting last 
     week.....later....rik
Permalink | Reply | 0 comments |
headers
Laurence Lundblade | 3 Jul 1996 20:38

How to sign receipts

I'm sort of new to EDI and receipts, but have been around the crypto stuff
and attended some of the EDI and receipts stuff. I have a proposal that may
solve the problem of the top level MIME type for signed receipts.  This is
an addition to RFC-1847 and solves the generic problem of figuring out what
is signed or encrypted without parsing the MIME signature formatting or
decrypting and parsing the encryption formatting. So it is not specific to
multipart/report at all, which I think is of significant value. The basic
rationale is the same for having the protocol parameter and, if anyone is
familiar, they type parameter in the multipart/related draft. It also has
some value added in the you can now disclose the MIME type of encrypted
data without disclosing the data itself if you wish to do so. The following
text could be added to RFC-1847.

--------------------------------------------
In section 2.1 and 2.2 near the beginning change:
    (4) Optional parameters: none
to
    (4) Optional parameters: content

Later in these sections a few paragraphs down add the following paragraph:

    The content parameter gives the MIME type and subtype of the actual signed
    or encrypted data. The parameter's value is expressed exactly like the
    protocol parameter, i.e.,

        parameter := "content" "=" value
        value := <"> type "/" subtype <">

    The type in this parameter is the type of data in the first part of a
    multipart/signed entity. For multipart/encrypted, it is the type of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 4 Jul 1996 17:40

Re: EDI on the Internet

Hi Dave and Steve,

I agree with Dave -- the is how I understand the time-stamp should work.
What good is a time stamp if it relies on the system time (which could be
set wrongly at any time or date) of the originator of the receipt?

Our Internet EDI receipt needs the third party digitally signed time stamp.

Question:  Is this another service Verisign is going to pick up?  Or maybe
the USPS?

Regards,
dave_d

At 10:00 PM 7/3/96 -0700, Dave Crocker wrote:
>At 5:59 PM -0700 7/3/96, Steve Botts wrote:
>>The AUTACK message, which is implemeneted in Templar, contains the time
>>stamps we're looking for.  I hope some of you will have a look at this
>>message, because
>
>        I haven't checked this thoroughly with hard-core security geeks,
>but my understanding is the the down-and-dirty non-repudiation function
>requires that the time-stamp come from an independent source.  I gather
>that the signature of the document and the signature of the timestamp are
>combined somehow to form a non-forgeable proof of the timing of the
>transfer.
>
>d/
>
>--------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rik Drummond | 5 Jul 1996 15:33

Re: EDI on the Internet

If you expect this dialogue to make it into the EDIINT WG stuff...Copy the
EDIINT list in the discussion.

Why is the third party time stamp so important in the EDI signed receipt
Dave Darnell -- at least over the short term?  These parties are already
doing business in some sort of a trusted relationship. Is not the a
document signed by both contractual parties enough? I can see the third
party is very important when an existing relationship is not in place --but
people do not normally notarize contracts

For our interoperabiltiy needs, in the EDIINT WG, over the short term
(couple of years) I do not see the third party timestamp as important. What
does the rest of the WG think.

Later...Rik

P.S. Nice job James.

At 11:55 PM 7/4/96, James Pottmyer wrote:
>Dave,
>  With a public-key crypto system to provide digital signature capability, it
>is possible to use one party's system time iff:
>  1) all parties to a "contract" are on-line at their information appliances
>or else are represented by agent processes that are nearly always present in a
>network.
>  2) parties promptly exchange with one another digitally signed messages that
>include identities of parties, their nonces, a "time stamp" generated by one
>party that is validated and agreed to by others,  and a digest of the other
>agreed content of the transaction.  (There is no reason today for anybody who
>cares about the time to deviate by as much as a second from the true time with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Darnell | 5 Jul 1996 16:00

Re: EDI on the Internet

Hi Rik,

I see your point, and it probably is not a big issue in the short term.  

But as EDI grows to meet the needs of the 6 million plus small to medium
sized enterprises we need to start thinking of EDI transactions being
ubiquitous as credit card transactions.  If EDI reaches that point then
there will be a definite need for third party certification authorities and
time stamps.

Does anybody know what the PKIX work group has done along these lines?
Again, this is probably not something we need to worry about today, but it
would be nice to know what PKIX thinks about this and contribute our EDI
recommendations to that group.

Regards,
dave_d

At 08:33 AM 7/5/96 -0500, Rik Drummond wrote:
>If you expect this dialogue to make it into the EDIINT WG stuff...Copy the
>EDIINT list in the discussion.
>
>Why is the third party time stamp so important in the EDI signed receipt
>Dave Darnell -- at least over the short term?  These parties are already
>doing business in some sort of a trusted relationship. Is not the a
>document signed by both contractual parties enough? I can see the third
>party is very important when an existing relationship is not in place --but
>people do not normally notarize contracts
>
>For our interoperabiltiy needs, in the EDIINT WG, over the short term
(Continue reading)

Permalink | Reply | 2 comments |

Gmane