third-party authentication of trading partners, as well as the
attributes of the trading relationship.
9. Security Considerations
This entire document is concerned with secure transport of business
to business data, and it considers both data confidentiality and
authentication issues.
Extracted from RFC 3851 [7]:
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 Triple DES 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 of the relative cryptographic strength
of messages.
Extracted from RFC 3850 [12]:
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 have 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 situations in which signature and certificate
checking might fail include the following:
o No certificate chain leads to a trusted CA.
o No ability to check the Certificate Revocation List (CRL) for a
certificate.
o An invalid CRL was received.
o The CRL being checked is expired.
o The certificate is expired.
o 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. See RFC 3280 for additional information on certificate path
validation.
The following are additional security considerations to those listed
in [7] and [12].
9.1. NRR Cautions
This specification seeks to provide multiple mechanisms that can be
combined in accordance with local policies to achieve a wide range of
security needs as determined by threat and risk analyses of the
business peers. It is required that all these mechanisms be
implemented by AS2 software so that the software has capabilities
that promote strong interoperability, no matter what policies are
adopted.
One strong cluster of mechanisms (the secure transmission loop) can
provide good support for meeting the evidentiary needs of non-
repudiation of receipt by the original sender and by a third party
supplied with all stated evidence. However, this specification does
not itself define non-repudiation of receipt nor enumerate its
essential properties because NRR is a business analysis and/or legal
requirement, and not relevantly defined by a technical applicability
statement.
Some analyses observe that non-repudiation of receipt presupposes
that non-repudiation of the sender of the original message is
obtained, and further that non-repudiation should be implemented by
means of digital signature on the original message. To satisfy
strict NRR evidence, authentication and integrity MUST be provided by
some mechanism, and the RECOMMENDED mechanism is digital signatures
on both the original message and the receipt message.
Given that this specification has selected several mechanisms that
can be combined in several ways, it is important to realize that if a
digital signature is omitted from the original message, in order to
satisfy the preceding analysis of NRR requirements, some
authentication mechanism MUST accompany the request for a signed
receipt and its included Received-content-MIC value. This
authentication might come from using client-side SSL, authentication
via IPsec, or HTTP authentication (while using SSL). In any case,
records of the message content, its security basis, and the digest
value need to be retained for the NRR process.
Therefore, if NRR is one of the goals of the policy that is adopted,
by using the mechanisms of the secure transmission loop mentioned
above and by retaining appropriate records of authentication at the
original message sender site, strong evidentiary requirements
proposed for NRR can be fulfilled.
Other ways of proceeding may fall short of fulfilling the most
stringent sets of evidence required for NRR to obtain, but may
nevertheless be part of a commercial trading agreement and, as such,
are good enough for the parties involved. However, if MDNs are
returned unsigned, evidentiary requirements for NRR are weak; some
authentication of the identity of the receiver is needed.
9.2. HTTPS Remark
The following certificate types MUST be supported for SSL server-side
certificates:
o with URL in the Distinguished Name Common Name attribute
o without URL in the Distinguished Name Common Name attribute
o self-signed (self-issued)
o certification authority certified
The URL, which matches the source server identity, SHOULD be carried
in the certificate. However, it is not required that DNS checks or
reverse lookups to vouch for the accuracy of the URL or server value.
Because server-side certificates are exchanged, and also trust is
established during the configuration of the trading partner
relationship, runtime checks are not required by implementations of
this specification.
The complete certification chain MUST be included in all
certificates. All certificate verifications MUST "chain to root" or
to an accepted trust anchor. Additionally, the certificate hash
SHOULD match the hash recomputed by the receiver.
9.3. Replay Remark
Because business data documents normally contain transaction ids,
replays (such as resends of not-yet-acknowledged messages) are
discarded as part of the normal process of duplicate detection.
Detection of duplicates by Message-Id or by business transaction
identifiers is recommended.
10. IANA Considerations
RFC 3335 registered two Disposition-Notification-Options parameters
Parameter-name: signed-receipt-protocol
Parameter-name: signed-receipt-micalg
that are also used by this specification (see Section 7.3).
RFC 3335 also registered on MDN Extension field name
Extension field name: Received-content-MIC
that is also used by this specification (see Section 7.4.3).
Registration of the above is therefore NOT needed.
10.1. Registration
This specification defines an extension to the Message Disposition
Notification (MDN) protocol for a disposition-modifier in the
Disposition field of a body of content-type "message/disposition-
notification".
10.1.1. Disposition Modifier ’warning’
Parameter-name: warning
Semantics: See Sections 7.4.3 and 7.5.5 of this document.
11. Acknowledgements
Carl Hage, Karen Rosenfeld, Chuck Fenton, and many others have
provided valuable suggestions that improved this applicability
statement. The authors would also like to thank the vendors who
participated in the Drummond Group Inc. AS2 interoperability testing.
Their contributions led to great improvement in the clarity of this
document.
12. References
12.1. Normative References
[1] 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.
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767,
March 1995.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
Peer-to-Peer Business Data Interchange over the Internet", RFC
3335, September 2002.
[5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification",
RFC 3798, May 2004.
[6] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[8] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
12.2. Informative References
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
Appendix A: Message Examples
NOTE: All examples are provided for illustration only, and are 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.
A.1. Signed Message Requesting a Signed, Synchronous Receipt
POST /receive HTTP/1.0
Host: 10.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@example.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@example.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
--as2BouNdary1as2
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--as2BouNdary1as2--
A.2. MDN for Message A.1, Above
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980
------=_Part_57_648441049.1028122454671
& 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@\"~~foo~~\">
& From: "\" as2Name \""
& To: "0123456780000"
& 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: AS2 Server
&Original-Recipient: rfc822; 0123456780000
&Final-Recipient: rfc822; 0123456780000
&Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
&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 the "S/MIME Message
Specification, PKCS Security Services for MIME".)
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 [8], 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.
A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous
Receipt
Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@example.com
Subject: Async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Receipt-Delivery-Option:
http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428
[omitted binary encrypted data]
A.4. Asynchronous MDN for Message A.3, Above
POST / HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@example.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_337_6452266.1040310218750"
Content-Length: 3103
------=_Part_337_6452266.1040310218750
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="----=_Part_336_6069110.1040310218718"
------=_Part_336_6069110.1040310218718
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
2002 15:04:18 GMT with Subject <async MDN request> has been received.
The EDI Interchange was successfully decrypted, and its integrity was
verified. In addition, the sender of the message, Sender
<as2_company> at Location http://10.240.1.2:8201/exchange/as2_company
was authenticated as the originator of the message. There is no
guarantee, however, that the EDI interchange was syntactically
correct, or that it was received by the EDI application/translator.
------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
------=_Part_336_6069110.1040310218718--
------=_Part_337_6452266.1040310218750
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
------=_Part_337_6452266.1040310218750-
Authors’ Addresses
Dale Moberg
Cyclone Commerce
8388 E. Hartford Drive, Suite 100
Scottsdale, AZ 85255 USA
EMail: dmoberg@cyclonecommerce.com
Rik Drummond
Drummond Group Inc.
4700 Bryant Irvin Court, Suite 303
Fort Worth, TX 76107 USA
EMail: rvd2@drummondgroup.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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 ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.