Re: [Technical Errata Reported] RFC8188 (8620)

[Martin Thomson <[e-mail]>]

I've taken a look at this, which meant re-learning how this works.

The examples are produced and checked by this script: https://github.com/web-push-libs/encrypted-content-encoding/blob/d2d3a156d4d8b5e51b2cb5cda07d88157b4c34e3/nodejs/test.js#L320

You can run that with: ECE_KEYLOG=1 node test.js aes128gcm verbose checkExamples

You can see that the ciphertext is produced from the 15 bytes of plaintext and a single byte of padding, which is the byte 0x02 (printed in the output as "Ag").

The alternative that is presented here has *two* 0x02 bytes at the end:

00000000: 4920 616d 2074 6865 2077 616c 7275 7302  I am the walrus.
00000010: 02                                       .

I suggest that we REJECT this erratum.

On Fri, Oct 31, 2025, at 07:20, RFC Errata System wrote:
> The following errata report has been submitted for RFC8188,
> "Encrypted Content-Encoding for HTTP".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8620
>
> --------------------------------------
> Type: Technical
> Reported by: Patrick Barrett <[e-mail]>
>
> Section: 3.1
>
> Original Text
> -------------
>    The encrypted data in this example is the UTF-8-encoded string "I am
>    the walrus".  The input-keying material is the value "yqdlZ-
>    tYemfogSmv7Ws5PQ" (in base64url).  The 54-octet content body contains
>    a single record and is shown here using 71 base64url characters for
>    presentation reasons.
>
>    HTTP/1.1 200 OK
>    Content-Type: application/octet-stream
>    Content-Length: 54
>    Content-Encoding: aes128gcm
>
>    I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
>    ly8Thjg
>
> Corrected Text
> --------------
>    The encrypted data in this example is the UTF-8-encoded string "I am
>    the walrus".  The input-keying material is the value "yqdlZ-
>    tYemfogSmv7Ws5PQ" (in base64url).  The 54-octet content body contains
>    a single record and is shown here using 72 base64url characters for
>    presentation reasons.
>
>    HTTP/1.1 200 OK
>    Content-Type: application/octet-stream
>    Content-Length: 54
>    Content-Encoding: aes128gcm
>
>    I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu_ul1ATXXzhZ8IY
>    2l5S6w8cG
>
> Notes
> -----
> The example is missing the padding delimiter octet.
>
> The paragraph directly above this explicitly says it should have it.
>
>>   [...] This uses a
>>   record size of 4096 octets and no padding (just the single-octet
>>   padding delimiter), so only a partial record is present.
>
> Also, without that the delimiter, the body is only 53 octets, not the 
> 54 the description says it should be.
>
> 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.
>
> --------------------------------------
> RFC8188 (draft-ietf-httpbis-encryption-encoding-09)
> --------------------------------------
> Title               : Encrypted Content-Encoding for HTTP
> Publication Date    : June 2017
> Author(s)           : M. Thomson
> Category            : PROPOSED STANDARD
> Source              : HTTP
> Stream              : IETF
> Verifying Party     : IESG