RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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 GROUP
Area 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 GROUP
Area 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 GROUP
Area 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.

Report New Errata



Advanced Search