Re: [Technical Errata Reported] RFC8188 (8620)

[Patrick Barrett <[e-mail]>]

Shoot, you are definitely correct.

I've figured out where my misunderstanding came from. While debugging an actual issue in my implementation I switched the 'encrypted data' from the string "I am the walrus" from the text to the value decoded from the 'unencrypted data' ("SSBhbSB0aGUgd2FscnVzAg") not realizing that the latter had the the padding delimiter added.

I realize that 'data' is probably being used as a generic term, but I'd suggest that the 'unencrypted data' in the intermediate values section could have the padding delimiter removed  to match how the word is used in the text above or have the name changed to 'unencrypted record' to be more clear about what data it is referring to.

On Thu, Nov 20, 2025, at 16:45, Martin Thomson wrote:
> 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