search

pdf-association / pdf-issues

Industry-based resolutions for issues and errata reported against any PDF-related specification
https://pdf-issues.pdfa.org/
64 stars 2 forks source link

32004 backward compatibility issue for public key encryption #475

Open vitali-pr opened 1 week ago

vitali-pr commented 1 week ago

ISO TS 32004:2024 spec, chapter 5.1.3 Additions to ISO 32000-2:2020, 7.6.5.2, table 4 describes an addition to 'Table 24 — Public-key security handler user access permissions' of ISO TS 32004:2024. It suggests to set 13th bit to 0 if MAC token is required.

So it assumes that all previously not used permission bits are set to 1 by default. And it is clearly described for standard encryption in 'Table 22 — Standard security handler user access permissions' of ISO TS 32004:2024. But for public key user access permissions it's not the case. The spec only says "PDF processors shall ignore all flags other than those at bit positions 2, 3, 4, 5, 6, 9, 10, 11, and 12." saying nothing about what to write there. So one could write zeroes not breaking the spec.

It breaks backward compatibility because MAC aware processor can notice 0 in 13th permission bit but not MAC token in the PDF-2.0 document and refuse to process a valid document not containing MAC token.

petervwyatt commented 1 week ago

From my understanding: the trailer also must have the AuthCode entry so looking at a single flag bit in isolation is incorrect and insufficient...

@mkl-public @MatthiasValvekens ?

mkl-public commented 1 week ago

If I understand the issue correctly, it only pops up if the first revision of a document has been public-key encrypted by a non 32004-aware software which sets unknown bits to 0. If in that case the second revision is created by a 32004-aware that applies MACs whenever possible, you get a file that has

Now you can say: But the first revision has neither AuthCode nor 32004 developer extension, so apparently the creator of the first revision was 32004-unaware and there was actually no requirement to MAC all revisions.

On the other hand, though, the first revision could also have been created by 32004-aware software with the requirement to MAC all revisions (bit 13 at 0), including a MAC, an AuthCode, and a developer extension, but someone manipulated the document and then removed those three items, letting the document appear to be created by 32004-unaware software...

(Just from the top of my head, not checking the full 32004...)

petervwyatt commented 1 week ago

To be discussed in DigSig TWG... please 😀

vitali-pr commented 1 week ago

On the other hand, though, the first revision could also have been created by 32004-aware software with the requirement to MAC all revisions (bit 13 at 0), including a MAC, an AuthCode, and a developer extension, but someone manipulated the document and then removed those three items, letting the document appear to be created by 32004-unaware software...

Yes right. Here it's not really about revisions. But about the fact that while validating you don't know whether the document was MAC protected (and tampered) or not if you see bit 13 set to 0.