Network Working Group T. Harding Request for Comments: 4823 R. Scott Category: Informational Axway April 2007 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
1. Introduction ....................................................4 2. Overview ........................................................4 2.1. Overall Operations .........................................4 2.2. Purpose of a Security Guideline for MIME EDI ...............5 2.3. Definitions ................................................5 2.3.1. Terms ...............................................5 2.3.2. The Secure Transmission Loop ........................6 2.3.3. Definition of Receipts ..............................7 2.4. Operational Assumptions and Options ........................8 2.4.1. EDI/EC Process Assumptions ..........................8 2.4.2. Process Options .....................................8 22.214.171.124. Security Options ...........................8 126.96.36.199. Compression Options .......................10 3. Referenced RFCs and Their Contribution .........................10 3.1. RFC 959: File Transfer Protocol  .......................10 3.2. RFC 2228: FTP Security Extensions  .....................10 3.3. RFC 1847: MIME Security Multiparts  ....................10 3.4. RFC 3462: Multipart/Report  ...........................11 3.5. RFC 1767: EDI Content  .................................11 3.6. RFCs 2045, 2046, and 2049: MIME  .......................11 3.7. RFC 3798: Message Disposition Notification  ............11 3.8. RFC 3852: CMS  and RFC 3851: S/MIME Version 3.1 Message Specification  ................................11 3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling  ....11 3.10. RFC 3274: Compressed Data Content Type for Cryptographic Message Syntax (CMS)  ..................11 3.11. RFC 3023: XML Media Types  ...........................12 4. Structure of an AS3 Message ....................................12 4.1. Introduction ..............................................12 4.2. Structure of an Internet EDI MIME Message .................12 5. AS3-Specific Headers ...........................................13 5.1. AS3-From and AS3-To Headers ...............................13 5.2. AS3-Version Header ........................................14 6. FTP Considerations .............................................15 6.1. FTP Security Requirements .................................15 6.2. Large File Transfers ......................................15 6.3. MIME Considerations for FTP ...............................15 6.3.1. Required/Optional Headers ..........................15 6.3.2. Content-Transfer-Encoding ..........................16 6.3.3. Epilogue Must Be Empty .............................16 6.3.4. Message-Id and Original-Message-Id .................16 7. Structure and Processing of an MDN Message .....................17 7.1. Introduction ..............................................17 7.2. Message Disposition Notifications (MDN) ...................19 7.3. Requesting a Signed Receipt ...............................19 7.3.1. Signed Receipt Considerations ......................22
7.4. MDN Format and Value ......................................23 7.4.1. AS3-MDN General Formats ............................23 7.4.2. AS3-MDN Construction ...............................24 7.4.3. AS3-MDN Fields .....................................25 7.4.4. Additional AS3-MDN Programming Notes ...............26 7.5. Disposition Mode, Type, and Modifier ......................29 7.5.1. Disposition Mode Overview ..........................29 7.5.2. Successful Processing Status Indication ............29 7.5.3. Unsuccessful Processed Content .....................29 7.5.4. Unsuccessful Non-Content Processing ................30 7.5.5. Processing Warnings ................................31 8. Public Key Certificate Handling ................................32 9. Security Considerations ........................................33 10. References ....................................................34 10.1. Normative References .....................................34 10.2. Informative References ...................................36 Appendix A. Message Examples ......................................37 A.1. Signed Message Requesting a Signed Receipt ................37 A.2. MDN for Message A.1 Above .................................37
2] and extending this work to support secure EC/EDI transport over SMTP . This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically, data privacy, data integrity, authenticity, non-repudiation of origin, and non-repudiation of receipt over FTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. While this document focuses on EDI data, any other data type describable in a MIME format is also supported. Internet MIME-based EDI can be accomplished by using and complying with the following documents: - RFC 959: File Transfer Protocol - RFC 2228: FTP Security Extensions - RFC 1767: EDI Content Type - RFC 3023: XML Media Types - RFC 1847: Security Multiparts for MIME - RFC 3462: Multipart/Report - RFCs 2045 to 2049: MIME - RFC 3798: Message Disposition Notification - RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications - RFC 3274: Compressed Data Content for Cryptographic Message Syntax - RFC 4217: Securing FTP with TLS - "Compressed Data for EDIINT" by T. Harding Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .
business data using FTP. The security protocols and structures used also support auditable records of these transmissions.
NOTE: While the S/MIME specification describes more than one format for a signed message, all signed messages or receipts used with AS3 MUST utilize the multipart/signed format. SHA-1 A secure, one-way hash algorithm used in conjunction with digital signature. SHA-1 is the recommend algorithm for AS3. MD5 A secure, one-way hash algorithm used in conjunction with digital signature. This algorithm is acceptable but not recommended due to its short key length and known weaknesses. MIC The message integrity check (MIC) is a representation of the message digest, which results from the application of the selected hash algorithm to the content to be signed. Of particular interest is the digital signature, which includes an encrypted copy of the digest. Additionally, an MDN containing a Received- content-MIC header will also contain (as that header's value) a base-64-encoded representation of the digest. User Agent (UA) The application that handles and processes the AS3 request. STL Secure Transmission Loop, described in the next section.
In other words, the following events occur during the execution of the STL: - The organization sending EDI/EC data signs and encrypts the data using S/MIME. In addition, the message will request a signed receipt to be returned to the sender of the message. - 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 returns a signed receipt, as requested to the sending organization in the form of a message disposition notification. This signed receipt will contain the hash of the signature from the received message, indicating to the sender that the received message was verified and/or decrypted properly. The above describes functionality that, if implemented, will satisfy all security requirements and provide non-repudiation of receipt for the exchange. While trading partners will usually want to utilize the STL, this specification does not require it. Section 7.
- Signed or unsigned data This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission. - Use of receipt or not This specification allows for EDI/EC message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a MIC value is REQUIRED as part of the returned receipt, unless an error condition occurs that results in the inability to compute a valid digest. (Such a case would result, for instance, if an encrypted message could not be decrypted.) Under such circumstances, an unsigned receipt (MDN) SHOULD be returned with the correct "disposition modifier" error value. - Security formatting This specification relies on the guidelines set forth in RFCs 3852  and 3851 . The first of these RFCs describes the Cryptographic Message Syntax (CMS), and the second contains the S/MIME Version 3.1 Message Specification describing a MIME container for CMS objects. Whenever the term S/MIME is used in this document, it refers to Version 3.1 as described therein. - Hash function, message digest choices When a signature is used, it is RECOMMENDED that the SHA-1 hash algorithm be used for all outgoing messages; however, both MD5 and SHA-1 MUST be supported for incoming messages. - Permutation summary In summary, the following twelve security permutations are possible in any given trading relationship: 1. Sender sends un-encrypted data, does NOT request a receipt. 2. Sender sends un-encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt. 3. Sender sends un-encrypted data, requests a signed receipt. The receiver sends back the signed receipt. 4. Sender sends encrypted data, does NOT request a receipt.
5. Sender sends encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt. 6. Sender sends encrypted data, requests a signed receipt. The receiver sends back the signed receipt. 7. Sender sends signed data, does NOT request a receipt. 8. Sender sends signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt. 9. Sender sends signed data, requests a signed receipt. Receiver sends back the signed receipt. 10. Sender sends encrypted and signed data, does NOT request a receipt. 11. Sender sends encrypted and signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt. 12. Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back the signed receipt. This case represents the Secure Transmission Loop described above. RFC 3274. Implementation details may be found in that RFC and in Harding's document, "Compressed Data for EDIINT". RFC 959 specifies how data is transferred using the File Transfer Protocol (FTP)
RFC 3023 introduces for the "+xml" suffix, no support for external parsed entity types is anticipated (as it adds significant complexity to signature processing). RFC822/2045 -RFC1767/RFC2376 (application/EDIxxxx or /xml) No encryption, signature -RFC822/2045 -RFC1847 (multipart/signed) -RFC1767/RFC2376 (application/EDIxxxx or /xml) -RFC3851 (application/pkcs7-signature) Encryption, no signature -RFC822/2045 -RFC3851 (application/pkcs7-mime) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature -RFC822/2045 -RFC3851 (application/pkcs7-mime) -RFC1847 (multipart/signed)(encrypted) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) -RFC3851 (application/pkcs7-signature)(encrypted) MDN, no signature -RFC822/2045 -RFC3798 (message/disposition-notification) MDN, signature -RFC822/2045 -RFC1847 (multipart/signed) -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature) While all MIME content types SHOULD be supported, the following MIME content types MUST be supported: Content-Type: multipart/signed Content-Type: multipart/report Content-type: message/disposition-notification Content-Type: application/PKCS7-signature Content-Type: application/PKCS7-mime Content-Type: application/EDI-X12 Content-Type: application/EDIFACT Content-Type: application/edi-consent Content-Type: application/XML 22] below, identifying the sender/receiver of a data exchange. A value may be company specific (e.g., a Data Universal Numbering System (DUNS) number), or it may be simply some string mutually acceptable to both trading partners used to identify each to the other.
AS3-text = "!" / ; printable ASCII characters %d35-91 / ; except double-quote (%d34) %d93-126 ; or backslash (%d92) AS3-qtext = AS3-text / SP ; allow space only in quoted text AS3-quoted-pair = "\" DQUOTE / ; \" or "\" "\" ; \\ AS3-quoted-name = DQUOTE 1*128( AS3-qtext / AS3-quoted-pair) DQUOTE AS3-atomic-name = 1*128AS3-text AS3-name = AS3-atomic-name / AS3-quoted-name Note: SP and DQUOTE are defined in [ABNF]RFC 4234. The AS3-From header value and the AS3-To header value MUST each be an AS3-name comprising 1 to 128 printable ASCII characters. The header MUST NOT be folded, and the value for each of these headers is case- sensitive. The AS3-quoted-name SHOULD be used only if the AS3-name does not conform to AS3-atomic-name. The AS3-To and AS3-From header fields MUST be present in all AS3 messages and AS3 MDNs. Implementations that map entities such as EDI identifiers/qualifiers to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From text values to a subset of the full set defined above, but they may not extend that set. If the AS3-From or the AS3-To or the association of the two header values is determined to be invalid or unknown to the receiving system, the receiving system MAY respond with an unsigned MDN containing an explanation of the error if the sending system requested an MDN, but it is not required to return an MDN under those circumstances.
package the document. A user agent MUST NOT reject a message if the version header is missing. AS3-Version: 1*DIGIT . 1*DIGIT A version header value of "1.1" indicates an implementation can support EDIINT data compression . A user agent MUST NOT send compressed messages to trading partners who do not use a version header of "1.1" or greater. 3]. This is addressed by RFC 2228 , and the use of one of the security mechanisms described therein is strongly encouraged. Specifically, conforming implementations of AS3 SHALL employ FTP client/servers that support the AUTH command described within . While any authentication mechanism based upon  MAY be utilized, AUTH TLS (as described in ) MUST be supported. (Note that  relies on TLS Version 1.0 , not Version 1.1 .) Section 188.8.131.52, efficiently reduces transmission requirements for many data types (including both XML and traditional EDI data). Additionally, some FTP implementations support compression as well.
An AS3 message OPTIONALLY MAY contain the following outer headers: Subject AS3-Version (assumed to be 1.0 if not present) Content-Length An AS3 message requesting a receipt MUST contain a Disposition- Notification-To header and MAY contain a Disposition-Notification- Options header (if the receipt is to be signed). Additional headers MAY be present but are ignored. 1] SHALL NOT be used. Section 3.6.4 of RFC 2822 : "<" id-left "@" id-right ">". Message-Id length is a maximum of 998 characters. Message-Id SHOULD be globally unique; id-right should be something unique to the sending host environment (e.g., a host name). When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value. NOTE: When creating the Original-Message-Id header in an MDN, always use the exact syntax contained in the original message: do not strip or add "angle brackets".
RFC 3798 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message. The following support for signed receipts is REQUIRED: 1) The ability to create a multipart/report; where the report-type = disposition-notification. 2) The ability to calculate a message integrity check (MIC) on the received message. The calculated MIC value will be returned to the sender of the message inside the signed receipt. 3) The ability to create a multipart/signed content with the message disposition notification as the first body part, and the signature as the second body part. 4) The ability to return the signed receipt to the sending trading partner. The signed receipt is used to notify a sending trading partner that requested the signed receipt that: 1) The receiving trading partner acknowledges receipt of the sent EC Interchange. 2) If the sent message was signed, then the receiving trading partner has authenticated the sender of the EC Interchange. 3) If the sent message was signed, then the receiving trading partner has verified the integrity of the sent EC Interchange. Regardless of whether the EDI/EC Interchange was sent in S/MIME format or not, the receiving trading partner's UA MUST provide the following basic processing: 1) If the sent EDI/EC 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/EC 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) is decrypted using the sender's public key. b) A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) 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 message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality. 4) The receiving trading partner formats the MDN and sets the calculated MIC into the "Received-content-MIC" 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 second part of the multipart/signed is as follows: S/MIME: protocol = "application/pkcs7-signature". 8) The signature information is formatted according to S/MIME specifications. The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multipart MIME content type. When the EDI Interchange is part of a multipart MIME content type, the MIC MUST be calculated across the entire multipart content, including the MIME headers. The signed MDN, when received by the sender of the EDI Interchange can be used by the sender: 1) As an acknowledgment that the EDI Interchange was sent, and then 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 MDN portion of the signed receipt. 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 EC Interchange (and 1767 MIME headers) in the "Received-content-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 MDN is successfully verified by the sender with the receiving trading partner's public key and the returned MIC value inside the MDN is the same as the digest of the original message. Section 7.4.4 for additional programming notes. RFC 3798. 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" ":" ftpurl This syntax is a residual of the use of MDN's in an SMTP transfer. Since this specification is adjusting the functionality from SMTP to
FTP and retaining as much as possible from the  functionality, the ftpurl must be present. The ftpurl field is specified as an RFC 1738 <URL:"ftp://" login [ "/" fpath [ ";type=" ftptype ]]>, and while it MUST be present, it may be ignored if the ftpurl points to an unknown location. If the ftpurl points to an unknown location, it is RECOMMENDED that the mdn is returned back to a known ftpurl for the sender of the received message. For requesting MDN-based receipts, the originator supplies the required extension headers that precede the message body. The header "tags" are as follows: A Disposition-notification-to header is added to indicate that a message disposition notification is requested. This header is specified in . A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of the MDN. Other headers, especially "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of an MDN to aid in identifying the original message. Disposition-notification-options identifies characteristics of the message. The following Disposition notification is in accordance with . EXAMPLE: Disposition-notification-to: // Requests the MDN ftp://host:port/inbox // Location to return MDN Disposition-notification-options: // The signing options for MDN signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1, md5 Disposition-notification-options syntax: Disposition-notification-options = "Disposition-Notification-Options:" disposition-notification-parameters disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance ", " value *("," value) importance = "required" / "optional" attribute = "signed-receipt-protocol" / "signed-receipt-micalg" So the Disposition-notification-options string could be: signed-receipt-protocol=optional, <protocol symbol>; signed-receipt-micalg=optional, <micalg1>, <micalg2>,...; The currently supported value for <protocol symbol> is "pkcs7- signature" for the S/MIME detached signature format. The currently supported values for MIC algorithm <micalg> values are: Algorithm Value Used -------- ------- MD5 md5 SHA-1 sha1 Receiving agents SHOULD be able to recover gracefully from a <micalg> parameter value that they do not recognize. The semantics of the "signed-receipt-protocol" parameter is as follows: 1) The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed- receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester. The "signed-receipt-micalg" parameter is a list of MIC algorithms preferred by the requester for use in signing the returned receipt and calculating the micalg in the Received-content-MIC header. The list of MIC algorithms should be honored by the recipient from left to right. Both the "signed-receipt-protocol" and the "signed-receipt-micalg" option parameters are REQUIRED when requesting a signed receipt. 2) The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning: Parameters with an importance of "Optional" permit a UA that does not understand the particular options parameter to still generate an MDN in response to a request for an MDN. A UA that does not
understand the "signed-receipt-protocol" parameter, or the "signed-receipt-micalg" parameter, will obviously not return a signed receipt. The importance of "Optional" is used for the signed receipt parameters because it is RECOMMENDED that an MDN be returned to the requesting trading partner even if the recipient could not sign it. The returned MDN will contain information on the disposition of the message as well as on why the MDN could not be signed. See the Disposition field in Section 7.5 for more information. Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction must be determined by the trading partners. Typically, if a signed receipt is required by the trading relationship and is not received, the transaction will likely not be considered valid. RFC 3798, "An Extensible Message Format for Message Disposition Notifications". The "rules" for processing a receipt-request follow: 1) When a receipt is requested, explicitly specifying that the receipt be signed, then the receipt MUST be returned with a signature unless conditions (2) or (3) below are applicable. 2) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support either the requested protocol format, or requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned. 3) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient is unable to compute the digest (e.g., message was encrypted, and recipient unable to decrypt), then the recipient SHOULD NOT return "Received-content- MIC" in the MDN to the requestor. If the MDN sets the disposition (e.g., "processed/error: decryption-failed") appropriately, then the "Received-content-MIC" may be returned, but the value must be discarded.
4) When a signature is not explicitly requested, or if the signed receipt request parameter is not recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient. 5) If a message is received without a request for a receipt, then a receipt (signed or unsigned) MAY be returned. The "Received-content-MIC" MUST be calculated as follows: - For any signed messages, the MIC to be returned is calculated on the RFC 1767 MIME header and content. Canonicalization as specified in RFC 1848 MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize. - For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated. - For unsigned, un-encrypted messages, the MIC MUST be calculated over the message contents prior to Content-Transfer-Encoding and without the MIME or any other RFC 822  headers, since these are sometimes altered or reordered by message transfer agents (MTAs). 6] except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message- headers. The format of the AS3-MDN is MDN, no signature -RFC822/2045 -RFC3798 (message/disposition-notification)
Section 7 of RFC 3798  except that the RFC 3798 disposition-field has been replaced with the AS3- disposition-field and that the AS3-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS3-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by prepending "AS3-". Entities below that do not differ from RFC 3798 are not necessarily further defined in this document. Refer to RFC 3798  and RFC 4234  for entities that are not further defined in this document. AS3-disposition-field = "Disposition:" disposition-mode ";" AS3-disposition-type [ "/" AS3-disposition-modifier] disposition-mode = action-mode "/" sending-mode action-mode = "manual-action" / "automatic-action" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" AS3-disposition-type = "processed" / "failed" AS3-disposition-modifier = ( "error" / "warning" ) / AS3-disposition-modifier-extension AS3-disposition-modifier-extension = "error: authentication-failed" / "error: decompression-failed" / "error: decryption-failed" / "error: insufficient-message-security" / "error: integrity-check-failed" / "error: unexpected-processing-error" / "warning: " AS3-MDN-warning-description / "failure: " AS3-MDN-failure-description AS3-MDN-warning-description = *( TEXT ) AS3-MDN-failure-description = *( TEXT ) AS3-received-content-MIC-field = "Received-content-MIC:" encoded-message-digest "," digest-alg-id CRLF
encoded-message-digest = 1*( ALPHA / DIGIT / "/" / "+" ) *3"=" ;( i.e. base64( message-digest ) ) digest-alg-id = "sha1" / "md5" The "Received-content-MIC" extension field is set after the integrity of the received message is verified. The MIC is the base64-encoded message-digest computed over the received message with a hash function. This field is required for signed receipts but optional for unsigned receipts. For details defining the specific content over which the message-digest is to be computed, see Section 7.3.1 of this document. The algorithm used to calculate the message digest MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, the message-digest MUST be calculated using the algorithm specified by the "micalg" value in the Disposition-Notification-Options header. When no signature is received and no micalg parameter is provided, then the SHA-1 algorithm MUST be used to calculate the digest. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify non-repudiation of receipt. AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case-insensitive (cf. RFC 3798, Section 3.1.1). AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3- disposition-modifier values that are defined above, and user-supplied *( TEXT ) values are also case-insensitive. AS3 implementations MUST NOT make assumptions regarding the values supplied for AS3-MDN- warning-description or AS3-MDN-failure-description or for the values of any (optional) error, warning, or failure fields. RFC 3462 and RFC 3798 for the formatting of the Content-Type entity-headers for the MDN. 3. Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action, rather than an explicit instruction by the user for this message.
4. Use an action-mode of "manual-action" when the disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action. 5. Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so. 6. Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent. 7. The sending-mode "MDN-sent-manually" is ONLY meaningful with "manual-action", not with "automatic-action". 8. The "failed" disposition type MAY NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations. 9. An AS3 implementation MUST present to its trading partners an FTP-compliant server interface where inbound documents and MDNs are received. 10. An AS3 implementation MUST be able to retrieve inbound messages from its currently configured FTP server interface. Note: Programming Notes 9 and 10 do not imply any specific method for supplying the FTP server interface. But, they do allow for several different types of implementations. Some vendors may choose to imbed an FTP-compliant server interface within their product, and others may choose to utilize off-the-shelf FTP servers to supply the required FTP server interface. Some may choose to utilize hosting services provided by their trading partner or by a third-party hosting service. Whichever method is utilized, an AS3 implementation MUST support rules 9 and 10. 11. AS3 implementations MAY imbed an FTP server interface within their product. 12. AS3 implementations MUST be configurable to allow the use of an external FTP hosting service. Note: An external FTP hosting service may be hosted by a third-party or possibly hosted by your trading partner.
13. An AS3 implementation MUST be able to send business documents and MDNs to a trading partner's currently configured FTP server interface. 14. An AS3 implementation may imbed FTP client code into their product or use a third-party FTP client. 15. Example Configurations 1. Peer to Peer Trading Partner A (TPA) is using a local FTP server, and Trading Partner B (TPB) is using an imbedded FTP server. [A Client] ----( connect )----> [B Server] [A Client] ----( send )-------> [B Server] [AS3-Message] [A Client] ----( disconnect )-> [B Server] [A Server] <---( connect )----- [B Client] [A Server] <---( send )-------- [B Client] [AS3-MDN]] [A Server] <---( disconnect )-- [B Server] [A Client] <---( GET )--------- [A Server] 2. Third-Party Hosting Both parties are using the same third-party-hosted FTP server. [A Client] ----( connect )----> [Hosted Server] [A Client] ----( send )-------> [Hosted Server] [AS3-Message] [A Client] ----( disconnect )-> [Hosted Server] [Hosted Server]( GET )--------> [B Client] [Hosted Server] <---( connect )----- [B Client] [Hosted Server] <---( send )-------- [B Client] [AS3-MDN]] [Hosted Server] <---( disconnect )-- [B Client] [A Client] <---( GET )--------- [Hosted Server] 3. Trading Partner Hosting TPA is using the imbedded FTP server hosted by TPB. [A Client] ----( connect )----> [B Server] [A Client] ----( send )-------> [B Server] [AS3-Message] [A Client] ----( disconnect )-> [B Server] [B Server] <---( connect )----- [B Client] [B Server] <---( send )-------- [B Client] [AS3-MDN]] [B Server] <---( disconnect )-- [B Client] [A Client] <---( GET )--------- [B Server]
values that should be used in the case where the message content is being rejected or ignored should be specified in the MDN "disposition-field" as below. (An example of this case is when the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, so the EDI UA chooses not to process the message contents itself.) Disposition: "disposition-mode"; failed/Failure: unsupported Format The "failed" AS3-disposition-type should be used when a failure occurs that prevents the proper generation of an MDN. For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message- integrity-check (MIC) algorithm. The "failure:" AS3-disposition-modifier-extension should be used with an implementation-defined description of the failure. Further information about the failure may be contained in a failure- field. The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". Implementations WILL support any printable textual characters after the Failure disposition-type. For use in Internet EDI, the following "failed" values are pre- defined and MUST be supported: "Failure: unsupported format" "Failure: unsupported MIC-algorithms"
For use in Internet EDI, the following "error" "disposition-modifier" values are defined: "Error: decryption-failed" The receiver could not decrypt the message contents. "Error: authentication-failed" The receiver could not authenticate the sender. "Error: integrity-check-failed" The receiver could not verify content integrity. "Error: insufficient-message-security" The security level of the message did not match the agreed level between TPs. "Error: decompression-failed" The receiver could not decompress the message contents. "Error: unexpected-processing-error" A catch-all for any additional processing errors. An example of how the "disposition-field" would look when processing errors, other than content, are detected is as follows: EXAMPLE Disposition: "disposition-mode"; processed/Error: decryption-failed
A "warning:" AS3-disposition-modifier-extension should be used to combine the indication of a warning with an implementation-defined description of the warning. Further information about the warning may be contained in a warning-field. For use in Internet EDI, the following "warning" "disposition- modifier" values are defined: "Warning: authentication-failed, processing continued" An example of how the "disposition-field" would look when processing warnings, other than content, are detected is as follows: EXAMPLE Disposition: "disposition-mode"; processed/Warning: authentication-failed, processing continued
21]: 40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents should inform senders and recipients the relative cryptographic strength of messages. Extracted from S/MIME Version 3.1 Certificate Handling : When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures has not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it. Some of the many places where signature and certificate checking might fail include: - no Internet mail addresses in a certificate matches the sender of a message, if the certificate contains at least one mail address - no certificate chain leads to a trusted CA - no ability to check the Certificate Revocation List (CRL) for a certificate - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails. The following certificate types MUST be supported. With URL Without URL Self Certified Certification Authority Certified The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root". Additionally, the certificate hash should match the hash recomputed by the receiver.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.  Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.  Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.  Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
 Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.  Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.  Resnick, P., "Internet Message Format", RFC 2822, April 2001.  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.  Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
 Harding, T., "Compressed Data for EDIINT", Work in Progress, January 2007.  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
