RFC Errata
Found 7 records.
Status: Verified (4)
RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005
Source of RFC: ediint (app)
Errata ID: 3028
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12
Section 7.4.3 says:
digest-alg-id = "sha1" | "md5"
It should say:
digest-alg-id = "sha-1" | "sha1" | "md5" ; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry ; It should be maintained for backwards compatibility
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Split off erratum 1974
Errata ID: 3029
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12
Section 7.3 says:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
It should say:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha-1 or sha1
MD5 md5
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility.
Errata ID: 1575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: r. deutsch
Date Reported: 2008-10-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section 4.1 says:
Any difference between AS2 implantations and RFCs are
^^^^^^^^^^^^^
mentioned specifically in the sections below.
It should say:
Any difference between AS2 implementations and RFCs are
^^^^^^^^^^^^^^^
mentioned specifically in the sections below.
Notes:
The word "implantations" should be "implementations".
Errata ID: 4743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2016-07-15
Verifier Name: Orie Steele
Date Verified: 2024-03-29
Section A.3, A.4 says:
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]
Moberg & Drummond Standards Track [Page 44]
RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
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.
Moberg & Drummond Standards Track [Page 45]
RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
------=_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-
It should say:
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:58201/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:58201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:58101
Connection: close
Content-Length: 3428
[omitted binary encrypted data]
Moberg & Drummond Standards Track [Page 44]
RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
A.4. Asynchronous MDN for Message A.3, Above
POST / HTTP/1.1
Host: 10.240.1.2:58201
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:58201/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:58201/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.
Moberg & Drummond Standards Track [Page 45]
RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
Reporting-UA: AS2@test:58101
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-
Notes:
Port numbers used in examples need to either refer to the intended service (e.g., 80 for HTTP) or use dynamic ports (49152-65535). The examples provided used examples in the assigned User ports range (8101, 8201) both as source and destination, and neither is appropriate for the example service described.
The simplest change was to add a "5" in front of the numbers, placing them in the dynamic range (e.g., 58101, 58201).
Status: Rejected (3)
RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005
Source of RFC: ediint (app)
Errata ID: 2973
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Pete Resnick
Date Rejected: 2011-11-12
Section 7.3 says:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
It should say:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha-1 or sha1
MD5 md5
SHA-224 sha-224
SHA-256 sha-256
SHA-384 sha-384
SHA-512 sha-512
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
A separate erratum was issued with the SHA1/SHA-1 fix. The additional algorithms cannot be added in an erratum.
Errata ID: 2974
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12
Section 7.4.3 says:
digest-alg-id = "sha1" | "md5"
It should say:
digest-alg-id = "sha-1" | "sha-224" | "sha-256" | "sha-384" | "sha-512" | "sha1" | "md5" ; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry ; It should be maintained for backwards compatibility
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Because this erratum really requires publication of a replacement RFC, in accordance with the "IESG Processing of RFC Errata for the IETF Stream" <http://www.ietf.org/iesg/statement/errata-processing.html> the appropriate processing is to reject it.
Errata ID: 3055
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: JP McCrory
Date Reported: 2011-12-20
Rejected by: Pete Resnick
Date Rejected: 2011-12-29
Throughout the document, when it says:
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Warning: An identical message already exists at the
destination server.
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
It should say:
(Remove/replace warning examples from section '7.5.6. Backward Compatibility with Disposition Type, Modifier, and Extension' - see notes) 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. (Add following comment to above section.) If duplicate is detected the disposition should be returned with 'processed' and without an error or warning status unless other errors occurred. Sending an error or warning on a duplicate can result in an endless communication loop between retransmissions and resulting error/warnings.
Notes:
Endless communication loops are a problem with AS2 and this is only supported by the RFC and its multiple examples of 'duplicate-document'. What most commonly happens is a file is sent synchronously to one of our partners but our two minute timeout in holding the connection for an MDN is reached. The recipients AS2 software generated the MDN but doesn't recognize the connection is no longer available for MDN return and as a result non-repudiation of receipt has not occurred. The file is later resent to the partner who then promptly sends an MDN with a processed/warning condition again not meeting our threshold of non-repudiation of receipt.
We have three or four occurrences of this exact scenario occur every week and because the RFC undercuts our ability to get AS2 software clients to address this issue at all many of our supplier are forced to manually mark their files as transmitted manually through a mailbox UI we have online.
We understand the need for duplicate detection and have our own in place but implemented in a way that endless communication loops cannot occur. Balanced duplicate detection is advised because to stringent of duplicate detection especially done within the communication protocol itself if problematic. An example of this would be partner who receive a file but then have issues in processing the data and did not take an archive of their data before processing as many do. These partners have requested our system to resend their data AS2 only to find the data is rejected before the file is received because it has the same 'message-id' as it did the first time it was sent and their AS2 software still have the message-id stored in their software's receiving records.
Again I support duplicate checking but it needs to be better defined for AS2 especially the elimination of the duplicate warning with the understanding of the unending communication loops that it can create through no fault of anyone just a missed MDN on the initial communication is all it takes.
--VERIFIER NOTES--
Aside from this being a poorly formatted report (it does not give proper original/change text and should probably have been split into multiple errata), none of this is at all appropriate for an erratum. This is a change to the examples and to add an additional warning given operational experience. This needs to be done via a document update, not an erratum.