RFC Errata
Found 5 records.
Status: Verified (1)
RFC 5849, "The OAuth 1.0 Protocol", April 2010
Note: This RFC has been obsoleted by RFC 6749
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 2550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alasdair McIntyre
Date Reported: 2010-10-12
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Throughout the document, when it says:
Section 3.1 oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D" Section 3.4.1.1 oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D" Section 3.4.1.3.1 oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"
It should say:
Section 3.1 oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D" Section 3.4.1.1 oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D" Section 3.4.1.3.1 oauth_signature="r6%2FTJjbCOr97%2F%2BUU0NsvSne7s5g%3D"
Notes:
(Apologies - this supercedes Errata ID 2549).
The signatures in sections 3.1, 3.4.1.1, and 3.4.1.3.1 of the RFC have mistakenly been calculated as if with "GET". I have supplied the correct "POST" signatures in the corrected text.
For reference, here is the perl script I used to calculate the signatures:
#!/usr/bin/perl
use strict;
use warnings;
use Digest::HMAC_SHA1;
use URI::Escape;
use MIME::Base64;
my $unsafe = '^-._~A-Za-z0-9';
my $client_secret = 'j49sk3j29djd';
my $token_secret = 'dh893hdasih9';
my $key = join('&', $client_secret, $token_secret);
my $uri_base = 'http%3A%2F%2Fexample.com%2Frequest';
my $params = join('', qw(
a2%3Dr%2520b%26a3%3D2%2520q%26a3%3Da%26b5%3D
%253D%25253D%26c%2540%3D%26c2%3D%26oauth_con
sumer_key%3D9djdj82h48djs9d2%26oauth_nonce%3
D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
A1%26oauth_timestamp%3D137131201%26oauth_tok
en%3Dkkk9d7dh3k39sjv7
));
foreach my $method ('GET', 'POST') {
my $base_sig = join('&', $method, $uri_base, $params);
my $bin_sig = Digest::HMAC_SHA1::hmac_sha1($base_sig, $key);
my $b64_sig = MIME::Base64::encode_base64($bin_sig, '');
my $enc_sig = URI::Escape::uri_escape($b64_sig, $unsafe);
printf "%-8s %s\n", $method, $enc_sig;
}
Status: Held for Document Update (3)
RFC 5849, "The OAuth 1.0 Protocol", April 2010
Note: This RFC has been obsoleted by RFC 6749
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 2718
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Florian Sey
Date Reported: 2011-02-14
Held for Document Update by: Peter Saint-Andre
Section 3.4.1.3.1 says:
contains the following (fully decoded) parameters used in the signature base sting:
It should say:
contains the following (fully decoded) parameters used in the signature base string:
Notes:
typographical error
Errata ID: 2860
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: houtsnip
Date Reported: 2011-07-13
Held for Document Update by: Peter Saint-Andre
Section 3.4.1.1. says:
5. The request parameters as normalized in Section 3.4.1.3.2, after being encoded (Section 3.6).
It should say:
5. The request parameters as normalized in Section 3.4.1.3.2, and then encoded (Section 3.6). [or ...] 5. The normalized request parameter string (see Section 3.4.1.3.2), after being encoded.
Notes:
It is not clear, from the way you write, whether you mean that the request parameters are first encoded, and then normalized, or the other way round.
When the sentence is read out of context, the meaning seems to be that the request parameters are first encoded, and then normalized, which is not what is actually meant. The real meaning can only be understood by looking at the sentence preceding the list: 'The signature base string is constructed by concatenating together, in order, the following HTTP request elements'. Then you understand that the request parameters are not *normalized* 'after being encoded', but are *concatenated* 'after being encoded'.
It was confusing enough for me, and my first language is English. Until I started filling in this erratum (and until I really looked at it closely), I really thought it was a technical error, and you'd just got it wrong.
Errata ID: 3328
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Day
Date Reported: 2012-08-21
Held for Document Update by: Sean Turner
Section 4.12. says:
Those designing additional signature methods, should evaluated the compatibility of the signature base string with their security requirements.
It should say:
Those designing additional signature methods should evaluate the compatibility of the signature base string with their security requirements.
Notes:
Remove comma after "methods" and change "evaluated" to "evaluate".
Status: Rejected (1)
RFC 5849, "The OAuth 1.0 Protocol", April 2010
Note: This RFC has been obsoleted by RFC 6749
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 2549
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alasdair McIntyre
Date Reported: 2010-10-12
Rejected by: Peter Saint-Andre
Date Rejected: 2010-11-18
Section 3.4.1.3.1. says:
For example, the HTTP request: POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm="Example", oauth_consumer_key="9djdj82h48djs9d2", oauth_token="kkk9d7dh3k39sjv7", oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131201", oauth_nonce="7d8f3e4a", oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D" c2&a3=2+q contains the following (fully decoded) parameters used in the signature base sting:
It should say:
For example, the HTTP request: POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Authorization: OAuth realm="Example", oauth_consumer_key="9djdj82h48djs9d2", oauth_token="kkk9d7dh3k39sjv7", oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131201", oauth_nonce="7d8f3e4a", oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D" c2&a3=2+q contains the following (fully decoded) parameters used in the signature base sting:
Notes:
It looks like "GET" was updated to "POST" in a previous revision, but the oauth_signature was not updated at the same time. All other instances of this change from GET to POST did have the oauth_signature field correctly updated.
--VERIFIER NOTES--
Peter: This is superseded by erratum #2550.