Re: An EDIINT Short Status/ Request

[carl@xxxxxxxxx (Carl Hage)]

rsedc@urgento.gse.rmit.EDU.AU (David Chia) writes:
: Tom Darling <tdarling@albany.net> writes:
: >  When we leave PGP behind, one
: > clear problem (for me, probably not for someone competent) on the
: > DOS/Windows side is the lack of encryption engines in the form of callable
: > subroutines. I confess, I am a low-life sinner

I believe PGP (and DOS PGP) uses RSAREF. RSA has a couple of developers
toolkit software packages for encryption. The S/MIME vendors probably all
use this. I don't know the royalty and licensing requirements with this
software, and this seems to be information that is not available and
must be negitoated. There is a $1-$3 or 1%-3% patent royalty required, depending on
which algorithms are used.

PGP uses the IDEA algorithm with a noncommercial license. I believe there
is only a single supplier of the commercial version. I wonder if PGP3
will truely be free of patent and licensing problems.

: Eric Young from Australia has written a library suite of crypto routines
: SSLeay and it is free even for commercial exploitations. You have to
: sort out the appropriate RSA licencing required yourself.

For fun reading see:
   The Neverending Saga of Deploying a Free SSL Compliant Web Server
   URL: http://petrified.cic.net/~altitude/ssl/ssl.saga.html 

: Let me throw in another red herring. Is there a case for picking and choosing
: from the Mastercard/Visa SET spec for encryption algorithms, certificate
: format, procedures, etc, and glue them to the internet EDI requirements?
: Then EDI and EFT could be streamlined.

The existing Internet RFCs cover more than 95% of the requirements,
whereas SET would require more than 95% of the spec to be modified.

I don't think SET is applicable or useful as a basis for an EDI standard
for the following reasons:
  - SET duplicates many standard functions of Internet RFCs in different
    ways
  - SET is heavily tied to specific 3 way credit card transactions between
    customer, merchant, and bank-gateway. The message structure itself is
    tied directly to the process of a credit card transaction.
  - SET is not layered in a way that separates credit card specific
    transactions from secure transport, reliability, and non-repudiation.
  - SET is a complex binary (ASN.1) format that can't be integrated
    with other MIME/RFC822 standards.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086