[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: An EDIINT Short Status/ Request
firstname.lastname@example.org.EDU.AU (David Chia) writes:
: Tom Darling <email@example.com> 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
: 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
- 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:firstname.lastname@example.org> Voice/Fax: 1-408-244-8410 1180 Reed Ave #51
<http://www.chage.com/chage/> Sunnyvale, CA 94086