& Content-Type: multipart/report; & Report-Type=disposition-notification; & boundary="----=_Part_56_1672293592.1028122454656" & &------=_Part_56_1672293592.1028122454656 &Content-Type: text/plain &Content-Transfer-Encoding: 7bit & &MDN for - & Message ID: <200207310834482A70BF63@host.com> & From: cyclone & To: "trading partner" & Received on: 2002-07-31 at 09:34:14 (EDT) & Status: processed & Comment: This is not a guarantee that the message has been & completely processed or understood by the receiving translator & &------=_Part_56_1672293592.1028122454656 & Content-Type: message/disposition-notification & Content-Transfer-Encoding: 7bit & & Reporting-UA: AS3 Server & Original-Recipient: rfc822; "trading partner" & Final-Recipient: rfc822; "trading partner" & Original-Message-ID: <200207310834482A70BF63@host.com> & Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1 & Disposition: automatic-action/MDN-sent-automatically; processed & &------=_Part_56_1672293592.1028122454656-- ------=_Part_57_648441049.1028122454671 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA ------=_Part_57_648441049.1028122454671-- Notes: 1. The lines proceeded with "&" are what the signature is calculated over. 2. For details on how to prepare the multipart/signed with protocol="application/pkcs7-signature", see RFC 3851 , "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification".
3. Note that the textual first body part of the multipart/report can be used to include a more detailed explanation of the error conditions reported by the disposition headers. The first body part of the multipart/report, when used in this way, allows a person to better diagnose a problem in detail. 4. As specified by RFC 3462 , returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. However, it is RECOMMENDED that this body part be omitted or left blank.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.