Subject: Re: [jose] [Editorial Errata Reported] RFC7517 (6907)

From: Chris Smiley <[email-masked]>
Date: Fri, 1 Apr 2022 15:51:40 -0700

Greetings,

We are unable to verify this erratum that the submitter marked as editorial.  
Please note that we have changed the “Type” of the following errata 
report to “Technical”.  As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

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

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/cs

> On Mar 30, 2022, at 8:49 AM, RFC Errata System <[email-masked]> wrote:
> 
> The following errata report has been submitted for RFC7517,
> "JSON Web Key (JWK)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6907
> 
> --------------------------------------
> Type: Editorial
> Reported by: Weijun Wang <[email-masked]>
> 
> Section: C.7
> 
> Original Text
> -------------
> C.7.  Additional Authenticated Data
> 
>   Let the Additional Authenticated Data encryption parameter be
>   ASCII(BASE64URL(UTF8(JWE Protected Header))).  This value is:
> 
>   [123, 34, 97, 108, 103, 34, 58, 34, 80, 66, 69, 83, 50, 45, 72, 83,
>   50, 53, 54, 43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 112, 50, 115, 34,
>   58, 34, 50, 87, 67, 84, 99, 74, 90, 49, 82, 118, 100, 95, 67, 74,
>   117, 74, 114, 105, 112, 81, 49, 119, 34, 44, 34, 112, 50, 99, 34, 58,
>   52, 48, 57, 54, 44, 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67,
>   66, 67, 45, 72, 83, 50, 53, 54, 34, 44, 34, 99, 116, 121, 34, 58, 34,
>   106, 119, 107, 43, 106, 115, 111, 110, 34, 125]
> 
> Corrected Text
> --------------
> C.7.  Additional Authenticated Data
> 
>   Let the Additional Authenticated Data encryption parameter be
>   ASCII(BASE64URL(UTF8(JWE Protected Header))).  The value is:
> 
>   [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 81, 81, 107, 86,
>   84, 77, 105, 49, 73, 85, 122, 73, 49, 78, 105, 116, 66, 77, 84, 73,
>   52, 83, 49, 99, 105, 76, 67, 74, 119, 77, 110, 77, 105, 79, 105, 73,
>   121, 86, 48, 78, 85, 89, 48, 112, 97, 77, 86, 74, 50, 90, 70, 57, 68,
>   83, 110, 86, 75, 99, 109, 108, 119, 85, 84, 70, 51, 73, 105, 119,
>   105, 99, 68, 74, 106, 73, 106, 111, 48, 77, 68, 107, 50, 76, 67, 74,
>   108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74,
>   68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 105, 119, 105, 89, 51, 82,
>   53, 73, 106, 111, 105, 97, 110, 100, 114, 75, 50, 112, 122, 98, 50,
>   52, 105, 102, 81]
> 
> Notes
> -----
> The array in the original text is the content of JWE Protected Header. The corrected text shows the content of the AAD parameter.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7517 (draft-ietf-jose-json-web-key-41)
> --------------------------------------
> Title               : JSON Web Key (JWK)
> Publication Date    : May 2015
> Author(s)           : M. Jones
> Category            : PROPOSED STANDARD
> Source              : Javascript Object Signing and Encryption
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 2 Apr 2022 03:22:46 +0200

>> The array in the original text is the content of JWE Protected Header. The corrected text shows the content of the AAD parameter.

I don’t understand this note, but what I see is that the original example is missing out on the base64url step (starts with 123 34, which are the decimal ASCII codes for {“, i.e., the raw JSON), while the supplied corrected example does perform it (starts with 101 121, which is ey — the first characters of the base64-url string that can also be seen at the end of C.2).

I haven’t checked whether this error propagates further down.

Grüße, Carsten

---

From: Wei-Jun Wang <[email-masked]>
Date: Mon, 4 Apr 2022 02:25:34 +0000

Sorry if my words are confusing. By AAD, I meant Additional Authenticated Data, which is defined as the BASE64 encoding of the JWE Protected Header.

The error does not propagate to anywhere else. I’ve confirmed that the AEAD calculation later does used the BASE64 encoded string. 

Thanks,
Weijun

> On Apr 1, 2022, at 21:23, Carsten Bormann <[email-masked]> wrote: