EDIINT Functional Specification July 1996
EDIINT Working Group Chuck Shih
Internet Draft Mats Jansson
Expires: 12/96 Rik Drummond
Lincoln Yarbrough
Requirements for Inter-operable Internet EDI
Please direct comments to drummond@onramp.net.
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts are draft documents
valid for a maximum of six months and may be updated,
replaced, or made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work
in progress."
To learn the current status of any Internet-Draft,
please check the "1id-abstracts.txt" listing contained
in the Internet-Drafts Shadow Directories on
ftp.is.co.za (Africa), nic.nordu.net (Europe),
unnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Any questions, comments, and reports of defects or
ambiguities in this specification may be sent to the
mailing list for the EDIINT working group of the IETF,
using the address <ietf-ediint@imc.org>. Requests to
subscribe to the mailing list should be addressed to
<ietf-ediint-request@imc.org>.
Abstract
This memo is an informational document discussing the
requirements for inter-operable EDI, with sufficient
background material to give an explanation for the EDI
community of the Internet-related issues.
Table of Contents
1.0 INTRODUCTION 4
1.1 THE AUDIENCE 4
2.0 THE INTERNET - A BRIEF HISTORY 5
2.1. THE INTERNET - MYTHS AND REALITY 6
2.2 INTERNET ROUTING 7
3.0 FUNCTIONAL REQUIREMENTS 9
3.1 INTRODUCTION AND DEFINITIONS 9
3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE
ENCRYPTION. 9
3.2.1 INTRODUCTION AND DESCRIPTION 9
3.2.2 SYMMETRIC ENCRYPTION 10
3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 10
3.2.4 NEEDS 11
3.2.5 ISSUES 11
3.2.6 SOME RECOMMENDED ENCRYPTION ALGORITHMS 11
3.3 KEY MANAGEMENT - SYMMETRIC KEYS 13
3.3.1 INTRODUCTION AND DESCRIPTION 13
3.3.2 NEEDS 15
3.3.3 ISSUES 15
3.3.4 RECOMMENDATION 15
3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 16
3.4.1 INTRODUCTION AND DESCRIPTION 16
3.4.2 PUBLIC KEYS 16
3.4.3 NEEDS 16
3.4.4 ISSUES 16
3.4.5 RECOMMENDATIONS 16
3.5 CONTENT INTEGRITY 17
3.5.1 INTRODUCTION AND DESCRIPTION 17
3.5.2 NEEDS 18
3.5.3 ISSUES 18
3.5.4 RECOMMENDATIONS 18
3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 18
3.6.1 INTRODUCTION AND DESCRIPTION 18
3.6.2 NEEDS 19
3.6.4 EDITOR'S RECOMMENDATIONS 20
3.7 SECTION: SIGNED RECEIPT OR NON REPUDIATION OF RECEIPT20
3.7.1 INTRODUCTION AND DESCRIPTION 20
3.7.2 NEEDS 21
3.7.3 RECOMMENDATIONS 21
3.8 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 22
3.8.1 INTRODUCTION AND DESCRIPTION 22
3.8.2 GATEWAY FUNCTIONS 22
3.9 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC
SERVICES 22
3.9.1 INTRODUCTION AND DESCRIPTION 22
3.9.2 NEEDS 22
3.9.3 ISSUES 23
3.9.4 RECOMMENDATION 23
4.0 TRACKING AND ERROR HANDLING BASICS 23
4.1 INTRODUCTION 23
4.2 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED FROM
INTERNAL FORMAT TO STANDARD EDI FORMAT 24
4.2.1 NEED 24
4.2.2 RECOMMENDATIONS 24
4.3 SECTION: TRANSMISSION SUCCESSFULLY ENCRYPTED, SIGNED
AND SENT 24
4.3.1 NEED 24
4.3.2 RECOMMENDATIONS 25
4.4 SECTION: TRANSMISSION SUCCESSFULLY RECEIVED 25
4.4.1 NEED 25
4.4.2 RECOMMENDATIONS 25
4.5 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED BY
RECEIVER 25
4.5.1 NEED 25
4.5.2 RECOMMENDATIONS 25
4.6 DETECTION AND RECOVERY OF DELAYED OR LOST
TRANSMISSIONS 25
4.6.1 NEED 25
4.6.2 RECOMMENDATIONS 26
4.7 DETECTION AND HANDLING OF DUPLICATE TRANSMISSIONS 26
4.7.1 NEED 26
APPENDIX A - A CONPARISON OF SECURITY PROTOCOLS 27
1.0 Introduction
Electronic Data Interchange (EDI) is a set of protocols
for conducting highly structured inter-organization
exchanges, such as for making purchases or initiating
loan requests. The initial RFC1767 defined the method
for packaging EDI X12 and UN/EDIFACT transaction sets in
a MIME envelope. However, several additional
requirements for obtaining multi-vendor, inter-operable
service, over and above how the EDI transactions are
packaged, have come to light since the effort concluded.
These currently revolve around security issues such as
EDI transaction integrity, confidentiality and non-
repudiation in various forms. Additional requirements
that mimic many of the heading fields found in X.435 EDI
messages (e.g., Interchange Sender, Interchange
Recipient, Interchange Control Reference, Communications
Agreement ID, and Syntax Identifier) are also needed to
support efficient exchanges by gateways and Value Added
Networks. Standards in these and other areas are
necessary to ensure inter-operability between EDI
packages over the Internet. Various technologies already
exist for these additional features and the primary
requirement is to review and select a common set of
components for use by the EDI community when it sends
EDI over the Internet. In effect, the effort is to
provide an EDI over the Internet Informational Document
and an Applicability Statement Document.
This document's current focus is on EDI MIME content
transported using SMTP (Simple Mail Transport Protocol),
the Internet's mail or messaging system.
Traditional VAN connectivity is slow and expensive. The
Internet promises lower cost usage and is more easily
accessible than traditional methods of communications.
The predominant problem with the use of the Internet
for EDI is interoperability between vendor products,
specifically in the areas of integrity, confidentiality,
signature, and non-repudiation. The EDIINT working
group's focus is to recommend solutions for each of
these areas using existing standards whenever possible.
1.1 The Audience
The audience for this document consists of persons
directly or indirectly involved in EDI communications
decisions, companies trading EDI documents today or in
the future, and vendors developing and marketing EDI
products. Also included in the audience for this
document, are people providing services and consulting
to the EDI community.
2.0 The Internet - A Brief History
The Internet is a world-wide collection of computers,
routers, and networks, connected together using the
TCP/IP suite of protocols. The Internet itself is not a
network, but a collection of networks. The Internet was
designed to be decentralized, with no single authority
needed to run it. All hosts on the Internet can
communicate with one another as peers, and all of the
communications protocols are "open" -- the standards are
in the public domain, and the standardization process is
open to anyone willing to put in the hard work to help
define them.
One consequence of this standards "openness" is that the
Internet can accommodate many different kinds of
machines (toasters for example). Its protocols -- the
TCP/IP suite - have therefore become the de facto
standards for heterogeneous computer networking. At one
level, the Internet is a physical collection of
computers connected by common protocols. At another
level though, the Internet can be thought of as a
distributed medium, offering some important advantages
for doing EDI: for instance, the Internet has hundreds
of thousands of connected global hosts, and tens of
millions of users. The Internet offers a flat rate,
volume and time-of-day independent pricing structure for
data transmission. The Internet is highly redundant,
offering the ability to route data along alternate
paths. The Internet's decentralized structure makes
adding new hosts relatively easy -- it scales well and
supports high bandwidth communications technologies.
2.1. The Internet - Myths and Reality
The Internet had its beginnings in 1969 as an
experimental U.S. Defense Department network called
ARPANET. The network was built to facilitate research on
how to construct networks that could withstand outages
to part of the network, but continue to function.
Network reliability was a fundamental design point when
developing the architecture and protocols associated
with the Internet. From the premise that the network was
inherently unreliable (parts of it could be destroyed at
any moment) emerged a design that was both robust and
reliable. Early on, the networks comprising the
Internet were primarily those from government agencies
and educational institutions. Access to the Internet was
pretty much available only to computer science
researchers, and government employees and their
contractors.
In 1986, the National Science Foundation, in order to
provide access to what was then a scarce resource, put
together an initiative to link five super-computer
centers together using the TCP/IP protocols. Two very
important results of the NSFNET initiative were the
upgrading of the Internet's infrastructure with ever
more powerful processors and higher speed links, and
expansion of access to a larger user community. The
1990's has seen the continual upgrading of the Internet
infrastructure and its expansion to new constituencies
outside the traditional government and university
research community. Commercial interests are now the
largest as well as the fastest growing segment of the
Internet.
Commercial Internet providers, such as Performance
Systems International (PSI), and UUNET (the Alternet
network), have emerged from the collection of
intermediate-level networks that came into being as a
result of the NSFNET initiative. The national long
distance carriers such as MCI, AT&T, and Sprint all
provide commercial Internet services. These commercial
providers, called Internet Service Providers or ISPs for
short, make available Internet connectivity and various
other Internet services to their clients. The perception
of the Internet as experimental, and primarily used by
and for educational and research activities is
rooted in its past, and does not reflect today's
situation. The growth in commercial access to the
Internet, along with the growth of the ISPs, is
radically changing the Internet's network composition.
The design and architecture underlying the Internet has
proven its robustness by scaling to unprecedented
proportions. The Internet is reliable from several
perspectives:
(1) Technologically, the TCP/IP suite of protocols and
the architecture underlying the Internet are stable and
mature.
(2) Product implementations based on the TCP/IP suite
are also stable and mature.
(3) Internet routing is dynamic, so packets sent through
the Internet get to their destinations even if there are
network outages along the way.
(4) The commercial ISP administered portions of the
Internet, provide essentially the same level of network
reliability, availability, monitoring, throughput,
implementation and support services as existing EDI
Value Added Networks (VANS), but at a lower cost and
with higher bandwidth.
Although the Internet is reliable, low-cost, highly
accessible, supports high bandwidth communications, and
is technically mature, there are still some valid
concerns relating to the use of the Internet for EDI.
These concerns revolve primarily around security,
message tracking, audit trails, and authorization. Some
of the concerns, encryption for instance, are of a
general nature and not specific to the Internet--
encryption may be required regardless of what type of
network is traversed. Other concerns, such as tracking,
arise because they are required by EDI, and supported by
existing EDI Value Added Networks.
2.2 Internet Routing
By using a common network trace program called
Traceroute, the route traversed by a packet from a
source host to a destination host on the Internet may be
followed. Tracing routes on the Internet yield some
interesting characteristics. As expected, the routes
traversed go through the networks administered by the
ISPs of each of the trading partners. Each route
consists of multiple nodes through each network. The
route can vary but that is not the typical case. The IP
packets are delivered reliably, and within a specified
period of time. When a reputable commercial ISP is used,
none of the nodes in the route are administered by
government or educational entities.
By looking at Internet network traces, we can conclude
that the Internet does a very good job of getting
packets from a source to destination. However, between
the source and the destination, the packets are routed
through many intermediate nodes. It is at the
intermediate nodes where anyone on one of the machines
that handles the packets can re-assemble the packets
that make up the EDI Interchange and can read it, copy
it, alter it, or delete it. In the case where the EDI
Interchange is carried using an e-mail transport (SMTP),
the situation could arise where the message cannot be
delivered to the final recipient and the message must
be stored at the intermediate node. Once again, the
message is susceptible to any number of security
threats.
The likelihood of security attacks, (especially if going
through intermediate nodes administered by a quality
ISP) are quite low, and practically speaking, may be
quite difficult. Nonetheless, since the possibility
exists, it is a concern - particularly if the packets
contain high value or sensitive EDI, or electronic
commerce transactions.
The Internet is being singled out in this discussion
because our focus is EDI over the Internet, but the
possibility of security threats and administrative
glitches exist even if the EDI Interchanges go through
an EDI VAN. It really is a matter of management of the
machines that make up the intermediate nodes in any
network that is at issue. There are measures that can
be taken to defend against security concerns while an
EDI interchange is in transit. These security measures
are essential requirements when doing EDI over the
Internet. Each of the security measures is described,
issues are discussed, and recommended solutions given.
3.0 Functional Requirements
3.1 Introduction and Definitions
The following sections describe the functional and
inter-operability requirements, as well as some of the
practical considerations of sending and receiving EDI
transactions on the Internet. It is assumed that the
reader is generally familiar with EDI.
3.2 Standard Encryption Algorithms and World-Wide
Encryption.
3.2.1 Introduction and Description
The goal of encryption is to turn otherwise readable
text into something that cannot be read, and therefore
understood. By making the text unintelligible,
encryption discourages anyone from reading or copying
the EDI Interchange while it is in transit between the
trading partners. Encryption conveys confidentiality to
the EDI Interchange. Traffic analysis is always
possible, since many times, header information is not
encrypted. (Traffic analysis is the analysis of header
information in order to derive useful information from
it)
Encryption is based on two components: an algorithm and
a key. An algorithm is a mathematical transformation
that takes plain-text or other intelligible information
and changes it into unintelligible cipher text. The
inverse mathematical transformation, back to the
original from the cipher text is also done, and is
called decryption. In order to encrypt the plain text, a
key is used as input in conjunction with an encryption
algorithm. An algorithm can use one of any of a large
number of possible keys. The number of possible keys
each algorithm can support depends on the number of bits
in the key. For instance, if the key length is 40, then
2 to the n, where n is the number of bits in the key,
results in 1,000,000,000,000 possible key combinations,
with each different key causing the algorithm to produce
slightly different cipher output.
An encryption algorithm is considered secure if its
security is dependent only on the length of its key.
Security cannot be dependent on the secrecy of the
algorithm, the inaccessibility of the cipher or plain
text, or anything else--except the key length. If this
were true about a particular algorithm, then the most
efficient -- and only -- attack on that algorithm is a
brute-force attack, whereby all key combinations must
be tried in order to find the one correct key (this is
true for symmetric encryption algorithms, asymmetric
algorithms work a little differently, and are explained
in greater detail later). So, by specifying a long
enough key length n, even a brute-force attack on a
secure algorithm can be made completely non-feasible.
3.2.2 Symmetric Encryption
Encryption algorithms whereby two trading partners must
use the identical key to encrypt and decrypt the EDI
Interchange are called symmetric encryption algorithms.
Put another way, if an EDI Interchange is encrypted with
one key, it cannot be decrypted with a different key.
The key used in most symmetric encryption algorithms is
just a random bit string, n bits long. These keys are
often generated from random data derived from the source
computer.
The use of symmetric encryption simplifies the
encryption process, each trading partner does not need
to develop and exchange secret encryption algorithms
with one another (which incidentally would be a near
impossible task). Instead, each trading partner can use
the same encryption algorithm, and only exchange the
shared, secret key.
There are drawbacks however with symmetric encryption
schemes; a shared secret key must be agreed upon by both
parties. If a trading partner has n trading
relationships then n secret keys must be maintained,
one for each trading partner. Symmetric encryption
schemes also have the problem that origin or destination
authenticity (non-repudiation of origin, delivery and
receipt) cannot be proved. Since both parties share the
secret encryption key, any EDI Interchange encrypted
with a symmetric key, could have been sent by either of
the trading partners. By using what is called public key
cryptography, which makes use of asymmetric encryption
algorithms, the non-repudiation of origin, delivery and
non-repudiation of receipt issues can be solved.
3.2.3 Asymmetric Encryption - Public-key Cryptography
Public-key cryptography is based on the concept of a key
pair. Each half of the pair (one key) can encrypt
information that only the other half (one key) can
decrypt. The key pair is designated and associated to
one, and only one, trading partner. One part of the key
pair (the private key) is only known by the designated
trading partner; the other part of the key pair (the
public key) is published widely but is still
associated with the designated trading partner.
The keys are used in different ways for confidentiality
and digital signature. Both confidentiality and
signature depend on each entity having a key pair that
is identified only with them and each party keeping one
pair of their key pair secret from all others.
Signature works as follows: Trading Partner A uses her
secret key to encrypt part of a message, then sends the
encrypted message to Trading Partner B. B gets Trading
partner A's public key (anyone may get it) and attempts
to decrypt the encrypted part of Trading partner A's
message. If it decrypts, then Trading Partner B knows it
is from A--because only A's public key can decrypt a
message encrypted with A's private key, and A is the
only one who knows her private key.
Confidentiality applies the asymmetric key pair, but in
a different manner than signature. If Trading partner A
wishes to send a confidential message to Trading Partner
B she would apply the key pair as follows: Trading
partner A would retrieve Trading partner B's public key,
and encrypt the message with it. When Trading Partner B
receives the message, she would decrypt the message
with her private key. Only her private key can decrypt
information that was encrypted with her public key. In
other words, anything encrypted with B's public key can
only be decrypted with B's private key.
Since public-key encryption algorithms are considerably
slower than their symmetric key cousins, they are
generally not used to do the actual encryption of what
could be large EDI Interchanges. For instance, RSA Data
Securities, Inc. estimates that software encryption
using DES (a symmetric key algorithm) is 100 times
faster than software encryption using RSA (a public-key
encryption algorithm from RSA Data Securities, Inc.).
Hardware encryption using DES is anywhere from 1,000 to
10,000 times faster than hardware encryption using the
RSA asymmetric encryption algorithm. Instead of being
used for bulk encryption, public-key encryption
algorithms are used to encrypt symmetric encryption
keys. They are also used as an efficient means of
exchanging and managing symmetric encryption keys.
3.2.4 Needs
In order to provide confidentiality for EDI Interchanges
on the Internet, a standard encryption algorithm(s) and
key length(s) must be specified. For inter-operability
to occur between two trading partners, the encryption
algorithm and key lengths must be agreed upon either
before hand or within an individual transaction.
3.2.5 Issues
* When choosing an encryption algorithm, the following
criteria should be considered; how secure the algorithm
is; how fast implementations of the algorithm are; the
availability of the algorithms for international as well
as domestic use; the availability of APIs and tool kits
in order to implement the algorithms; and the frequency
of the use of the algorithm in existing
implementations.
* Sufficient key lengths must be chosen with regard to
the value of the EDI Interchange so that brute-force
attacks are not worth the time or effort compared to the
value of the Interchange.
3.2.6 Some Recommended Encryption Algorithms
DES: The most widely used commercial encryption
algorithm is DES. It is widely used in the banking
industry for Electronic Funds Transfer (EFT). DES is
also a U.S. government encryption standard. DES is in
the public domain, which means anyone can implement the
algorithm, including those in the international
community. DES was designed for, and is used for bulk
encryption of data. DES is prohibited by the U.S.
government for export.
The DES algorithm has been analyzed by cryptographers
since the mid-1970s, and is considered secure: in other
words, the security of DES is completely dependent on
the length of its key. DES specifies a 56 bit key, so 2
to the 56th or 10 to the 16th keys are possible. A
brute force attack, which means trying every single key
to decrypt 8 bytes of known cipher-text into its
corresponding 8 bytes of known plain-text is the best
attack on the algorithm.
The amount of time and money required to mount a
successful brute force attack varies with the processing
power used - and how lucky the attacker may be in
generating a key that is close to the one used to
encrypt the original EDI Interchange. Some estimates
which have been put forth claim that a $1 million dollar
hardware based, brute-force attack on DES would take 3.6
hours to recover the DES key. A corresponding $1
million dollar software based brute-force attack on DES
would however take 3 years. As the price/performance of
processors decrease, a 56 bit key becomes less and less
adequate in protecting EDI Interchanges of extreme
value. Triple-DES, an algorithm with longer key length
(discussed below) should be used in such cases.
Triple-DES is a variant on DES that encrypts the EDI
Interchange 3 times, with 2 independent 56 bit keys,
giving it an effective key length of 112 bits. This
makes a brute-force attack on Triple-DES not feasible.
DES and Triple-DES actually can be implemented in 3
different modes. It is recommended that DES and Triple-
DES be used in Cipher Block Chaining (CBC) mode, which
gives added protection by making each cipher-text block
depend on each other, so changes in the cipher-text can
be detected.
RC2 and RC4: RC2 and RC4 are proprietary symmetric
algorithms of RSA Data Security. RC2 and RC4 unlike DES
are variable-key length algorithms. By specifying
differing key lengths, RC2 and RC4 can be configured to
provide greater or lesser security. RC2 and RC4 are
alternatives to DES and have special export status,
whereby 40 bit versions of RC2 and RC4, and 56 bit
versions for foreign subsidiaries and overseas offices
of U.S. companies have expedited export approval from
the U.S. government. RSA claims that RC2 and RC4 are
faster than DES when implemented in software. Several e-
mail products such as Lotus Notes and Apple's Open
Collaboration Environment make use of these algorithms.
It is recommended that a key length of at least 128 bits
be used when using RC2 and RC4. A key length of 128
bits would make a brute-force attack impossible now and
for the foreseeable future.
IDEA: The International Data Encryption Algorithm was
published in 1991. The symmetric algorithm is an
iterated block cipher with a 64-bit block size and a 128-
bit key size. The key length of IDEA is over twice that
of DES and is longer than triple-DES. The IDEA algorithm
is patented in both the United States and abroad. The
IDEA algorithm in CBC mode is used by PGP (Pretty Good
Privacy - a popular electronic mail security program)
for encryption. Individual users of PGP have a royalty
free license to use the IDEA algorithm.
There are many encryption algorithms that are secure and
can provide confidentiality for an EDI Interchange. For
interchanges that carry less value, 40-bit RC2 or 56-bit
DES are probably adequate. For more valuable
interchanges, use of Triple-DES, IDEA, or longer key
length RC2 or RC4 is recommended.
DES is currently in wide-spread use, and Triple-DES is
projected to be in wide-spread use, as the 56-bit DES
key limitation becomes less and less adequate. The DES
algorithm is available for implementation outside the
U.S., and the DES algorithm has been studied for a long
time, and has been found to be secure. RC2 and RC4 are
useful because they allow the security of the
encryption - the key length specification, to be
configurable. (the RC2 and RC4 algorithms are
proprietary, they can be exported outside the U.S. IDEA
is a newer algorithm and has not been studied as much as
DES. It has an adequate key-length, though it is not
configurable. Indications are that IDEA is a secure
algorithm and its use in PGP makes it the most widely
used encryption algorithm for Internet electronic mail.
3.3 Key Management - Symmetric Keys
3.3.1 Introduction and Description
The use of symmetric encryption is based on a shared
secret. Two trading partners using a symmetric
encryption algorithm must be able to do the following;
generate a random symmetric key and agree upon its use;
securely exchange the symmetric key with one another;
set up a process to invalidate a symmetric key that has
been compromised or needs changing. Each trading partner
would then need to do this with each and every one of
their trading partners. Management and distribution of
symmetric keys can become an insecure and cumbersome
process.
Pure symmetric key management schemes also have the
problem that origin authenticity cannot be proved. Since
two parties share a secret encryption key, any EDI
Interchange encrypted with a symmetric key, could have
been sent by either of the trading partners who have
knowledge of the key.
Using public-key cryptography, the management of
symmetric keys is simplified and made more secure.
Trading partners do not need to agree on secret
symmetric keys as part of the trading partner
relationship. Public-key cryptography also solves the
origin authenticity problem that pure symmetric key
management schemes have.
By generating a unique symmetric encryption key for each
EDI Interchange, and using public key cryptography,
trading partners no longer need to secretly agree on a
shared symmetric key in the trading partner
relationship. A symmetric key can be randomly generated
by the software for each EDI Interchange between trading
partners. Since a unique symmetric key is generated for
each EDI Interchange, key maintenance is not needed.
Trading partners do not need to invalidate compromised
or expired keys. Each symmetric key is used only one
time.
Additional security is also realized using the method
described above; in the unlikely event that one of the
symmetric keys is compromised, only one EDI transaction
is affected, and not every transaction in the trading
partner relationship. Public-key encryption also
provides a secure way of distributing symmetric keys
between trading partners. Since only the receiving
trading partner has knowledge of her private asymmetric
key, she is the only one that can decrypt the symmetric
key encrypted with her public asymmetric key - and is
thus the only one who can use the symmetric key to
decrypt the EDI Interchange.
To impart confidentiality to an EDI Interchange which
trading partner ABC sends to trading partner XYZ, the
following steps would be performed:
1) The EDI Translator outputs the EDI Interchange.
2) A random symmetric key of the specified length
is generated.
3) The EDI Interchange is encrypted using the
randomly generated symmetric key with the chosen
encryption algorithm.
4) The random symmetric key is then encrypted
using 5) XYZ's, the destination's, public
asymmetric key.
The encrypted symmetric key and encrypted EDI
Interchange are then enveloped and sent to the
trading partner.
On the receiving side, the following steps would be
performed:
1) The symmetric key is decrypted using XYZ's
private asymmetric key.
2) The decrypted symmetric key is then used to
decrypt the EDI Interchange.
3) The decrypted EDI Interchange is then routed to
the EDI translator.
3.3.2 Needs
A method to manage the symmetric encryption keys used in
encrypting EDI Interchanges. The method should simplify
the generation, maintenance, and distribution of the
symmetric encryption keys. The method should also
provide a secure channel for distributing the symmetric
encryption keys between trading partners.
3.3.3 Issues
* Choose a public-key encryption algorithm that
facilitates key management of the symmetric
encryption keys. The symmetric encryption keys
should be generated on the fly for each EDI
Interchange.
* When choosing a public-key encryption algorithm,
the following criteria should be considered; how
secure the algorithm is; how fast implementations
of the algorithm are; the availability of the
algorithms for international as well as domestic
use; the availability of APIs and tool kits in
order to implement the algorithms; and the
frequency of the use of the algorithm in
existing implementations.
* Sufficient key lengths must be chosen with
regard to the value of the EDI Interchange so that
brute-force attacks are not worth the time or
effort compared to the value of the Interchange.
3.3.4 Recommendation
1) RSA is a public-key cryptography algorithm that has
become a de facto standard in its use for key
management. Its use is recommended in managing and
distributing symmetric encryption keys when doing EDI
over the Internet. The RSA public-key algorithm also
has the advantage that it can be used freely outside the
U.S.
2) The mathematics of RSA are complicated, but is based
on the difficulty in factoring large prime numbers. A
public-key is generated by multiplying two large prime
numbers together, deriving the private key from the
public key involves factoring the large prime number. If
the prime is large enough, this becomes an impossible
task. The RSA key length is configurable, and is
recommended to be at least 512 bits (154 digits long),
and preferably 1024 bits (or 308 digits long) or longer.
3.4 Key Management - Public and Private Keys
3.4.1 Introduction and Description
The use of public-key cryptography to simplify the
management of the symmetric encryption keys presents the
user with two problems; protecting the private key, and
binding a trading partner's identity to his public key.
Most likely the user will never know what his private
key is. The software will generate a random private key,
encrypt it, and store it in a file or database. The
private key is accessed indirectly by the user through
access to the software. User access to the software is
generally controlled by a password, pass-phrase, and/or
certain access rights. These are internal security
policies, and are company specific. It is important to
control the access to the private key since any
unauthorized access can lead eventually to the
revocation of the corresponding public key.
3.4.2 Public Keys
A public key is used by a originating trading partner
to encrypt a symmetric key, and as we'll discuss later,
by a receiving trading partner to do authentication and
non-repudiation of origin and receipt. Trading partners
exchange public keys using a public key certificate.
A public key certificate is defined in the X.509
standards, and is a binding of an entity's
distinguished name (a formal way for identifying someone
or something in the X.500 world, in our case it would be
a trading partner) to a public key. A certificate also
contains the digital signature of the issuer of the
certificate, the identity of the issuer of the
certificate, and an issuer specific serial number, a
validity period for the certificate, and information to
verify the issuer's digital signature. Certificate
issuers are called Certification Authorities, and are
trusted by both trading partners. In essence, a
certificate is a digitally notarized binding of trading
partner to public key.
3.4.3 Needs
Adoption of a trust model and use of Certification
Authorities for verifying public key certificates.
3.4.4 Issues
Lack of Certification Authorities. To date only Verisign
has stepped forward as a Certification Authority. The
U.S. Postal Service is interested in becoming a
Certification Authority but is in the process of
implementing the services.
3.4.5 Recommendations
Since there already exists a trust relationship between
EDI trading partners, until Certification Authorities
become more prevalent, and the formats and protocols for
interacting with Certification Authorities become
standardized, it is recommended that the trading
partners self-certify each other and exchange public
keys as part of the trading partner relationship. The
self-certified certificate should still be exchanged
between trading partners in X.509 v3 format, so
migration to exchange of notarized certificates is made
easier.
Since the formats and protocols for use in registering,
requesting, and revoking certificates have not been
standardized, the use of PCKS #10 and S/MIME is one
recommendation. Also, PGP with its circle of trust is
another valid option. We recommend that S/MIME be
tested for interoperability first, and that PGP v3.0 be
tested later. Implementation of the standards for
Certification Authority interactions being developed by
the IETF-pkix (public-key infrastructure X.509) work
group should eventually be adopted.
3.5 Content Integrity
3.5.1 Introduction and Description
Encryption guarantees the confidentiality of an EDI
Interchange. Content integrity guarantees that the
receiving trading partner gets the EDI Interchange in
its originally sent state. Content integrity assures
that no modifications - additions, deletions, or changes
- have been made to the EDI Interchange when it is in
transit between trading partners.
Content integrity is achieved if the sender includes
with the EDI Interchange, an integrity control value.
This value can be computed by using an appropriate
cryptographic algorithm to 'fingerprint' the EDI
Interchange. These cryptographic algorithms are called
one-way hash functions or message integrity checks.
Similar to encryption, a one-way hash function turns the
EDI intelligible plain-text into something
unintelligible.
Unlike encryption algorithms however, one-way hash
functions can't be decrypted. One-way hash functions
are constructed so the probability is infinitely small
that some arbitrary length piece of plain-text can be
hashed to a particular value, or that any two pieces of
plain-text can be hashed to the same value. One-way hash
values are usually from 112 to 160 bits long. The
longer the hash value, the more secure it is.
One-way hash functions don't require a key, and the
algorithm used must be agreed upon by the trading
partners. To insure content integrity, the sending
trading partner needs to calculate a one-way hash value
of the EDI Interchange. This value is unique and
'fingerprints' the EDI Interchange. The sending trading
partner sends the hash value along with the EDI
Interchange. The receiving trading partner using the
same one-way hash function calculates the hash value for
the received EDI Interchange. If the received hash value
matches the calculated hash value, then the receiving
trading partner knows that the EDI Interchange has not
been tampered with.
3.5.2 Needs
Choice of a one-way hash algorithm to calculate the hash
value required to insure content integrity.
3.5.3 Issues
The one-way hash algorithm should be secure, publicly
available, and should produce hash values of at least
128 bits.
3.5.4 Recommendations
MD5 is a one-way hash function that is publicly
available, produces a 128 bit hash value called a
Message Digest. It is widely used or recommended by most
e-mail security programs and specifications, such as
PEM, PGP, and S/MIME.
3.6 Authentication and Non-Repudiation of Origin
3.6.1 Introduction and Description
Encryption guarantees confidentiality. Applying a one-
way hash function guarantees content integrity. Both
authentication and non-repudiation of origin guarantee
the identity of the sender of the EDI Interchange. Non-
repudiation of origin, identifies the original sender,
and is the same as authentication when the EDI
Interchange is sent point-to-point, i.e. when there is
no forwarding involved. Authentication and non-
repudiation of origin discourages any spoofing attacks
that may occur while the EDI Interchange is in transit
between the trading partners.
Both authentication and non-repudiation of origin are
accomplished using digital signatures. A digital
signature is another application of public-key
cryptography, and is explained in more detail in the
following paragraphs.
Up to this point, a receiving trading partner's public-
key has been used to encrypt a symmetric key, and this
symmetric key could only be decrypted by the receiving
trading partner's private key. However the roles of the
private and public keys can be reversed, so that you
encrypt with the private key, and decrypt with the
public key. Again the keys are reciprocal, if encryption
is done with the private key, decryption can only be
done with the public key.
Since only trading partner ABC knows her own private-
key, only trading partner ABC can encrypt something with
that private-key. Encryption with a private key
therefore has the effect of uniquely identifying the
person or entity doing the encryption. It is in effect,
a digital signature. Since ABC's public-key is known to
all his trading partners, they can all decrypt something
encrypted with ABC's private-key. Decryption using ABC's
public-key therefore has the effect of authenticating
ABC as the trading partner that did the encryption, and
it in effect verifies ABC's digital signature. ABC also
cannot say that he did not do the encryption, since he
is the only one with knowledge of his private key. In
this way, non-repudiation of origin is achieved.
So what should a trading partner sign or encrypt with
his private-key to guarantee authentication and non-
repudiation of origin? Remember, public-key encryption
algorithms are not meant to encrypt something very
large, they are too slow for that. The symmetric key is
encrypted with a public-key, and encrypting this with a
private-key is not recommended, as this would allow
other than the authorized recipient to decrypt the EDI
Interchange. Since a one-way hash value is pretty small,
usually only between 112-160 bits long, it is a natural
choice for what can be digitally signed. If the message
integrity value was signed with a private key, then not
only could authentication and non-repudiation of origin
be guaranteed, but message integrity as well.
3.6.2 Needs
Choice of a digital signature algorithm.
3.6.3 Issues
When choosing a digital signature algorithm, the
following criteria should be considered; how secure the
algorithm is; how fast implementations of the algorithm
are; the availability of the algorithms for
international as well as domestic use; the availability
of APIs and tool kits in order to implement the
algorithms; and the frequency of the use of the
algorithm in existing implementations.
Sufficient key lengths must be chosen with regard to the
value of the EDI Interchange so that brute-force attacks
are not worth the time or effort compared to the value
of the Interchange.
3.6.4 Editor's Recommendations
In addition to using RSA to encrypt keys, it is
recommended that RSA also be used for digital
signatures. Again, the RSA algorithm has the advantage
that it can be used freely outside the U.S.
3.7 Section: Signed Receipt or Non Repudiation of Receipt
3.7.1 Introduction and Description
The signed receipt (or alternately Non Repudiation of
Receipt), is a receipt acknowledgment sent by the
receiving trading partner to the sending trading partner.
The receipt is used to solve the following issues when
doing EDI over the Internet:
* Lack of mailbox delivery notification within the
Internet standards, though these are currently
being addressed within RFCs 1891-1894.
* Provide the equivalent of VAN mailbox delivery
notification.
* Provide the equivalent of VAN mailbox pick-up
notification.
* Provide the equivalent of VAN mailbox
authentication.
* Detect the situation where EDI Interchanges are
maliciously deleted, or are not delivered by the
transport.
Receipt of a signed receipt is an implicit
acknowledgment of successful mailbox delivery. It is
also an explicit acknowledgment that the Interchange was
retrieved from the mailbox--pick-up notification. By
having the receiver sign the receipt, it authenticates
that the intended receiver picked up the EDI Interchange-
-mailbox authentication--and that the intended receiver
verified the integrity of the EDI Interchange, and the
identity of the sender. By returning the original one-
way hash value (or original message) back in the signed
receipt, the sender can reconcile the acknowledged EDI
Interchange with what was sent.
3.7.2 Needs
Define the format and protocol for the signed receipt
so that it provides the following:
* Implicit acknowledgment of mailbox delivery of
the EDI Interchange to the recipient.
* Explicit acknowledgment that the receiver has
authenticated the sender and verified the
integrity of the sent EDI Interchange.
* Guarantees non-repudiation of receipt when the
receipt acknowledgment is digitally signed by the
receiving trading partner.
* Provide information in the signed receipt so
it can be used for tracking, logging, and
reconciliation purposes.
The re-transmission timer, and retry count to detect
lost Interchanges should be recommended, but needs to be
configurable. Additionally, it should be specified what
the receiver should do when it receives duplicate
Interchanges, and what the sender should do when it
receives duplicate receipt acknowledgments. The signed
receipt should be applicable to more than just EDI.
3.7.3 Recommendations
The syntax for a signed receipt should not be specific
to EDI, since many of the uses of a signed receipt can
be broadly applied to other MIME encapsulated objects.
It is recommended that the results of the IETF receipt
working group be adopted for use as a signed receipt.
The receipt working group has published an Internet
draft--draft-ietf-receipt-mdn-01--which can be obtained
off of the IETF World Wide Web site. The EDIINT working
group is working with the receipt working group to
specify additional disposition-field values, as well as
specification of how the MDN (message disposition
notification) should be used within an EDI environment.
Specifically, within an EDI environment, requests for
message disposition requests cannot be silently
ignored. In addition, if non-repudiation of receipt is
agreed to by the trading partners, the original message
sent must be returned in the third component of the
message disposition notification--digitally signed by
the receiver of the EDI Interchange. The time-out and
retry values for the message disposition notification
should be recommended, but needs to be configurable.
Duplicates should be checked by the UA and discarded.
Until the receipt Internet draft is complete, a
combination of RFC1847 and draft-ietf-receipts-mdn
should be used to implement this functionality
3.8 EDI Object Boundaries and Transaction Privacy
3.8.1 Introduction and Description
The specification by this work group applies to the EDI
Interchange level, and not the group or document level.
Any security services, packaging, transport, or non-
repudiation services are assumed to be applied to an EDI
Interchange. Unlike the X12.58 and UN/EDIFACT 9735-5 and
9735-6 security standards, the security services cannot
be applied at a group or document level. The purpose of
the specification is to move these services out of the
translator, and into the "communications" subsystem. The
"communications" subsystem should know as little about
the structure of the EDI data as possible.
The entire EDI Interchange including the enveloping
headers (ISA/IEA or UNA/UNB/UNZ) are also encrypted.
Since the routing of the EDI Interchange is through the
Internet, and not a VAN, the sender/receiver ids are not
used in mailbox routing, so the EDI envelops can be
encrypted when sending EDI over the Internet.
Only one EDI Interchange is sent per e-mail message.
3.8.2 Gateway Functions
Situations exist whereby a VAN, or internal gateway, in
order to route an EDI Interchange received on the
Internet, will need to be able to access the information
in the EDI envelope. The enveloping information as well
as other useful gateway information may need to be
copied and sent as a separate body part. It is proposed
that additional fields be specified in RFC 1767 to
accommodate EDI specific gateway routing requirements,
and this be sent as a separate body part from the
encrypted EDI Interchange.
3.9 Syntax and Protocol for Specifying Cryptographic
Services
3.9.1 Introduction and Description
Once cryptographic services are applied to EDI
Interchanges, then the formats and protocols must be
specified on how the cryptographic information is
conveyed during the EDI message exchange. Encryption
algorithm information, one-way hash algorithm
information, symmetric keys, initialization vectors, one-
way hash values, public-key certificates, need to be
enveloped and sent along with the EDI Interchange.
3.9.2 Needs
Syntax and protocol for specifying EDI Interchanges that
have had cryptography applied to it. Choose an existing
standard and don't reinvent one.
3.9.3 Issues
The syntax should be transport independent so it can be
used with different Internet transports. The standard
should have broad support, and implementations should be
available. Finally it should be international in nature.
3.9.4 Recommendation
The IETF EDIINT working group has put together a matrix
comparing many of the different ways that EDI with
cryptography applied to it can be transmitted. The use
of S/MIME and PGP/MIME (version 3.0 with the elkins
draft) are both viable alternatives. Each has its
strengths and weaknesses as the comparison matrix brings
out.
The S/MIME specification allows signed, and encrypted
and signed to be distinguished. The signatories in an
S/MIME encrypted and signed message can be
distinguished, which in certain EDI and electronic
commerce situations is not acceptable. S/MIME specifies
40 bit RC2 as the default encryption algorithm and key
length. In some applications neither this default
algorithm or key length are acceptable. S/MIME can
accommodate other security algorithms and key lengths
such as those recommended in section 3.3.2 however.
PGP/MIME supports a set profile of security algorithms
and some user configurable key lengths. PGP/MIME does
not have the signatory problem as described above for
S/MIME. However, PGP/MIME does not give the user as much
flexibility in choosing algorithms and key lengths,
although the security profile used by PGP/MIME is more
than adequate to insure confidentiality, non-repudiation
of origin, and message integrity.
4.0 Tracking and Error Handling Basics
4.1 Introduction
It's important to recognize that traditional EDI via
Value Added Networks have some inherent tracking
mechanisms, that we have to either duplicate in Internet
EDI, or decide we don't need. In Internet EDI, there is
no third party to call to track a transmission after it
has left one company, and before it has been received by
the second company. Also, the move from VAN based EDI
to Internet EDI changes the connectivity in other ways.
From a more batch oriented store-and-forward technology
to a more event driven routing technology.
Aside from the communications between companies,
"tracking" touches many other points within the trading
companies. This is where the use of 997 functional
acknowledgments come in, the EDIFACT CONTRL message, and
the common translator tracking of sequential group
control numbers. All of this needs to be considered in
Internet EDI tracking. In addition, some recent
developments within S/MIME warrant some analysis--
"positive acknowledgment", which refers to mail response
not just if the delivery failed, but also if it
succeeded.
What tracking information do we really need, and where
does the UA have a role in providing it?
1) Transmission successfully translated from
internal format to EDI standard format
2) Transmission successfully encrypted and sent
(The equivalence of transmission successfully
forwarded to receiver's VAN mailbox.)
3) Transmission successfully received by the
intended receiver and successfully decrypted (The
equivalence of a VAN acknowledgment that sent
transmission has been picked up by the receiver.)
4) Transmission successfully translated by the
receiver (the EDI Interchange was determined to be
syntactically correct.)
5) Detection and recovery of delayed or lost
transmissions.
6) Detection and handling of duplicate
transmissions.
7) Detection and handling of out-of-sequence
transmissions.
The question of what the UA needs to track as compared
to what the EDI translator tracks is addressed in the
following sections.
Needs, issues and recommendations will be discussed.
4.2 Section: Transmission successfully translated from
internal format to standard EDI format
4.2.1 Need
There needs to be a facility by which a sender can
assure that the EDI transmission was correctly
translated and prepared for outbound transmission.
4.2.2 Recommendations
This is standard functionality for most if not all EDI
translators. This should NOT be required functionality
in the UA.
4.3 Section: Transmission successfully encrypted, signed and
sent
4.3.1 Need
There needs to be a facility by which a sender can be
assured that an EDI transmission was successfully
encrypted, signed, and sent.
4.3.2 Recommendations
* This should be required functionality of the UA.
* The UA needs to be able to identify the transmission
by its interchange control #, AND a user defined value,
if desired.
4.4 Section: Transmission successfully received
4.4.1 Need
There needs to be a facility by which a sender of a
transmission can be assured that the transmission was
correctly received by the intended receiver.
4.4.2 Recommendations
1) The UA should track this, and provide the sender with
signed receipts.
2) The use of the MDN (message disposition notification)
as described in Section 3.7.3, according to the Internet
draft by Roger Fajman
3) Note: This could theoretically be accomplished by
using a 997 in place of the NRR, however, it's our
recommendation to not do that for two reasons:
* The implied success of the receiver's decryption
through the receipt of a legible 997, binds the
certificate to a control ID only (997) and not to
the actual data (NRR).
* Translators are very different, and we feel this
RFC should define interoperability between UA's
only, and still cover all angles.
4.5 Section: Transmission successfully translated by
receiver
4.5.1 Need
There needs to be a facility for the sender to be
assured that the receiver could "understand" (in EDI
terms) the transmission.
4.5.2 Recommendations
This should NOT be tracked by the UA, following our
recommendation for object boundaries
The Functional acknowledgment 997, and the EDIFACT
CONTRL serve this exact purpose - this should be tracked
by the EDI translator.
4.6 Detection and recovery of delayed or lost transmissions
4.6.1 Need
There needs to be a facility by which a sender can
detect sent transmissions that have not been
acknowledged as correctly received, by a specified,
configurable, period of time, and be able to configure
actions accordingly.
4.6.2 Recommendations
1) The use of time stamps for each of the two events:
* MIME message sent.
* Signed Receipt received.
2) The ability to automatically detect transmissions
that have failed the time trigger.
3) The ability to configure automatic actions based on
failure. Actions may include:
* Re-transmit. If re-transmitted, the receiving
UA needs to be able to detect the second
transmission as a duplicate and discard it (more
on this below).
* Alert/Report.
* Ignore/delete (this option may be chosen by
someone that has decided to track only at the EDI
translator level through 997/CONTRL.
4.7 Detection and handling of duplicate transmissions
4.7.1 Need
There needs to be a facility by which a receiver of EDI
transmissions is able to detect different types of
duplicate transmissions, and handle them the way they
should be handled. First, translator initiated
duplicates should NOT be halted in any way - we should
assume that translators will handle that level. In
other words, there should be no checking of ISA control
numbers by the UA. Secondly, the use of a re-
transmission feature in attempts to deliver
transmissions quickly, should allow for a UA to identify
duplicate transmissions generated by the sending UA, and
discard of duplicate transmissions after the first has
been received.
4.7.1 Need
The ability to pass through translator initiated re-
transmissions to the receiving translator without a
hitch. This means EDI related control numbers, such as
the ISA control number, should not be checked by the UA.
Appendix A - A Comparison of Security Protocols
Version: 3.0
Date: July 18, 1996
Sources:
EDIINT- EDI over Internet, Internet Mail Consortium Workshop
data, Chuck Shih, Steve Dusse', David Darnell, Kent
Landfield, David Chia, Rik Drummond, Jeff Cook, Alan Cox,
Raph Levien, Russ Housley, and many others.
1) Exportable Out Side Of The USA
------------------------------------
PGP V3.0
* PGP is already outside the USA and except for
countries that prohibit encrypted messages with long
key lengths (instead of just restricting the import of
long key length algorithms) PGP long key lengths
messages can be read This is included in the PGP
ViaCrypt documentation:
* No since the encryption algorithm specified is IDEA.
S/MIME
* Has the 40 and 56 bit export restrictions if RC2 or
RC4 is used for encryption
MOSS
* Not with full key length
* Depends on the data encryption algorithm used. RFC
1423 specifies DES in CBC mode, which is not
exportable. Moss however allows the use of variety of
cryptographic algorithms.
MSP
* Depends on the key management and data encryption
algorithm used. MSP allows the use of variety of
cryptographic algorithms.
2) Easily Integrated Into Products In A User Transparent
Manner
------------------------------------------------------------
PGP V3.0
* Maybe in V.30. Not in earlier versions
* There seems to be general disagreement on this one
S/MIME
* Yes
MOSS
* Do not know
MSP
* Yes. Support for signed receipts may require GUI
enhancements.
3) Fully Compatible With Like Versions World Wide
-----------------------------------------------------
PGP V3.0
* PGP version 2.6 is compatible with any earlier
versions. Version 3.0 should be also.
S/MIME
* RSA has an active interoperability program in place
* Implementations to the spec should guarantee
interoperability.
MOSS
* Moss does not require any particular security
algorithm. Moss provides the means to identify which
algorithms are used for each message. A suite of
algorithms is defined in RFC 1423.
MSP
* Implementations to the spec should guarantee
interoperability when the same cryptography is used.
4) Current Implementation Status
----------------------------------
PGP V3.0
* Version 3.0 is out 3Q96
* Version 2.6 is available
* Qualcomm
* Premail
* Michael's PGPMIME
S/MIME
* Two companies have implemented several others have
committed
* Product is shipping
MOSS
* TIS, Innosoft and SupplyTech
MSP
* SPYRUS, Nortel, Xerox, LJL, BBN, and J. G. Van Dyke
all have implementations.
* Product is shipping.
* In use for Military messages.
5) Confidentiality
------------------
PGP V3.0
* YesS/MIME * YesMOSS
* Yes
MSP
* Yes
6) Signature
------------
PGP V3.0
* Yes
S/MIME
* Yes
MOSS
* Yes
MSP
* Yes
7) Return Receipt
------------------
PGP V3.0
* Via MIME extensions RFC1891-94
S/MIME
* Via MIME extensions RFC1891-94
MOSS
* Via MIME extensions RFC1891-94
MSP
* Yes.; supports non-repudiation with proof of delivery.
8) Delivery Notification
-------------------------
PGP V3.0
* Via MIME extensions RFC1891-94
S/MIME
* Via MIME extensions RFC1891-94
MOSS
* Via MIME extensions RFC1891-94
MSP
* Via MIME extensions RFC1891-94
9) Authentication
-----------------
PGP V3.0
* Yes
S/MIME
* Yes
MOSS
* Yes
MSP
* Yes
10) Multimedia
--------------
PGP V3.0
* Yes
S/MIME
*Yes
MOSS
* Yes
MSP
* Yes
11) Integrity
-------------
PGP V3.0
* Yes
S/MIME
* Yes
MOSS
* Yes
MSP
* Yes
12) Trust Model (Key Management & Revocation)
-------------------------------------------------
PGP V3.0 * PGP 3.0 will have hierarchical model of public-key
certificates
* RSA used for key management in current versions
* Ad hoc key revocation.
S/MIME
* RSA based using X.509 all versions.
* NT's Entrust will be usable with this product very
soon.
MOSS
* Both RSA and DES based key management.
MSP
* X.509 all versions.
13) Certificate (Information, Format, Distribution)
------------------------------------------------------
PGP V3.0
* Yes using proprietary "Key rings". Not clear what V3
will use
S/MIME
* Yes using X.509 -all versions
MOSS
* Yes with optional X.509
MSP
* Yes using X.509
14) Infrastructure Overhead
----------------------------
PGP V3.0
* Base 64 encoding
S/MIME
* ASN.1 - BER and DER encoding
* Base 64 encoding
MOSS
* Base 64 encoding
MSP
* Base64 encoding and ASN.1 encoding
15) Envelope Type
------------------
PGP V3.0
* MIME/ ASCII
S/MIME
* PKCS #7 ASN.1 and MIME
MOSS
* MIME/ ASCII
MSP
* MIME /ASN.1
16) Envelope / Structure Components (ASN1 Or ASCII)
-------------------------------------------------------
PGP V3.0
* ASCII
S/MIME
* ASN.1and ASCII
MOSS
* ASCII
MSP
* ASN.1
17) Algorithms Supported (List Them: Encryption, Key
Management, One Way Hash, Digital Signature, Key Lengths
For Encryption)
------------------------------------------------------------
-
PGP V3.0
* RSA and IDEA in pre 3.0
* Diffie Hellman and DSA in Ver. 3.0
* I DEA in CBC
* MD5 & RSA
* A 384 for casual grade, 512 commercial grade, 2048
military grade
* A 128 bit IDEA key length
S/MIME
* RSA
* RC2 / RC5
* MD5 & RSA
* SHA-V
* Note: S/MIME like Moss is a format and allows any type
of algorithm to be specified. RSA of course specifies
their own algorithms
* Triple-DES/RC5
MOSS
* DES in CBC
* RSA or DES
* MD2/MD5 and RSA
* A 56 bit key lengths for DES
* FORTEZZA
* Note: Moss like S/MIME allows a variety of
cryptographic algorithms to be used. The suite of
algorithms defined above are found in RFC 1423.
MSP
* Algorithm independent. Implementations exist using:
* RSA & DES
* FORTEZZA (DSS SHA-1, KEA, Skipjack)
18) Common Algorithms With EDIFACT AUTACK List Of Codes
-----------------------------------------------------------
PGP V3.0
* RSA (yes)
* IDEA (yes)
* DH (?)
* DSA (yes)
* MD5 (yes)
S/MIME
* RSA (yes)
* RC2 and RC4 (yes)
* DES (yes)
* MD5 (yes)
MOSS
* RSA (yes)
* DES (yes)
* MD5 (yes)
MSP
* RSA (yes)
* DES (yes)
* MD5 (yes)
* DSS (yes)
* SHA-1 (yes)
19) Coexistence With Others For Reception (signature not
readable) Of MIME Multipart/Signed Data
------------------------------------------------------------
PGP V3.0
* Yes V3.0
S/MIME
* Yes, but user selectable
MOSS
* Yes
MSP
* Yes, if used with MIME encapsulation (see <draft-
housley-msp-mime-01.txt>
20) Signed Message Body Readable By RFC822/ MIME Readers
------------------------------------------------------------
-
PGP V3.0
* Should be in V3.0
S/MIME
* Yes - if one of the options multipart/signed is used
* Verify with RSA is it multipart/alternative and not
/signed?
MOSS
* Yes
MSP
* Yes, if used with MIME encapsulation
21) Signature Separate From Signed Document
----------------------------------------------
PGP V3.0
* Yes
S/MIME
* Yes, optional
* Verify with RSA
MOSS
* Yes
MSP
* Yes
22) Backward Compatibility
---------------------------
PGP V3.0
* To PGP
S/MIME
* To PEM
MOSS
* To PEM
MSP
* No
23) Uses Proprietary Algorithms?
---------------------------------
PGP V3.0
* Ver 3.0 will use Diffie-Hellman with expiring patents
in 1997. Ver 3.0 will use DSA (Digital Signature
Algorithm invented at the NSA)
S/MIME
* Yes
MOSS
* YES, but it supports different options in a coherent
manner.
MSP
* It supports both standard (FIPS and X9) as well as
proprietary algorithms.
24) Adequate Security For EDI Purposes
-----------------------------------------
PGP V3.0
* Yes
S/MIME
* Yes. However one can tell the difference between an
encrypted message and a signed/encrypted message.
There is not consensus as to if this is a problem or
not.
MOSS
* Yes
MSP
* Yes
25) Scaleable
-------------
PGP V3.0
* No enough experience to tell. The current trust model
will not scale well.
S/MIME
* No enough experience to tell
MOSS
* No enough experience to tell
MSP
* Yes
26) Solid Mime Integration
---------------------------
PGP V3.0
* V3.0 -yes
S/MIME
* Yes - but it mixes PKCS technology with MIME. Internet
purest do not seem to like the mix.
MOSS
* Yes
MSP
* Yes (see <draft-housley-msp-mime-01.txt>
27) Variable Key Sizes Supported
----------------------------------
PGP V3.0
S/MIME
* Yes, 40- 128 bit
* Symmetric 512-2048 bit RSA
MOSS
MSP
* Yes
* Symmetric (DES = 56 bits; SKIPJACK = 80 bits)
* Signature (DSS = 512 .. 1024 bits; RSA = 512 .. 2048
bits)
* Key Management (KEA = 1024 bits; RSA = 512 .. 2048
bits)
28) Only X.509 Or Other Certificate Distribution Methods
------------------------------------------------------------
PGP V3.0
S/MIME
* X.509 any version
MOSS
MSP
* X.509 any version
29) Very Solid API And Took Kit
---------------------------------
PGP V3.0
* V3.0 Yes - anticipated
S/MIME
* Yes
MOSS
* No
MSP
* Yes. DISA is submitting an API to X/Open.
* At least two tookkits for sale.
30) Tool Kits Can Be Made Available To All Countries Not
Under UN Embargo
------------------------------------------------------------
-
PGP V3.0
* Probably from alternate sources
S/MIME
* Export version probably to most countries
MOSS
* Export version probably to most countries (40 bit
DES?)
* Alternate sources probably yes
MSP
* Export version probably to most countries. Toolkits
exported to many countries, including France.
* Alternate source likely.
31) Fit With Future Direction Of EDI
---------------------------------------
PGP V3.0
* Neutral
S/MIME
* Neutral
MOSS
* Neutral
MSP
* Neutral
Author:
Chuck Shih <cshih@netscape.com>
Phone: 415 937 3511 USA
Chair:
Rik Drummond <drummond@onramp.net>
Phone: 817 294 7339 USA
Datatracker
draft-ietf-ediint-req-00
Internet-Draft
