32004 backward compatibility issue for public key encryption

[vitali-pr]

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]

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]

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

• an AuthCode entry (added in the second revision) and
• bit 13 set to 0 (requiring each revision to be MAC'ed) but
• no MAC in the first revision, violating that requirement.

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]

To be discussed in DigSig TWG... please 😀

[vitali-pr]

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.

[MatthiasValvekens]

Hi,

Chiming in a bit late (though I did already discuss some of this with @vitali-pr before he filed the issue). The problem is indeed strictly about "downgrade protections": you shouldn't be able to strip a MAC from a MAC-enabled document and pass it off as a non-MAC-enabled document.

This type of problem is often hard/impossible to solve in contexts where backwards compatibility is required. PDF is no different in that regard, but it does have one somewhat useful mechanism: the permission bits. In both the standard and pubsec security handler, these come with some degree of tamper protection that is codified in 32000-2, so 32004 attempts to piggyback off that by encoding the presence of a MAC in a newly allocated permission bit.

The reason why 32000 mandates that all unknown bits be 1 in the standard security handler is exactly this: to be able to introduce new permissions with well-defined backwards compatibility semantics. I would argue that if no such provision exists for the pubsec security handler, then that's an omission in 32000 that should be rectified.

But given the nature of the problem, that's a bit of a moot point if it's not what widely used implementations already do today. If memory serves, iText also sets unknown permission bits to 1 in the pubsec security handler. @lrosenthol @romantoda @faceless2 can you comment on how your implementations handle unknown permission bits in the public-key security handler? (Note: this question is about implementing 32k, not 32004)

In summary, here's my take:

• Conceptually, I think the requirements in 32k should be harmonised between the standard and public-key security handlers, provided that this is what major implementations already do anyway.
• If we can't harmonise the requirements, then we probably should document that in a note. 32004 users would then have to live with the fact that there is no downgrade protection for public-key encrypted files (which we should also document). Given the nature of public-key-based workflows, this might not be all that bad. One could argue that the recipient should specify that they expect a MACed file when they share their public key with the sender.

[faceless2]

When signing with a public key, we set bit one (Acrobat will fail validation if we don't) and also 7 and 8, but we don't set any bits above 12 - everybody knows the natural state of a bit is zero :smile:

We've got no problem mandating unspecified bits are set, I agree with the reasoning in this issue.

[MatthiasValvekens]

The DigSig TWG recommends harmonising the requirements in 32k to align the public-key security handler with the standard one in its requirements for "unassigned" permission bits, whenever WG8 sees an opportunity to do so (e.g. in a dated revision to ISO 32000-2). We also propose setting the "capacity" of the permission bit field at 32 bits.

It's debatable whether that would constitute a breaking change [*], but in the committee's view, usage of this feature is sparse and limited to closed workflows, so the general feeling is that this would be acceptable.

[*] I personally contend that it doesn't have to be; if the requirement is carefully worded it need not expressly invalidate any existing files (after all, any permission bit may be assigned in the future). Depending on how any given processor handles unknown permission bits in response to this change, it may of course refuse to process files with unknown bits set to zero. But that's not 32k's problem as long as we shy away from imposing any processor requirements ;).

EDIT: Text to be wordsmithed based on the wording of the requirements for the standard security handler.

[petervwyatt]

@mkl-public - happy to take wording recommendations from the DigSig TWG...

[mkl-public]

Crypto/Provenance TWG recommends adding a new row for permission bit positions 13 - 32 to table 24 (Public-key security handler user access permissions):

Bit position	Meaning
...	...
13 - 32	Reserved. Must be 1.

This corresponds to a change already applied to table 22 (Standard security handler user access permissions) in ISO 32000-2:2020.

[petervwyatt]

PDF TWG agree