FieldMDP and DocMDP in approval signatures

[MatthiasValvekens]

Describe the bug

I'm confused about the way the provisions for DocMDP and FieldMDP are supposed be combined (clauses 12.8.2.2 and 12.8.2.4, respectively). Assume that I have a signature field with a Lock dictionary that looks like this:

<<
/Type /SigFieldLock
/Action /Include
/Fields [(foo)]
/P 2
>>

Here, the intention is to lock the field "foo" after signing, but still allow other form fields to be updated while at the same time disallowing commenting.

Based on my reading of the language at the end of clause 12.8.2.4, the signing application should create two signature reference dictionaries here: a FieldMDP SigRef dictionary with TransformParams

<<
/Type /TransformParams
/Action /Include
/Fields [(foo)]
/V /1.2
>>

and a DocMDP SigRef dictionary with TransformParams

<<
/Type /TransformParams
/P 2
/V /1.2
>>

Is my reading correct? Because Acrobat glitched out when I tried to get it to validate a signature with this kind of structure. Signing the empty signature field using Acrobat produces a signature with only a FieldMDP SigRef dictionary, containing a P entry with value 2 in addition to the usual FieldMDP entries, despite the fact that Table 259 (Entries in the FieldMDP transform parameters dictionary) doesn't list P as a possible entry. I've also seen this behaviour in other PDF software, so it might just be an oversight in the spec.

What am I missing here?

EDIT: My intention was to submit this with the "question" rather than "bug" label, but apparently I can't do that.

EDIT: Forgot to attach the signed file. The /Fields array is empty here, but other than that everything is the same. fieldmdp-with-lock-signed-by-acrobat.pdf

[mkl-public]

the signing application should create two signature reference dictionaries here: a FieldMDP SigRef dictionary ... and a DocMDP SigRef dictionary

No. Indeed, a FieldMDP transform shall be created based on the SigFieldLock dictionary. But creating a DocMDP transform is not required.

• First of all creating a DocMDP transform when signing a signature field with a P entry in its signature field lock dictionary is actually forbidden if there already is a certification or approval signature in the document. Thus, creating a DocMDP transform cannot be required.
• Also the description of the P value in the signature field lock dictionary conveys that it updates the MDP settings from a previous author signature, and if there is no such author signature, assumes initial permissions to be based on the value 3. This in particular implies that this lock dictionary entry does not request that the signature to put into the field shall be an author signature (which a DocMDP transform would imply).

One might even discuss whether a signature with both a FieldMDP and a DocMDP transform is allowed at all. (I only have the ISO 32000-2:2017 version yet, so I cannot be sure whether this question is decided in the current format.)

---

That being said there indeed are some peculiarities in how Acrobat signed your document:

• As you already remarked yourself, Acrobat seems to have copied the P entry along from the signature field lock dictionary to the FieldMDP transform. This is peculiar as the P entry is neither mentioned as possible FieldMDP transform parameter nor as an entry a signing application is expected to copy there from the lock dictionary. (On the other hand the note under that copying instruction claims that copying is done because all objects in a signature dictionary are direct objects if the dictionary contains a byte range signature. If otherwise referencing was ok, this would at least allow the presence of any lock dictionary values in the transform parameters, in particular the P.)
• That note mentioned above makes it quite peculiar that in Acrobat's signature the transform parameters actually are copied into a separate indirect object. Here apparently Acrobat only loosely follows the specification.

[MatthiasValvekens]

Thank you, @mkl-public , apparently I was wrong about the semantics of Lock, and I misinterpreted the meaning of the P key in Lock as a requirement on the signer to create a DocMDP entry in the signature. I rationalised that as OK, because I (also mistakenly) believed that the certification signature was identified by the pointer in Perms in the document catalog, rather than by the mere presence of a DocMDP signature reference dictionary. Thanks a lot for helping me realise what the source of my confusion was!

Nonetheless, we seem to be in agreement about P in FieldMDP.

[MatthiasValvekens]

Coming back to this issue after sitting on it for some time, I'm still not sure what the right thing to do here would be. Does the following sound reasonable?

Suggestion:

Add a note (perhaps at the end of clause 12.8.2.4?) clarifying how to compute the DocMDP permission level that is currently in effect, making reference to the relevant clauses describing Lock and DocMDP. This would still ensure that all validation-related information for implementers (to the extend defined by ISO 32000) can be found in clause 12.8. If people agree with this approach, I'll draft some words.

I'm less sure what we should (or even can) say about P in FieldMDP in such a note. I've seen a number of implementations that write this value (even though it's technically not defined in the standard), but I have no idea what (if anything) validators do with it in the wild. That being said, adding notes describing behaviour that isn't defined in the actual standard also seems inappropriate. Any thoughts on that point?

[MatthiasValvekens]

The discussion in the DigSig TWG today ended up addressing the remaining open points here:

• It affirmed that the P key in a field lock dictionary is indeed the intended way to apply DocMDP-like locking to a signature that is not the first one in the file.
• As a suggestion out of the DigSig TWG to make this a bit less confusing, we suggest adding the P key from Table 236 (Entries in a signature field lock dictionary) to Table 259 (Entries in the FieldMDP transform parameters dictionary) as well. In addition, the text below Table 259 should be modified accordingly (details below). Like this, the signature reference dictionary/dictionaries canonically define the MDP level.

Proposed changes

Add a P entry to Table 259 of type number with the following description:

(PDF 2.0; optional) An integer value describing the access permissions for this document. This entry shall have the same restrictions and semantics as the P entry defined in Table 236 (Entries in a signature field lock dictionary).

Modify the 3rd bullet point in the para below Table 259 as follows:

The Action, Fields entries in the transform parameters dictionary shall be copied from the corresponding fields in the signature field lock dictionary.

to

The Action, Fields, and P entries in the transform parameters dictionary shall be copied from the corresponding fields in the signature field lock dictionary.

(side note: several implementations that I am aware of already do this)

Wordsmithing welcome.

[mkl-public]

Strictly speaking this changes the (documented!) way the P works in this context, originally having the P entry in the Lock dictionary was the single documented way to lock the document.

After the proposed change, what is the expected behavior of a PDF processor confronted with a signed PDF having the P entry only in the Lock dictionary? Or only in the FieldMDP transform parameters? Or having different values in those locations?

[MatthiasValvekens]

Hmm, right. I was probably too hasty to try to knock this one out in the remaining "dead time" at the end of a meeting (we were on the topic anyway, but still). I'd still contend that the FieldMDP params dictionary should've been the source of truth for the signer's intent w.r.t. MDP all along (with the lock dictionary only serving as a hint for downstream signers, i.e. communicating author intent). But of course that doesn't necessarily mean that retconning it is the way to go.

I need some more time to think this one over (and I'll probably end up putting it back on the agenda for one of our future sessions).

[mkl-public]

Yes, what I'd want in the end also is that the Lock dictionary only is an instruction to the signing software during signature creation while the FieldMDP params dictionary is an instruction to any PDF processor after signature creation. But the way the P currently is documented, differs from that. Thus, the new text should really make clear which P means which (and if conflicts are possible, how to resolve them).