signing time as optional in PDF spec but mandatory in PAdES #505
Comments
|
Yes, but ISO 32000-2 is not PAdES. :) Sure, it integrates some constructs from PAdES, but fundamentally ISO 32000-2 and the PAdES family of standards are maintained by different standards bodies for differing purposes.
Indeed, not all PDF signatures are required to be PAdES-compliant, at least not as far as ISO 32000-2 is concerned. I'm simplifying, but for all practical purposes PAdES defines a profile (actually multiple profiles) of PDF signatures. In some usage contexts (particularly in Europe), adherence to a particular PAdES profile may be a requirement, but this is not universally true for all users of PDF signatures. While your question is valid, I would contend that this is not the kind of thing that needs addressing in ISO 32k. If the relationship between ISO 32k and the PAdES family of standards is unclear, you could maybe argue that an industry body like the PDF Association should educate people on that point, but IMHO that kind of thing is definitely well beyond the scope of the specification itself. Also from a purely practical perspective: as this issue tracker shows, it's already hard enough to keep track of all the internal dependencies between requirements within ISO 32k. If we also had to keep tabs on changes to other standards, it'd become completely unmanageable ;). TL;DR: I don't think there's anything for 32k to do here. |
Please take a closer look at the table from 319 142-1 you link to: that table does not specify PAdES signatures in general but only PAdES baseline signatures! If you take a look at 319 142-2, you'll find that for the PAdES extended signatures (E-BES and E-EPES) the /M entry is optional. Thus, there is no general rule on the /M entry in PAdES to start with. Other than that it's just like Matthias describes it: ISO 32000 presents the general specification of digital signatures, and ETSI EN 319 142-1 and 319 142-2 present a number of profiles thereof some of which have stricter requirements on the presence or absence of some entries. The creation of such profiles is a normal process without the need to mention anything in the general specification about it. |
|
This is tied into the file attached to issue pdf-association/arlington-pdf-model#119 I think? ISO32000 says This particular signature is just invalid: it has no signature date. It's not an Arlington fail because it still meets the requirements of the PDF datamodel (M is optional), but it's still invalid according to 32K. So I agree with Matthias; there's no change required for 32K here. I did find this statement from Peter in your original issue quite interesting:
The confusion seems to be whether a UI shows the signature as valid but the certificate chain invalid (which it necessarily has to be without a date), or whether it decides the whole signature is invalid (and, in the case of Acrobat, hides it completely - a UI decision I don't agree with). But if you're actually trying to validate the signature it's kind of irrelevant at which point it fails, so long as it does. As Tolstoy almost certainly said, every valid signature is the same, but every invalid one fails in its own way... |
Many thanks for your explanations, @MatthiasValvekens & @mkl-public. Sorry for the noise, since I didn’t realize that PAdES might be an EU specialty and took for granted that all PAdES signatures behaved the same way in regard of |
@faceless2, many thanks for your reply. I’m afraid I cannot see how that PDF document is related to this issue. In fact, pdf-association/arlington-pdf-model#119 should describe another totally unrelated issue, but thanks to your reply I realize I had explained myself like crap. Sorry for my previous inaccurate explanation and let me know whether it is clearer now (I really hope it is).
As far as I know, signing time may be also a signed attribute inside the CMS signature (not an unsigned attribute embedded to it). The signature contains a signing time attribute (inside the signature), otherwise
Again, I may be missing something. I agree the
Peter noticed that Acrobat also wanted to save the PDF document when closing it. The resulting document (after being saved/modified by Acrobat) had the signature completely removed. But the cause of this was the lack of the info about existing signatures ( Once the signature flags were added, Acrobat showed the signature and it didn’t try to modify the document (no date displayed though).
Sorry, I cannot see which confusion you mean here that Acrobat solves by hiding the signature. Just for the record, as far as I can remember (and the footnote confirms), the sample certificate used to sign that document was self-signed (the certificate is single, no chain [again, I generated it myself for testing purposes]). |
Weil, "EU specialty" is only partially true. Thus, PAdES encompasses both parts of global and other parts mostly of EU interest only. |
|
@mkl-public - confirming that this issue can be closed as no fix for ISO 32000 (as per discussions above)? |
|
@petervwyatt - indeed, no fix necessary here. One might consider mentioning in a general chapter of 32k that profiles of (parts of) the specification may make optional elements required or may forbid them. But isn't that a general property of profiles... |
|
I didn't come back to this last year due to the holiday break, but it was first on my list this week and you've just beaten me to it. And actually I disagree, I think there is an issue here. Here are four self-signed PDF files, all using a dummy certificate created at the time of signing.
The spec says the Testing shows neither Acrobat nor Foxit are checking the I don't think there's any doubt that if the signature contains an RFC3161 timestamp, that's the date that's used. All implementions agree on that as far as I know. But if there's no RFC3161 timestamp, is the @ousia seems to think it should be, but I'm still of the opinion that "when the time of signing is not available in the signature" doesn't necessarily imply that - it doesn't explicitly mention Myself, I'd be inclined to clarify the spec to match the implementations myself, although I'm sure @petervwyatt you'll test a few more toolkits than my cursory check - if it turns out Acrobat, Foxit and our API are the outliers then I'm easily persuaded otherwise. But that phrase "when the time of signing is not available in the signature" should be revised: either to say "when an RFC3161 timestamp is not present in the signature", or if the |
|
Actually the signature validation details are not really subject of the PDF specification. They depend on the validation policy applicable in the context the signature is used. Furthermore, the text this question focuses on, the M entry and its characterization in table 255 "Entries in a signature dictionary", is in a section that specifies details for arbitrary signature schemes, not only for the interoperable adbe.... and ETSI.... subfilter types. So your proposal
wouldn't make sense here: The signing scheme used may not know any Thus, your question
is not subject of ISO 32000 in general and in particular not subject of the table entry the original question refers to. Acrobat (and similarly Foxit, following Acrobat's lead) is very lax when validating the actual signature (but fairly strict when checking modifications). So when finding no indication of the signing time, they most likely simply assume a time, e.g. (shortly before) now. Other validation policies, like ETSI EN 319 102-1, ignore such claimed signing times completely and only accept time stamps by trusted TSAs, defaulting to now otherwise. |
|
Fair point - this is a generic section of the spec which could apply to non-PKCS#7 signatures, so my suggestion of adjusting the text for the However:
was the comment from @ousia that I was aiming at with my reply, as the implementations I tested didn't do this. But it seems this really is an implementation fault: for PAdES signatures only, see ISO32K section 12.8.3.4.3:
I'm certainly aware of the issues around validation policies, but for PAdES signatures this clause in 32K seems clear. The fact that this isn't done in practice is probably a problem, but unless we want to adjust this clause to reflect reality it doesn't seem like the spec is at fault and I agree no changes are required. Finally, for completeness my previous testcases were not PAdES signatures. I'm reattaching PAdES versions here all with subfilter "ETSI.CAdES.detached". These should all be governed by ISO32K 12.8.3.4.3
|
|
@mkl-public - could I ask that you add this to the next DigSig TWG agenda and decide as a group what you'd like to do? Could be one or more of the following:
|
petervwyatt
added
documentation
Not being a native English speaker I still wonder after reading that 12.8.3.4.3 excerpt a number of times what it exactly means. Does it mean that in case of PAdES signatures with both a signing-time signed attribute and a M dictionary entry, a processor shall not interpret the M value as signing time? Or does it mean that in case of PAdES signatures with a signing-time signed attribute, there shall not be an M dictionary value? Is it a processor requirement or a file format requirement? Similarly in 12.8.3.4.2:
Did the author here deliberately use different verbs ("indicate" / "use") here, giving rise to a processor requirement? Or did they for stylistic reasons not want to use the same verb but meant usage in both cases, giving rise to a file format requirement? That being said, 12.8.3.4.5 gives instructions on how to validate a PAdES signature. Here in particular it says:
Thus, claimed signing times as in the signing-time signed attributes or the M signed signature dictionary entry are not to be used at all as verification time for PAdES signatures. This also is in line with ETSI EN 319 102-1, so for the sake of compatibility this requirement makes perfect sense. So maybe the question above about how to handle signing-time and M if both are present, is eventually somewhat moot... |
Yes, that would make sense. There at least seems to be some need for clarification here. Having known PAdES from the corresponding ETSI norms, I haven't really dived into the way it has been included in ISO 32000-2 yet. But it appears to be quite a can of worms... |
|
In the interest of avoiding future confusion / potential turf wars about scope, would it be worth considering to do the following exercise at the next dated revision of 32k?
If that's too far of a departure from the current text for a dated revision, then feel free to disregard the above ;) |
Often wearing ETSI colored glasses anyways I'd quickly agree. But others might disagree. ;) |
|
To summarize the issue for the DigSig TWG meeting next week: @ousia @faceless2 @MatthiasValvekens Is this correctly summarized? Originally this issue was about the description of the signature dictionary M entry in table 255. There the entry is marked as optional but @ousia pointed out that current PAdES signatures actually would require it and proposed to have that mentioned in that table entry somehow. Most replies were not in favor of that proposal. On one hand that table is in the general section about digital signatures and mostly describes items generically and not specifically for interoperable signing schemes, in particular not for PAdES. On the other hand only PAdES baseline profiles require the M entry while PAdES extended profiles don't, so already the base fact to mention was only partially correct. In the course of the discussion, though, the focus shifted to which time should be considered the claimed signing time if multiple times were given, e.g. both in the M entry and in the signing-time signed attribute of a CMS signature container. In that context @faceless2 quoted from section 12.8.3.4.3 of ISO 32000-2 for PAdES signatures:
At the same time he created some signed test files and validated them with a number of PDF processors. None of them apparently made use of the signing-time attribute. Consequentially, Mike wondered,
In reply it was pointed out that section 12.8.3.4.5 on the validation of PAdES signatures requires to use a trusted time for the existence of the signature and remarks that the M time is not trusted. As the signing-time attribute is similarly trust(un)worthy as the M time, it consequentially cannot be used for validation, either. Thus, both the M time and the signing-time time of CAdES signatures may only be used to display a claimed signing time. Furthermore, the validation policy for digital signatures usually depends on the policy of the underlying CA and the context in which the signed document is used, not on the format of the document. Thus, requirements on the process of signature validation in ISO 32000 appear somewhat questionable. @MatthiasValvekens also saw the issue of PAdES signatures being defined both in ETSI norms (originally) and in ISO 32000-2 (rewrite of part of the ETSI norms) and proposed:
|
|
You will be most welcome in the digsig TWG 😄 good summary. I just want to add that of course, there is a disinction between a trusted and untrusted signing time. "Validation" and "verification" are words that can be interpreted many ways, but in the absence of a trusted time from RFC3161 then the untrusted signing time is (necessarily) used to "validate" the signature - by which I mean stating that "the file claims to be signed at this time, although that's not confirmed, but assuming that claim is true then the signature and certificate chain is valid". The source of that untrusted signing time ( Re. validation policies set by the CA, that's the theory but in practice it's the PDF viewing application that decides. As you can tell it's a pet topic which I'll summarize as: I believe a baseline policy for signature validation is necessary. I'd suggest we currently have a de facto baseline policy, based on how most (all?) toolkits and viewers function, which is:
If we want to continue to exchange signed PDFs between different tools, codifying this somewhere (probably in 32K) might not be a bad idea (ideally along with other things that matter for validation, like key-usage). And of course none of this prevents a specific CA policy, or a specific signature subfilter like Apologies, this topic is wandering. Agree a review of the PAdES claims in 32K vs actual PAdES is not a bad idea, although I see no reason to remove those claims from 32K so long as they're identical. 32K is much more concise and a convenient place to summarize them, with the proviso that we continue to refer to PAdES for the full picture. |
Thanks! :)
This (or something similar) may be the current approach of many general purpose PDF processors with generic signature validation functionality. But the relevance of the validation results of those processors is fairly limited. (By the way, at least Adobe Acrobat (which likely is most used such generic validator) and Foxit can be configured to ignore claimed signing times and only use trusted time stamp times, defaulting to "now".) Of course, people will use these processors for a quick check of integrity and basic validity. But if the validity of such a signature in a context with a fairly fixed validation policy (like eIDAS qualified signatures) ever is questioned and goes to court, the validation result of such a general purpose validator will be ignored and validation policy aware validators will be used.
We could indeed consider to define a common validation policy in PDF viewers. If doing so in 32K, though, we should be cautious not to make this policy mandatory for PDF signature validation - that would be ignoring the fact that there are different validation policies required in certain contexts. So this could be introduced in 32K like "a PDF processor validating signatures can support multiple validation policies; it should (shall?) support the basic validation policy defined as follows..." Alternatively a PDF association Technical Note could be created.
Well, it by now offers quite a range open issues to pursue in the TWG. :)
It may be more concise but it is somewhat outdated. For example, it focuses on the "extended PAdES profiles" E-BES and E-EPES while the "baseline PAdES profiles" are the ones in actual use. hardly anyone cares about the extended profiles, they are mostly of historical interest if at all. |
|
The DigSig TWG confirmed that the ISO 32000-2 section on PAdES signatures is somewhat outdated. Simply removing it most likely is not a solution, though. This will have to be discussed more thoroughly. Concerning the common signature validation policy Mike agreed to provide a paper with some ideas on this topic as a base for further discussion. |
Describe the bug
From the
/Mkey of signature dictionary:From the latest ETSI EN 319 142-1, PAdES requires
/Mto be set and no signing time attribute in the CMS signature.If not all PDF signatures are PAdES (which I don’t really know), it would be worth mentioning that
/Mis a requirement for PAdES, which also requires no time of signing in the signature message itself.The text was updated successfully, but these errors were encountered: