Search RFCs

RFC Editor

Found 3 records.

Status:Reported (3)

RFC 7516, "JSON Web Encryption (JWE)", May 2015

Errata ID:7719
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2023-12-01

Section 6 says:

The key identification methods for this specification are the same asthose defined in Section 6 of [JWS], except that the key beingidentified is the public key to which the JWE was encrypted.

It should say:

??? <I don't know the proper correction.>

Notes:

Section 6 of [JWS] says "these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail."

I don't know if this is true for signature schemes (that is, RFC 7515 might have the same erratum), but this is only true for encryption schemes if the algorithm is key-committing. See https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-properties-02.html#name-key-commitment.

Errata ID:8676
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Burak Can Kus
Date Reported: 2025-12-12

Section 5.2 says:

14.  Compute the Encoded Protected Header value BASE64URL(UTF8(JWE     Protected Header)).  If the JWE Protected Header is not present     (which can only happen when using the JWE JSON Serialization and     no "protected" member is present), let this value be the empty     string.

It should say:

14.  Compute the Encoded Protected Header value BASE64URL(UTF8(JWE     Protected Header)).  If the JWE Protected Header is not present     (which can only happen when using the JWE JSON Serialization and     no "protected" member is present), let this value be the empty     string. Instead of serializing the JWE Protected Header JSON     object, use the Base64url decoded representation of JWE     Protected Header.

Notes:

Step 3 says:

3. Verify that the octet sequence resulting from decoding the
encoded JWE Protected Header is a UTF-8-encoded representation
of a completely valid JSON object conforming to RFC 7159
[RFC7159]; let the JWE Protected Header be this JSON object.

Since JWE Protected Header is the JSON object, the serialized value might often end up different than the Base64url representation of the input value, this is because JSON is not canonical. So in step 14, instead of serializing the JSON object of the JWE Protected Header, the Base64url decoded value must be used to obtain the same value.

Errata ID:6018
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kinan Diraneyya
Date Reported: 2020-03-16

Throughout the document, when it says:

initialization vector

It should say:

initialization value

Notes:

RFCs 7516 through 7520 (inclusive) all used the deprecated (as dictated by RFC 4949) term "initialization vector" in place of the newer term "initialization value".

Report New Errata