This one makes sense to me, I've been bitten by this issue in other work ( it's relevant to bit strings status lists, should we see examples for those in the future ).
I might even go further to suggest that when deterministic compression can be used, it should be used, but that seems like probably a job for another day, and not specific to the examples we have in the cookbook. While we're talking about deflate. I think people started using it to compress signature payloads in an attempt to fit JWTs into QRCodes... That's not related to this erratum but it is related to deflate, and odd behavior I've seen with it. OS On Tue, Oct 17, 2023, 2:58 AM RFC Errata System <[email protected]> wrote: > The following errata report has been submitted for RFC7520, > "Examples of Protecting Content Using JSON Object Signing and Encryption > (JOSE)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7680 > > -------------------------------------- > Type: Technical > Reported by: Filip Skokan <[email protected]> > > Section: 5.9 > > Original Text > ------------- > This example illustrates encrypting content that is first compressed. > It reuses the AES symmetric key, key encryption algorithm, and > content encryption algorithm from Section 5.8. > > Note that whitespace is added for readability as described in > Section 1.1. > > > Corrected Text > -------------- > This example illustrates encrypting content that is first compressed. > It reuses the AES symmetric key, key encryption algorithm, and > content encryption algorithm from Section 5.8. > > Note that DEFLATE [RFC1951] is not a deterministic algorithm; its > implementations must properly round-trip but are not required to > produce the same compressed data; it might not be possible to exactly > replicate the results in this section. > > Note that whitespace is added for readability as described in > Section 1.1. > > Notes > ----- > This added text is aligned with other non-deterministic algorithms in > sections 4.2, 4.3, 5.1, 5.2, 5.13, and 6. It gives the reader a heads up > that the results might not be replicable, e.g. when using a modern zlib > deflate implementation which uses ANZAC++ hash in favour of hardware > accelerated hashing function (i.e. CRC32) to insert symbols in the > dictionary during compression. > > 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. > > -------------------------------------- > RFC7520 (draft-ietf-jose-cookbook-08) > -------------------------------------- > Title : Examples of Protecting Content Using JSON Object > Signing and Encryption (JOSE) > Publication Date : May 2015 > Author(s) : M. Miller > Category : INFORMATIONAL > Source : Javascript Object Signing and Encryption > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
