One document matched: draft-ietf-ediint-as1-02.txt
Differences from draft-ietf-ediint-as1-01.txt
INTERNET DRAFT Mats Jansson, LiNK
draft-ietf-ediint-as1-02.txt Chuck Shih, Actra
Nancy Turaj, Mitre Corp.
Rik Drummond, Drummond Group
19 November, 1996
MIME-based Secure EDI
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 obsoleted 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), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes how to securely exchange EDI documents
using MIME and public key cryptography.
Feedback Instructions:
If you want to provide feedback on this draft, follow these guidelines:
-Send feedback via e-mail to mjansson@agathon.com, with "AS#1" in the
Subject field.
-Be specific as to what section you are referring to, preferably
quoting the portion that needs modification, after which you state
your comments.
-If you are recommending some text to be replaced with your suggested
text, again, quote the section to be replaced, and be clear on the
section in question.
-If you are questioning fundamental methods, make it clear to us and
we will bring the issue to the ediint list for discussion. To follow
the discussion, you need to subscribe at ietf-ediint@imc.org.
Table of Contents
1. Introduction
2. Overview
2.1 Purpose of a security guideline for MIME EDI
2.2 Definitions
2.2.1 Terms
2.2.2 The secure transmission loop
2.2.3 Definition of receipts
2.3 Assumptions
2.3.1 EDI process assumptions
2.3.2 Flexibility assumptions
3. Structure of an EDI MIME message
3.1 Referenced RFCs and their contribution
3.1.1 RFC 821 SMTP [7]
3.1.2 RFC 822 Text Message Format [3]
3.1.3 RFC 1521 MIME [1]
3.1.4 RFC 1847 MIME Security Multiparts [6]
3.1.5 RFC 1892 Multipart/report [9]
3.1.6 RFC 1767 EDI Content [2]
3.1.7 RFC 2015 PGP/MIME [4]
3.1.8 Internet draft (fajman): Message Disposition Notification
[5]
3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8]
3.2 Vocabulary
3.3 Structure of an EDI MIME message - No encryption/No signature
3.4 Structure of an EDI MIME message - S/MIME
3.4.1 S/MIME Overview
3.4.2 Example: S/MIME - Signature Only
3.4.3 Example: S/MIME - Encryption Only
3.4.4 Example: S/MIME - Signature and Encryption
3.5 Structure of an EDI MIME message - PGP/MIME
3.5.1.PGP/MIME Overview
3.5.2 Example: PGP/MIME - Signature Only
3.5.3 Example: PGP/MIME - Encryption Only
3.5.4 Example: PGP/MIME - Signature and Encryption
4. Receipts
4.1 Introduction
4.2 Requesting a signed receipt
4.3 Message Disposition Notification Format
4.4 Message Disposition Notification Processing
4.4.1 Large File Processing
4.4.2 Example
5. Public key certificate handling
5.1 Near term approach
5.2 Long term approach
6. Authors' Addresses
7. References
1. Introduction
The authors would like to extend special thanks to Carl Hage for
providing the team with valuable, and very thorough feedback.
Without participants like Carl, these efforts become hard to
complete in a way useful to the users of the technology.
Previous work on Internet EDI focused on specifying MIME content
types for EDI data ([2] RFC 1767). This Applicability Statement
expands on RFC 1767 to specify use of a comprehensive set of data
security features, specifically data privacy, data
integrity/authenticity, non-repudiation of origin and non-
repudiation of receipt. This draft recognizes contemporary RFCs
and Internet drafts and is attempting to "re-invent" as little as
possible.
With an enhancements in the area of "receipts", as described below
(3.1.8), secure Internet MIME based EDI can be accomplished by
using and complying with the following RFCs and drafts:
-RFC 821 SMTP
-RFC 822 Text Message Formats
-RFC 1521 MIME
-RFC 1767 EDI Content Type
-RFC 1847 Security Multiparts for MIME
-RFC 1892 Multipart/Report
-Internet draft: Message Disposition Notification (fajman)
-RFC 2015 MIME/PGP (elkins)
-Internet draft: S/MIME Specification (dusse)
Our intent here is to define clearly and precisely how these
are pieced together and what is required by user agents to be
compliant with this Applicability Statement.
2. Overview
2.1 Purpose of a security guideline for MIME EDI
The purpose of these specifications is to ensure interoperability
between EDI user agents, invoking some or all of the commonly
expected security features. This standard is also NOT limited to
strict EDI use, but applies to any electronic commerce application
where business data needs to be exchanged over the Internet in a
secure manner.
2.2 Definitions
2.2.1. Terms
EDI Electronic Data Interchange
EC Electronic Commerce
Receipt The functional message that is sent from a
receiver to a sender to acknowledge receipt
of an EDI/EC interchange
Signed Receipt Same as above, but with a digital signature
Message Disposition The way by which a receipt or a signed
Notification (MDN) receipt is accomplished within Internet
Messaging.
Non-repudiation of NRR is a "legal event" that occurs when the
Receipt (NRR) original sender of an EDI/EC interchange has
verified the signed receipt coming back from
the receiver. NRR IS NOT a functional or a
technical message.
PGP/MIME Digital envelope security based on the Pretty
Good Privacy (PGP) standard (Zimmerman),
integrated with MIME Security Multiparts [6].
S/MIME A protocol for adding cryptographic
signature and/or encryption services to
Internet MIME messages.
2.2.2 The secure transmission loop
The functional requirements document, [9] "Requirements for Inter-
operable Internet EDI" (can be found at www.ietf.org),provides
extensive information on EDI security and the user/business related
processes surrounding the need for and use of EDI security. In
this document, it is assumed that the reader is familiar with the
requirements document.
This document's focus is on the formats and protocols for
exchanging EDI content that has had security applied to it using
the Internet's messaging transport.
The "secure transmission loop" for EDI involves one organization
sending a signed and encrypted EDI interchange to another
organization, requesting a "signed receipt", followed later by the
receiving organization sending this "signed receipt" back to the
sending organization. In other words, the following transpires:
-The organization sending EDI/EC data encrypts the data and
provides a digital signature, using either PGP/MIME or S/MIME.
In addition, they request a "signed receipt".
-The receiving organization decrypts the message and verifies the
signature, resulting in verified integrity of the data and
authenticity of the sender.
-The receiving organization then sends a "signed receipt" in the
form of a signature over the hash from the previous step.
The above describes functionality which if implemented, would
satisfy all security requirements. This specification, however,
leaves full flexibility for users to decide the degree to which they
want to deploy those features with their EDI trading partners.
2.2.3 Definition of receipts
The term used for both the functional activity and message for
acknowledging receipt of an EDI/EC interchange is "receipt", or
"signed receipt". The first term is used if the acknowledgment is
for an interchange that was not signed, thereby resulting in a
receipt which is also not signed. The second term is used if the
acknowledgment is for an interchange which was signed, resulting in
a receipt which is also signed. The rule is: If a receipt is
requested, it will be signed only if the original interchange was
signed. A term often used in combination with receipts is "Non-
repudiation of Receipt (NRR). NRR refers to a legal event which
occurs only when the original sender of an interchange has verified
the sender and content of a "signed receipt". Note that NRR is not
possible without signatures.
2.3 Assumptions
2.3.1 EDI process assumptions
-Encrypted object is an EDI Interchange
This specification assumes that a typical EDI interchange is the
lowest level object that will be subject to security features.
In ANSI X12, this means anything between, and including
segments ISA and IEA. In EDIFACT, this means anything between,
and including, segments UNA/UNB and UNZ. In other words, the
EDI interchanges including envelope segments remain intact and
unreadable during secure transport.
-EDI envelope headers are encrypted
Congruent with the above statement, EDI envelope headers are NOT
visible in the MIME package. In order to optimize VAN-to-
Internet routing, work may need to be done in the future to
define ways to pull out some of the envelope information to make
them visible, however, this specification does not go into any
detail on that.
-X12.58 and UN/EDIFACT security considerations
The most common EDI standards, ANSI X12 and EDIFACT, have
defined internal provisions for security. X12.58 is the
security mechanism for ANSI X12 and AUTACK provides security for
EDIFACT. This specification DOES NOT dictate use or non-use of
these security standards. They are both fully compatible,
though possibly redundant, with this specification.
2.3.2 Flexibility assumptions
-Encrypted or un-encrypted data
This specification allows for EDI message exchange where the EDI
data is either un-protected or protected by means of encryption.
-Signed or un-signed data
This specification allows for EDI message exchange with or
without digital signature of the original EDI transmission.
-Use of receipt or not (signature required for "Signed Receipt")
This specification allows for EDI message transmission with or
without a request for receipt notification. If receipt
notification is requested, however, a signature is required as
part of both the original EDI transmission and the returned
receipt.
-Formatting choices
This specification defines use of two methods for formatting EDI
contents that have security applied to it:
-PGP/MIME
-S/MIME
This specification relies on the guidelines set forth in the
Internet draft on PGP/MIME, as reflected in [4] MIME Security
with Pretty Good Privacy (PGP), and [8] S/MIME Specification
from RSA Security, Inc. Compliance with this specification
dictates that AT LEAST one of these methods is supported.
-Hash function, message digest choices
When signature is used, unless specified otherwise by the chosen
method (PGP/MIME or S/MIME), the MD5 checksum hash function is
recommended.
In summary, the following eight permutations are possible, in
any given trading relationship:
(1) Sender sends un-encrypted data, does NOT request a receipt.
(2) Sender sends unencrypted data, requests a receipt. Receiver
sends back a receipt.
(3) Sender sends encrypted data, does NOT request a receipt.
(4) Sender sends encrypted data, requests a receipt. Receiver
sends back a receipt.
(5) Sender sends signed data, does NOT request a signed receipt.
(6) Sender sends signed data, requests a signed receipt.
Receiver sends back a signed receipt.
(7) Sender sends encrypted and signed data, does NOT request a
signed receipt.
(8) Sender sends encrypted and signed data, requests a signed
receipt. Receiver sends back a signed receipt.
NOTE: Users can choose any of the eight possibilities, but only
example (8) offers the whole suite of security features
described in the "Secure transmission loop" above.
NOTE: A request for receipt that is signed, MUST result in a
signed receipt. A request for receipt without signature MUST
result in an un-signed receipt.
3. Structure of an EDI MIME message
The following sub chapters describe the structure of EDI MIME
messages, making use of security features in different ways.
Please note that if a signed receipt is to be returned, the
original EDI transmission also had to have been signed.
The structures shown below represent the use of specifications
outlined in the following RFCs and Internet-drafts, and before
moving into the structures themselves, there is a brief review of
what each document contributes.
NOTE: The examples below are just that - examples. Do not code
according to them. Refer to the RFCs that specify the correct
grammar in each case.
3.1 Referenced RFCs and their contribution
3.1.1 RFC 821 SMTP [7]
This is the core mail transfer standard that all MTAs need to
adhere to.
3.1.2 RFC 822 Text Message Format [3]
Defines message header fields and the parts making up a message.
3.1.3 RFC 1521 MIME [1]
This is the basic MIME standard, upon which all MIME related RFCs
build, including this one. Key contributions include definition of
"content type" and sub-type "multipart", in addition to encoding
guidelines, which establish 7-bit US-ASCII as the lowest common
denominator used.
3.1.4 RFC 1847 MIME Security Multiparts [6]
This document defines security multiparts for MIME:
multipart/encrypted and multipart/signed.
\ 3.1.5 RFC 1892 Multipart/report [10]
This RFC defines the use of Multipart/report content type,
something that the MDN draft (fajman) relies on for the receipt
functionality.
3.1.6 RFC 1767 EDI Content [2]
This RFC defines the use of content type "application" for ANSI
X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and
mutually defined EDI (application/EDI-Consent).
3.1.7 RFC 2015 PGP/MIME [4]
This RFC defines the use of content types
"multipart/encrypted", "multipart/signed", "application/pgp
encrypted" and "application/pgp-signature" for defining MIME PGP
content.
3.1.8 Internet draft (fajman): Message Disposition Notification [5]
This Internet draft defines how a message disposition notification
(MDN) is requested, and the structure of the MDN.
NOTE: This is the only specification we were not able to take
"as is". Extension field-names beginning with "X-" will not be
defined as a standard field. MDN field names not beginning with "X-
" need to be registered with the Internet Assigned Numbers
Authority (IANA) and described in an RFC. The X-Received-MIC field
described in this document will be registered with IANA.
3.1.9 Internet draft (dusse): S/MIME Message Specification [8]
This specification describes how MIME shall carry PKCS7
signature and envelope information.
3.2 Vocabulary
<recipient email> The email address of the receiving
organization's EDI processing system.
<sender email> The email address of the sending organi-
zation's EDI processing system.
<date> Transmission date
<EDI standard> "EDIFACT" or "EDI-X12" or "EDI-consent"
<encoding> "Quoted-printable" or "Base64"
<EDI Object> ANSI X12 or EDIFACT EDI Interchange, or
mutually agreed electronic commerce file
<char set> "us-ascii" or "iso-8859-1" (note that if
iso-8859-1 is used, in most cases
encoding will be required "Quoted
printable" or "Base 64"
<hash symbol> "md5" or "sha1"
<pgp control information> -Key ID of recipient's public key
-Session key (symmetric)
-Timestamp
-Key ID of sender's public key
-Leading two octets of message digest
-Message digest
-Filename
-Timestamp
<PKCS#7 control information - enveloped>
-contentType = EnvelopedData
-version = Version
-recipientInfos = RecipientInfos
-contentType = Data
-contentEncryptionAlgorithm =
ContentEncryptionAlgorithmIdentifier
-encryptedContent =
<PKCS#7 control information - signed>
-ContentType = SignedData
-version = Version
-digestAlgorithms =
DigestAlgorithmIdentifiers
-contentType = Data
-content =
<PKCS#7 signature information>
-signerInfos = SignerInfo
NOTE: The examples below are just that - examples. They are
provided for illustration purposes only. Refer to the RFCs or
drafts under "7. References" for the actual grammar and protocol
definitions.
3.3 Structure of an EDI MIME message - No encryption/No signature
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: Application/<EDI standard>
Content-Transfer-Encoding: <encoding>
<EDI object>
3.4 Structure of an EDI MIME message - S/MIME
3.4.1 S/MIME Overview
S/MIME or the Secure/Multipurpose Internet Mail Extensions,
specify formats and procedures when the cryptographic security
services of authentication, message integrity, non-repudiation of
origin, and confidentiality are applied to Internet MIME messages.
S/MIME is specified in draft draft-dusse-mime-msg-spec-00.txt, and
an S/MIME implementation guide is available from RSA Data
Securities, Inc.
This applicability statement sets forth the implementation
requirements and recommendations needed to use S/MIME when sending
EDI on the Internet. These implementation requirements and
recommendations are intended to ensure a base level of inter-
operability among S/MIME EDI implementations.
NOTE: The S/MIME Implementation Guide, Version 2 specifies a
restricted profile for use for export purposes and an unrestricted
profile for use domestically. These profiles specify the
cryptographic algorithms and key lengths that a conformant S/MIME
implementation must support. It is recommended that for Internet
EDI, these profiles be adhered to. However, cryptographic
algorithms, and key lengths are parameters that need to be set by
the trading partnership, and can vary from what is specified by
the S/MIME standards.
Content Types:
signedAndEnvelopedData content type should not be
used when sending EDI on the Internet. Objections have been raised
concerning the fact that the issuerAndSerialNumber for each signer
of a signedAndEnvelopedData content is left in the clear. This
information could be used to derive the identity of the signer
of the message. The use of signedAndEnvelopedData also precludes
the ability to sign information that is in addition to, but
separate from the primary signed contents. The use of the S/MIME
"authenticated attributes" is not required for Internet EDI, since
it is generally sufficient to sign the EDI MIME content.
The S/MIME Implementation Guide, Version 2 requires a compliant
S/MIME agent to support the nesting of a signed message format
within an enveloped message, for both incoming and outgoing
messages. This EDI AS#1 specification also requires the support of
a nested signed message within an enveloped message. Therefore,
when using S/MIME for the purpose of sending EDI on the Internet,
a two step process will be used: the user agent first creates an
application/x-pkcs7-mime signed message, and uses this message as
input to the creation of an application/x-pkcs7-mime enveloped
message.
The receiver of an incoming enveloped message that is decrypted
and found to contain a signed application/x-pkcs-7-mime type,
should process the signed contents and present the signature
status and corresponding "data" content to message disposition
notification processing -- if a request for a message disposition
notification has been made -- otherwise the "data" content is
passed to a general MIME processor.
The "data" content type is used as the content within the
signedData and the envelopedData content types, to indicate the
MIME message content which has had security services applied to
it. For the purpose of Internet EDI, this "data" content type will
contain RFC 1767 specified MIME EDI content, or a MIME multipart
content that has a RFC 1767 MIME EDI content as part of the
multipart content.
Signed Message Type:
The S/MIME specification requires support of the signedData
content format, and recommends support of the multipart/signed
format. For use in Internet EDI, support is required for the
signedData content format if message authentication, integrity,
and non-repudiation of origin are required. The great value for
support of the multipart/signed format is the ability of non-
S/MIME-enabled agents to process the content of the body that was
signed.
The multipart/signed format is recommended when a signed message
is being sent to a set of recipients, not all of which are known
to have S/MIME enabled agents. Since trading partners using S/MIME
to transact EDI on the Internet will by definition have S/MIME-
enabled agents, the multipart/signed loses much of its utility.
Support of the multipart/signed format for use in Internet EDI is
therefore optional.
3.4.2 Example: S/MIME - Signature Only
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: application/x-pkcs7-mime
Content-Transfer-Encoding: base64
<PKCS#7 control information - signed>
&Mime-Version: 1.0
&Content-Type: Application/<EDI standard>;
&Content-Transfer-Encoding: <encoding>
&
&<EDI object>
<PKCS#7 signature information>
Notes:
-The lines preceded with "&" is what the signature is calculated
over
- <PKCS#7 control information - signed> consists of (refer to:
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):
ContentType = SignedData
version = Version
digestAlgorithms = DigestAlgorithmIdentifiers
contentType = Data
content =
NOTE: that except for ContentType and Content, the actual object
identifiers or values for the fields are not specified. (See PKCS#9
and the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc.,
for these object identifiers.)
- <PKCS#7 signature information> consists of (refer to:
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):
signerInfos = SignerInfo
NOTE: The signerInfo contains the digestAlgorithm, the
digestEncryptionAlgorithm, and the encryptedDigest or the digital
signature. The issuerAndSerialNumber field defined within the
signerInfos identifies a signing trading partner's public-key
certificate. Since Internet EDI allows self-certification, this
field can contain the distinguished name of the sending trading
partner for the issuer distinguished name.
3.4.3 Example: S/MIME - Encryption Only
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: application/x-pkcs7-mime
Content-Transfer-Encoding: base64
<PKCS#7 control information - enveloped>
&Mime-Version: 1.0
&Content-Type: Application/<EDI standard>;
&Content-Transfer-Encoding: <encoding>
&
&<EDI object>
Notes:
-The text preceded by "&" indicates that it is really encrypted,
but presented as text for clarity
- <PKCS#7 control information - enveloped> consists of (See
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):
contentType = EnvelopedData
version = Version
recipientInfos = RecipientInfos
contentType = Data
contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier
encryptedContent =
NOTE: Except for contentType, the actual object identifiers or
values for the fields are not specified. (See PKCS#9 and the S/MIME
Implementation Guide, Version 2 from RSA Labs, Inc., for these
objects.)
NOTE: The recipientInfos contains the symmetric encryption key
encrypted with the receiver's public key. The issuerAndSerialNumber
field defined within the recipientInfos identifies a receiving
trading partner's public-key certificate. Since Internet EDI allows
self-certification, this field can contain the distinguished name of
the receiving trading partner for the issuer distinguished name.
NOTE: In general there will be one recipientInfos specified, but in
the case of RFQs there may be n recipientInfos specified.
3.4.4 Example: S/MIME - Signature and Encryption
The required support for EDI Internet is to first create an
application/x-pkcs7-mime signedData message, and then to create an
application/x-pkcs7-mime envelopedData message with the application/x-
pkcs7-mime signedData message as input to the application/x-pkcs7-mime
envelopedData message.
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: application/x-pkcs7-mime
Content-Transfer-Encoding: base64
<PKCS#7 control information - enveloped>
*Mime-Version: 1.0
*Content-Type: application/x-pkcs7-mime
*<PKCS#7 control information - signed>
*&MIME-Version: 1.0
*&Content-Type: Application/<EDI standard>;
*&Content-Transfer-Encoding: <encoding>
*&<EDI object>
*<PKCS#7 signature information>
Notes:
- The lines preceded with "&" is what the signature is calculated
over.
- The text preceded by "*" indicates that it is really encrypted, but
presented as text for clarity
- <PKCS#7 control information - enveloped> consists of (See
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):
contentType = EnvelopedData
version = Version
recipientInfos = RecipientInfos
contentType = Data
contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier
encryptedContent =
NOTE: Except for contentType, the actual object identifiers or
values for the fields are not specified. (See PKCS#9 and the S/MIME
Implementation Guide, Version 2 from RSA Labs, Inc., for these
objects.)
NOTE: The recipientInfos contains the symmetric encryption key
encrypted with the receiver's public key. The issuerAndSerialNumber
field defined within the recipientInfos identifies a receiving
trading partner's public-key certificate. Since Internet EDI allows
self-certification, this field can contain the distinguished name of
the receiving trading partner for the issuer distinguished name.
NOTE: In general there will be one recipientInfos specified, but in
the case of RFQs there may be n recipientInfos specified.
- <PKCS#7 signature information> consists of (refer to:
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):
signerInfos = SignerInfo
NOTE: The signerInfo contains the digestAlgorithm, the
digestEncryptionAlgorithm, and the encryptedDigest or the digital
signature. The issuerAndSerialNumber field defined within the
signerInfos identifies a signing trading partner's public-key
certificate. Since Internet EDI allows self-certification, this
field can contain the distinguished name of the sending trading
partner for the issuer distinguished name.
3.5 Structure of an EDI MIME message - PGP/MIME
3.5.1 Overview
PGP provides two functional services, signature and encryption,
but in reality performs 5 functions in order to do it effectively.
1) Digital signature (MD5, RSA)
2) Compression (ZIP)
3) Message Encryption (IDEA)
4) ASCII Armor
5) Message segmentation
When sending a message, the services are performed in that order.
With the exception of item 5), these services are optional,
meaning a user can choose whether to use signature, encryption,
compression and ASCII armor, but commonly, 2) and 4) are always
used, while 1) and 3) are used in three ways:
1) Signature only, in which case ASCII armor can be applied only
to the signature block to keep the message legible.
2) Encryption only
3) Both signature and encryption
Applicability of PGP/MIME and RFC 2015, for use in internet EDI
dictates the following:
- When both encryption and signature feature is used, the EDI
data is first signed, then encrypted in a two-step process, as
described in the example.
-Compression and ASCII Armor is optional and could be user
configurable.
The following examples describe use of PGP/MIME without
compression and ASCII armor, since those services are managed by
PGP, and are optional per this draft
.
3.5.2 Example: PGP/MIME - Signature Only
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="separator";
micalg=pgp-<hash symbol>; protocol="application/pgp-signature"
--separator
&Content-Type: Application/<EDI standard>
&Content-Transfer-Encoding: <encoding>
&
&<EDI object>
--separator
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version 2.6.2
fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQere
/876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
frtFFKFG+GFff=
=ndaj
-----END PGP MESSAGE-----
--separator--
Notes:
-The lines preceded with "&" is what the signature is calculated
over.
3.5.3 Example: PGP/MIME - Encryption Only
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary="separator";
protocol="application/pgp-encrypted"
--separator
Content-Type: application/pgp-encrypted
Version: 1
--separator
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version 2.6.2
&<pgp control information>
&Content-Type: Application/<EDI standard>;
&Content-Transfer-Encoding: <encoding>
&
&<EDI object>
-----END PGP MESSAGE-----
--separator--
Notes:
-The text preceded by "&" indicates that it is really encrypted, but
presented as text for clarity
-"pgp control information" contains the following, but refer to PGP
specifications or tool kits for details:
-Key ID of recipient's public key
-Session key (symmetric)
-Timestamp
-Key ID of sender's public key
-Leading two octets of message digest
-Message digest
-Filename
-Timestamp
3.5.4 Example: PGP/MIME - Signature and Encryption
The sequence here is that the EDI data is first signed as a
multipart/signature body, and then the data plus the signature is
encrypted to form the final multipart/encrypted body. Here goes:
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary="separator";
protocol="application/pgp-encrypted"
--separator
Content-Type: application/pgp-encrypted
Version: 1
--separator
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version 2.6.2
* <pgp control information>
* Content-Type: multipart/signed; boundary="signed separator";
* micalg=pgp-<hash symbol>; protocol="application/pgp-signature"
*
* --signed separator
* &Content-Type: Application/<EDI standard>
* &Content-Transfer-Encoding: <encoding>
* &
* &<EDI object>
*
* --signed separator
* Content-Type: application/pgp-signature
*
* -----BEGIN PGP MESSAGE-----
* Version 2.6.2
*
* fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd
* /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
* frtFFKFG+GFff=
* =ndaj
* -----END PGP MESSAGE-----
*
* --signed separator--
-----END PGP MESSAGE-----
--separator--
Notes:
- The lines preceded with "&" is what the signature is calculated
over.
- The text preceded by "*" indicates that it is really encrypted,
but presented as text for clarity
- "pgp control information" contains the following, but refer to
PGP specifications or tool kits for details:
-Key ID of recipient's public key
-Session key (symmetric)
-Timestamp
-Key ID of sender's public key
-Leading two octets of message digest
-Message digest
-Filename
-Timestamp
-RFC 2015 allows another way to handle the above in a combined
fashion, However, for the purpose of EDI we require the above method,
which is based on MIME Security Multiparts [4] RFC 1847. This method
performs signature and encryption in a two-step process, first signing
the data, then encrypting it. This is also consistent with PGP's
recommendations.
4. Receipts
4.1 Introduction
In order to provide a non-repudiation of receipt (NRR) or signed
receipt, a message disposition notification (MDN) as specified by draft-
ietf-receipt-mdn-01 is to be implemented by a receiving trading
partner's UA (User Agent). The message disposition notification
is then digitally signed and returned to the sending trading partner
as part of a multipart/signed content.
The required support for signed receipts when doing EDI Internet is as follows:
1). Create a multipart/report; report-type=disposition-notification.
2). Calculate the MIC on the message disposition notification.
3). Digitally sign the MIC.
4). Create a multipart/signed content with the message disposition
notification as the first body part, and the signed MIC
calculated on the message disposition notification as the
second body part.
5). Return the signed receipt to the sending trading partner.
The MDN is used to notify a sending trading partner that sent a signed,
or signed and encrypted EDI Interchange that:
1). The receiving trading partner acknowledges receipt of
the sent EDI Interchange.
2). The receiving trading partner has authenticated the sender of
the EDI Interchange.
3). The receiving trading partner has verified the integrity of the
received EDI Interchange.
Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME
format, the receiving trading partner's UA must provide the following
basic processing:
1). If the sent EDI Interchange is encrypted, then the encrypted
symmetric key and initialization vector (if applicable) is
decrypted using the receiver's private key.
2). The decrypted symmetric encryption key is then used to decrypt
the EDI Interchange.
3). The receiving trading partner authenticates signatures in a
message using the sender's public key. The authentication
algorithm performs the following:
a). The message integrity check (MIC or Message Digest)
contained within the signature is decrypted using the
sender's public key.
b). A MIC on the signed contents (the MIME header and encoded
EDI object, as per RFC1767) in the message received is
calculated using the same one-way hash function that the
sending trading partner used.
c). The MIC extracted from the signature is compared with the
MIC calculated using the same one-way hash function that
the sending trading partner used.
4). The receiving trading partner formats the MDN and sets the
calculated MIC into the MDN extension field.
5). The receiving trading partner creates a multipart/signed MIME
message according to RFC 1847.
6). The MDN is the first part of the multipart/signed message, and
the digital signature is created over this MDN, including its
MIME headers.
7). The second part of the multipart/signed message contains the
digital signature. The "protocol" option specified in the
multipart/signed is as follows:
S/MIME: protocol = "application/pkcs-7-mime"
PGP/MIME: protocol = "application/pgp-signature"
The EDI Interchange and the RFC 1767 MIME EDI content header, can
actually be part of a multi-part MIME content-type. When the EDI
Interchange is part of a multi-part MIME content-type, the MIC is
calculated across the entire multi-part content, including the MIME
headers. The multi-part MIME content that contains the EDI Interchange
is then enveloped in either PKCS #7 or PGP format.
The signed MDN, when received by the sender of the EDI Interchange can then be used by the sender:
1). As an acknowledgment that the EDI Interchange sent, was
delivered and acknowledged by the receiving trading partner.
The receiver does this by returning the original message
id of the sent message in the signed MDN.
2). As an acknowledgment that the integrity of the EDI Interchange
was verified by the receiving trading partner. The receiver
does this by returning the calculated MIC of the received EDI
Interchange (and 1767 MIME headers) in the X-Received-MIC
field of the signed MDN.
3). As an acknowledgment that the receiving trading partner has
authenticated the sender of the EDI Interchange.
4). As a non-repudiation of receipt when the signed MIC calculated
over the MDN, is successfully decrypted by the sender with the
receiver's public key.
4.2 Requesting a signed receipt
Message Disposition Notifications are requested as per the draft-ietf-
receipt-mdn-01.txt. A request that the receiving user agent issue a
message disposition notification is made by placing the following header
into the message to be sent:
mdn-request-header = "Disposition-notification-to" ":" address
The address field is specified as an RFC 822 user@domain address, and is
the return address for the message disposition notification.
A note to implementors: this RFC does not preclude the sending of a
signed receipt whenever EDI content is received by a trading partner.
The sending of a signed receipt can be made a configurable parameter,
and a signed receipt may be returned even though the original message
does not contain a receipt request.
4.3 Message Disposition Notification Format
The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-01.txt. For use in EDI over the Internet the following format will be used:
- content-type - per RFC1892 and the ietf-receipt-mdn specification
- reporting-ua-field - per ietf-receipt-mdn specification
- mdn-gateway-field - per ietf-receipt-mdn specification
- original-recipient-field - per ietf-receipt-mdn specification
- final-recipient-field - per ietf-receipt-mdn specification
- original-message-id-field - per ietf-receipt-mdn specification
- disposition-field - for EDI use:
* autoprocessed - when the received content(s) are
successfully processed
* decryption_failed - when the receiver could not decrypt the
contents
* authentication_failed - when the receiver could not
authenticate the sender
* integrity_check_failed - when the receiver could not verify
content integrity
- extension field - the following extension field will be added in
order to support signed-receipts for RFC 1767 specified content
types and multi-part specified content types which includes RFC
1767 content types. The extension field is sent only when the
received contents are successfully processed.
- extension field = "X-" "Received-MIC" ":" MIC
MIC or message integrity check, is defined as the result of a one-way
hash function applied to the received EDI Interchange and RFC 1767 MIME
content type information, or the multi-part MIME content containing
RFC 1767 MIME EDI content information. The MIC is also referred to as a
message digest when using the MD5 one-way hash function.
4.4 Message Disposition Notification Processing
4.4.1 Large File Processing
Large EDI Interchanges sent via SMTP can be automatically
fragmented by some message transfer agents. A subtype of message,
"partial", is defined in RFC 1521 to allow large objects to be
delivered as separate pieces of mail and to be automatically
reassembled by the receiving user agent. Using message, "partial",
can help alleviate fragmentation of large messages by different
message transfer agents, but does not completely eliminate the
problem. It is still possible that a piece of a partial message,
upon re-assembly, may prove to contain a partial message as well.
This is allowed by the Internet standards, and it is
the responsibility of the user agent to re-assemble the fragmented
pieces.
It is recommended that the size of the EDI Interchange sent via
SMTP be configurable so that if fragmentation does occur, then
message, "partial" can be used to send the large EDI Interchange
in smaller pieces. RFC 1521 defines the use of Content-Type:
message/partial. Support of the message/partial content type for
use in Internet EDI is optional.
The receiving UA is required to re-assemble the original message
before sending the message disposition notification to the
original sender of the message. A message disposition notification
is used to specify the disposition of the entire message that was
sent, and should not be returned by a processing UA until the
entire message is received, even if the received message requires
re-assembling.
In general, EDI content compresses well, since there is repetitive
data in most EDI Interchanges. Instead of implementing the
message/partial, compression of the EDI Interchange can be done
after the signature is applied to the EDI Interchange, and before
encryption. When no signature applied, then compression is applied
before the encryption. Compression is an alternative solution to
implementing Content-Type: message/partial when sending large EDI
Interchanges on the Internet.
Applying compression before encryption strengthens cryptographic
security since repetitious strings are reduced. This sequence is
consistent with the PGP sequence as well.
4.4.3 Example
The following is an example of a signed receipt returned by a UA
after processing a MIME EDI content type that was signed.
NOTE: This example is provided as an illustration only, and is
not considered part of the protocol specification. If an example
conflicts with the protocol definitions specified above or in the
other referenced RFCs, the example is wrong.
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="separator";
micalg=rsa-md5; protocol="application/x-pkcs7-mime"
--separator
&Content-Type: multipart/report; report-type=disposition
& notification; boundary = "xxxxx"
&
&--xxxxx
& The message sent to Edi Recipient <Edi_Recipient@edicorp.com>
& has been received, the EDI Interchange was succesfully
& decrypted and its integrity was verified. In addition, the
& sender of the message, Edi Sender <Edi_Sender@othercorp.com>
& was authenticated as the originator of the message. There is
& no guarantee however that the EDI Interchange was
& syntactically correct, or was received by the EDI
& application.
&
&--xxxxx
& Content-Type: message/disposition-notification
&
& Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0)
& Original-Recipient: rfc822; Edi_Recipient@edicorp.com
& Final-Recipient: rfc822; Edi_Recipient@edicorp.com
& Original-Message-ID: <17759920005.12345@edicorp.com>
& Disposition: autoprocessed
& X-Received-MIC: Q2hlY2sgSW50XwdyaXRIQ……
&
&--xxxxx
& Content-Type: message/rfc822
&
&--xxxxx--
--separator
Content-Type: application/x-pkcs7-mime
@ContentType = SignedData
@version = Version
@digestAlgorithms = DigestAlgorithmIdentifiers
@contentType = Data
@content =
fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQere
/876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
frtFFKFG+GFff=
=ndaj
@signerInfos = SignerInfo
--separator--
Notes:
-The lines preceeded with "&" is what the signature is calculated
over.
-The text preceeded by "@" indicates PKCS#7 defined fields and types.
(See PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.)
As specified by RFC 1892, returning the original message is not
necessary. This is an optional body part. It is recommended that
the received headers be placed in the third body part, as it can
be helpful in tracking problems.
5. Public key certificate handling
5.1 Near term approach
In the near term, the exchange of public keys and certificaition
of these keys must be handled as part of the process of
establishing a trading partnership. The UA and/or EDI application
interface must maintain a database of public keys used for
encryption or signatures, in addition to the mapping between EDI
trading partner ID and RFC822 email address. The procedures for
establishing a trading partnership and configuring the secure EDI
messaging system might vary among trading partners and software
packages.
For systems which make use of X.509 certificates, it is recommended
that trading partners self-certify each other if an agreed upon
certification authority is not used. It is highly recommended that
when trading partners are using S/MIME, that they also exchange
public key certificates using the recommendations specified in the
S/MIME Implementation Guide Version 2. The message formats and
S/MIME conformance requirements for certificate exchange are
specified in this document.
This applicability statement does NOT require the use of a
certification authority.
5.2 Long term approach
In the long term, additional Internet-EDI standards may be
developed to simplify the process of establishing a trading
partnership, including the third party authentication of trading
partners, as well as attributes of the trading relationship.
6. Authors' Addresses
Mats Jansson
mjansson@agathon.com
LiNK
1026 Wilmington Way
Redwood City, CA 94062 USA
Chuck Shih
chucks@actracorp.com
Actra Corp.
610 East Caribbean Drive
Sunnyvale, CA 94089 USA
Nancy Turaj
nturaj@.mitre.org
MITRE Corporation
Mailstop: W657
1820 Dolley Madison Blvd.
McLean, VA 22102-3481 USA
Rik Drummond
drummond@onramp.com
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA
7. References
[1] N. Borenstein, N.Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, September 23, 1993.
[2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March
2, 1995.
[3] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 13, 1982.
[4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC
2015, Sept. 1996.
[5] R. Fajman, "An Extensible Message Format for Message Disposition
Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996.
[6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts
for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct.
3,1995
[7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1, 1982.
[8] S. Dusse, "S/MIME Message Specification; PKCS Security
Services for MIME", Internet draft: draft-dusse-mime-msg-spec
00.txt
[9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996.
[10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages", RFC 1892, January 15,
1996.
| PAFTECH AB 2003-2026 | 2026-04-23 01:16:42 |