The following errata report has been submitted for RFC7515,
"JSON Web Signature (JWS)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8508

--------------------------------------
Type: Technical
Reported by: Ryan Desmond <[email protected]>

Section: Sec 2, Appendix C

Original Text
-------------
2.  Terminology

   These terms are defined by this specification:

   Base64url Encoding
      Base64 encoding using the URL- and filename-safe character set
      defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
      characters omitted (as permitted by Section 3.2) and without the
      inclusion of any line breaks, whitespace, or other additional
      characters.  Note that the base64url encoding of the empty octet
      sequence is the empty string.  (See Appendix C for notes on
      implementing base64url encoding without padding.)


Appendix C.  Notes on Implementing base64url Encoding without Padding

   This appendix describes how to implement base64url encoding and
   decoding functions without padding based upon standard base64
   encoding and decoding functions that do use padding.

   To be concrete, example C# code implementing these functions is shown
   below.  Similar code could be used in other languages.

   ...

     static byte [] base64urldecode(string arg)
     {
       string s = arg;
       s = s.Replace('-', '+'); // 62nd char of encoding
       s = s.Replace('_', '/'); // 63rd char of encoding
       switch (s.Length % 4) // Pad with trailing '='s
       {
         case 0: break; // No pad chars in this case
         case 2: s += "=="; break; // Two pad chars
         case 3: s += "="; break; // One pad char
         default: throw new System.Exception(
           "Illegal base64url string!");
       }
       return Convert.FromBase64String(s); // Standard base64 decoder
     }

   As per the example code above, the number of '=' padding characters
   that needs to be added to the end of a base64url-encoded string
   without padding to turn it into one with padding is a deterministic
   function of the length of the encoded string.  Specifically, if the
   length mod 4 is 0, no padding is added; if the length mod 4 is 2, two
   '=' padding characters are added; if the length mod 4 is 3, one '='
   padding character is added; if the length mod 4 is 1, the input is
   malformed.

Corrected Text
--------------
2.  Terminology

   These terms are defined by this specification:

   Base64url Encoding
      Base64 encoding using the URL- and filename-safe character set
      defined in Section 5 of RFC 4648 [RFC4648], all trailing '='
      characters SHOULD be omitted (as permitted by Section 3.2) and
      any line breaks, whitespace, or other additional characters SHALL
      be excluded.  Note that the base64url encoding of the empty octet
      sequence is the empty string.  (See Appendix C for notes on
      implementing base64url encoding without padding.)


Appendix C.  Notes on Implementing base64url Encoding without Padding

      ...

      NOTE: The decoding function allows padded input, which is not recommended.

Notes
-----
The definition for Base64url is more strict than RFC4648, but doesn't qualify 
that with keyword from RFC 2119.  The corrected text uses RFC 2119 keywords to 
be more specific and consistent.  I do propose allowing but discouraging 
extraneous padding, which is currently ambiguous.  An alternate solution would 
be using SHALL be omitted in the definition and either adding a note in 
appendix C or a conditional to throw an exception for non-compliant input.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7515 (draft-ietf-jose-json-web-signature-41)
--------------------------------------
Title               : JSON Web Signature (JWS)
Publication Date    : May 2015
Author(s)           : M. Jones, J. Bradley, N. Sakimura
Category            : PROPOSED STANDARD
Source              : Javascript Object Signing and Encryption
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to