Internet Security

[drickards@xxxxxxxxxxxx (Dale Rickards)]

Hi there,

I have been reading your e:mail discussions over the last month and I
thought it was time to express my views.

MY BACKGROUND....

I am female ... even though my name is Dale.

I worked for Sterling Commerce (formally Sterling Software) developing EDI
data security software for 4 years and have implemented both the X12.58 and
the X12.42 (version 3040 - prior to public key)  standards defined by ANSI
X12.  I have also been part of the work groups developing these standards
"X12-C committee Task group 6 - Data Security" and have been involved with
the public key changes made to the standards  ((just a note - I have
recently changed jobs but I am still active in data security))

I have also worked with IBM to interface their black-box security solution
into Sterlings EDI security software to provide a greater level of security.

During this time I worked closely with the banks in the U.S. to implement
security solutions for EDI.

E:MAIL VS EDI....  

I don't think that you can come up with the same solution for both E:Mail
(or other internet information) and EDI.  

EDI is exchanged between trading partners who have a trading partner
agreement and have identified what type of relationship they will have.
They have defined the transaction sets they will be exchanging and which
segments and elements they will be using.  When they use security, they will
still have a trading partner agreement which defines the relationship.
Banks are the only organizations who seem to be implementing EDI security
(although other companies are discussing it because the banks are forcing
them to).  The banks usually have a security officer who sets up security
ID's and defines key values (DES) and exchanges them with their trading
partners.  This will not change when using public key no matter which
algorithm they use because banks tend to be security nuts (for good reason).
This means that  the algorithm that EDI, sent though the internet, uses
should be flexible so that way these trading partners can choose the
algorithm that they feel comfortable with (ie. RSA, PGP etc).   The X12.58
standards allows for the use of may different types of algorithms for this
reason.  

Question:   If security is applied by an EDI security software/hardware
solution (ANSI or EDIFACT) prior to 
                    exchange on the internet  why do we need to worry about
adding more security in MIME?
                    Is there something I am missing?
 
E:Mail information will be sent to anyone, rather then just trading
partners, and should be more defined to allow you to send confidential
information without having to worry about the algorithm which was used.
According to your Charter this is not be decided in this work group.

I agree that we must be careful that nothing is proprietary.

ANSI X12 VS EDIFACT....

There has also been discussion in this group on the ANSI X12 vs EDIFACT
standards.  Does it matter which one is used?  If both standards allow for
different algorithms to be used then I do not see what the issue is.  Once
the EDI message has been secured and sent over the internet, then the
translator security product at the receivers site should be able to handle
the data prior to EDI translation.

The way the ANSI X12 standards work is that after the EDI transaction set
has been generated by the translator, security segments are imbedded into
the transaction set when security is applied (S1S/S2S/S1A/S2A).  These
security segments define what algorithm was used, if a session key was used
and the digital signature (with lots of other information... to long to type
in).

SECURITY IS STILL SLOW TO TAKE OFF...

I have found that security is still something that companies and people in
general have not thought about.  In Canada (where I live) one of the banks
is allowing customers to apply for loans over the internet.  They send all
their confidential information (i.e. home address, credit card numbers, how
much they make) to the bank using the internet and their credit application
will be processed and approved/denyed within 24 hours.

INTERNATIONAL SECURITY.....

International security is still something which needs to be addressed.  I
know that the U.S.government has a real issue about this.  The DES algorithm
is used world wide, although it cannot be exported in software (I am not
sure if it is only sold software) without approval from the U.S. government.
This approval must be obtained for each country you are sending the software
too.  Each approval costs approximately $10,000 and it can only be sent to a
financial organization in the approved country.  (I know this because I was
involved in this when I worked at Sterling).  The current gov't
adminstration in the U.S. was trying to setup a Certification Agency
(Nov/95)  which would maintain all private key values for all citizens in
the U.S.   That way they could break the encryption if they needed too.   


Thanks for you time... Dale