Clauses 12.8.4.3 DSS, 12.8.4.4 VRI and 12.8.5 DTS all fail to indicate clearly they were added in PDF 2.0

[petervwyatt]

Clauses 12.8.4.3 DSS, 12.8.4.4 VRI and 12.8.5 DTS fail to clearly indicate that these features were added in PDF 2.0, which to a casual reader is very confusing and causing files versioned as PDF 1.7 to occur with such features. The main clue is the fact that the DocCatalog/DSS entry does state “(Optional; PDF 2.0)” and DSS and DTS (but not VRI!) is included in clause "0.3 Changes introduced in ISO 32000-2:2017" - but let's face it very few people read the Introduction each time they refer to the spec!

Proposed solution is to:

• at the start each of the 3 main clauses add a sentence like "PDF 2.0 introduced support for XXX.".
• add "; PDF 2.0)" to each entry in Tables 261 and 262 since many devs only read about dictionary entries
• in prose, wherever the DSS or VRI key names are mentioned add "(PDF 2.0)"

[mkl-public]

which to a casual reader is very confusing and causing files versioned as PDF 1.7 to occur with such features.

There actually is another reason for that: DSS, VRI, and DTS originally have been defined by ETSI, first in TS, later in EN form, and those documents are based on PDF 1.7 and only recommend (but not require) developer extensions to be added.

[petervwyatt]

@mkl-public - the PDF 1.7s I have don't have any Extensions dict. Can you also pls point me to the appropriate ETSI doco? Do you happen to know if things are 100% the same or are there differences between ETSI and ISO?

[mkl-public]

Can you also pls point me to the appropriate ETSI doco?

The current ETSI PAdES spec is ETSI EN 319 142-1 v1.2.1: https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.02.01_60/en_31914201v010201p.pdf

(Oops, I wasn't aware of the 1.2 versions, I still used version 1.1.1. I'll have to check what has changed...)

Concerning the extensions, see section 5.6 and note the "should".

Do you happen to know if things are 100% the same or are there differences between ETSI and ISO?

AFAIK ISO 32000-2 includes the PDF object specifications from the ETSI spec pretty unchanged, merely a bit consolidated. It does not contain the BASELINE profiles, though.

But I'll have to check whether there are relevant changes between the 1.1 and 1.2 versions.

[petervwyatt]

On reflection I think this doesn't change anything as far as ISO 32000-2 is concerned, since most of the PDF 2.0 features were directly adopted from Adobe Extension Level 3 or 5 specs and those features are not indicated as such in 32K-2 - they all just say "introduced with PDF 2.0" with no mention of ADBE 32K-1 extensions (so readers would only know if they know).

Not saying this is good or helpful to the wider PDF community, just that it would be consistent with the current state of affairs. Maybe the only slight difference here is that ETSI is a recognized SDO whereas Adobe is clearly not. You might say 32K is self-centred around ISO publications at the exclusion of all others 😀. Let's see what others and the PDF TWG members think.

[petervwyatt]

@mkl-public: 32K-2 already refers to an EXPLICITLY DATED version of the ETSI spec (in fact for all normatively referenced ETSI specs!):

ETSI EN 319 142-1 V1.1.1 (2016-04) Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signature, European Telecommunications Standards Institute

So the new v1.2 does not immediately apply to PDF 2.0. If you see this as an issue, could you please raise a separate errata here in GitHub?

[mkl-public]

Indeed, as far as ISO 32000 is concerned, this is clearly "since 2.0" material. I just wanted to point out that making that clearer in the ISO spec won't change what you have observed, the presence of these objects in 1.7 documents without any extension in many documents in the wild: The ETSI PAdES specs have been adopted in Europe and beyond, software creating PAdES signatures will usually be based on them, not on PDF-2.

So the new v1.2 does not immediately apply to PDF 2.0. If you see this as an issue, could you please raise a separate errata here in GitHub?

I just compared ETSI EN 319 142-1 V1.1.1 with ETSI EN 319 142-1 V1.2.1, and the only relevant change was the clarification that the OCSP responses to be embedded in DSS->OCSPs are the full OCSPResponse objects, not merely the BasicOCSPResponse objects wrapped in them.

("Clarification" in my opinion. ETSI formulated this, though, as if in former versions naked BasicOCSPResponse objects embedded there had also been allowed, see section 5.4.2.2. NOTE 2.)

[petervwyatt]

Proposed solution is still to update to reflect formal standardization with PDF 2.0:

• at the start each of the 3 main clauses add a sentence like "PDF 2.0 introduced support for XXX.".
• add "; PDF 2.0)" to each entry in Tables 261 and 262 since many devs only read about dictionary entries
• in prose, wherever the DSS or VRI key names are mentioned add "(PDF 2.0)"

[mkl-public]

A quick look around in the spec did not show up any other later addition to be so intensely labeled with its introductory version. In particular I don't find any addition with version labels to all entries on the dictionaries introduced in it, Also in my opinion that would be too extreme. I'd second, though, the proposal to add a sentence like "PDF 2.0 introduced support for XXX." to those main clauses or to add a "(PDF 2.0)" to the first mentioning of document security store, validation-related information, and document timestamp in their respective defining section. This appears to be how it's been handled in most additions.

[petervwyatt]

PDF TWG agree (yes, its a lot of minor edits)