I have a correct, working, LTV implementation of adbe.pkcs7.detached PDF signatures that was made following ISO32000 2008-1 and RFC5652 guidelines. Now i'm trying to also allow for ETSI.CAdES.detached type signatures which are described in ETSI EN 319 142-1. For what i've understood so far, the main difference is the /SubFilter value, the DSS structure, the ESS attribute and the document-time-stamp. Are all 4 of theese changes necessary to comply with the standard?

If so, does the final PDF document has the same Long term capability as the adbe.pkcs7.detached one?

It is mentioned in the ETSI document that it's necessary to re-apply the document-time-stamp and DSS just before it expires to keep the signature valid, why does this not happen in the adbe.pkcs7.detached document and how can one avoid this?

How exactly is the ESS attribute constructed in the SignedData structure and is there any other change in it?

The code was implemented using PDFBox and BouncyCastle in Java, are this libraries capable of also implementing the ETSI signature as well?

CodePudding user response：

In a comment you clarify that you are "aiming for B-LT type signatures"; thus, this answer assumes this PAdES profile. In that comment you also also insinuate that the "Long term capability" you want to compare to is what Adobe's "LTV-enabled" implies. thus, here we also explore what that term implies and what not.

Formats

For what i've understood so far, the main difference is the /SubFilter value, the DSS structure, the ESS attribute and the document-time-stamp. Are all 4 of theese changes necessary to comply with the standard?

Indeed, for an actual PAdES B-LT signature (in contrast to an ISO 32000-1 adbe.pkcs7.detached one) the SubFilter value must be ETSI.CAdES.detached, a DSS structure must be added, and an ESS signing certificate must be present. Furthermore, a timestamp is required after signing but it needn't be a document time stamp, a signature timestamp in the signature container also suffices.

There are more differences, though. E.g. for PAdES signatures the embedded SignedData object shall be as profiled in CAdES. Depending on the contents of your SignedData object this may make a difference, see e.g. here. Take all of the spec seriously to prevent nasty surprises.

How exactly is the ESS attribute constructed in the SignedData structure and is there any other change in it?

The ESS signing certificate attributes are specified in RFC 2634 and RFC 5035 and profiled for use in CAdES and PAdES in ETSI EN 319 122-1. The SignedData, SignerInfo, and Attributes structures are defined in RFC 5652 and other documents referenced from there.

Do take seriously how these RFCs are profiled by CAdES and PAdES! E.g. the RFCs allow to include both a ESScertID and ESScertIDv2 in the same signature while in CAdES/PAdES only exactly one of these attributes is allowed and required.

Long term capabilities

does the final PDF document has the same Long term capability as the adbe.pkcs7.detached one?

In a comment you clarified that getting Adobe Acrobat to show "LTV-enabled" for your adbe.pkcs7.detached signature is an indication of "Long term capabilities" for you. With that in mind: Yes, Adobe Acrobat also shows "LTV-enabled" for PAdES B-LT signatures with trust anchors on the AATL or EUTL.

It is mentioned in the ETSI document that it's necessary to re-apply the document-time-stamp and DSS just before it expires to keep the signature valid, why does this not happen in the adbe.pkcs7.detached document and how can one avoid this?

Beware, the ETSI document assumes a different validation policy than Adobe Acrobat:

First of all, what does it mean for a signature to allow Long Term Validation? It means that the signature container (in case of integrated PDF signatures the whole respective PDF) brings along all information necessary for validation of the signature. BUT which information is necessary for validation depends on the validation policy that is applied!

The validation policy applied by Adobe Acrobat is very lax. In particular it trusts essentially all time designations in all the tokens in questions (signatures, revocation data, ...). Furthermore, it does not require revocation data to be strictly younger than the signature but allows them to be a bit older.

The proper validation policy for European qualified electronic signatures, on the other hand, is based on ETSI EN 319 102-1 and profiled by ETSI TS 119 172-4 which is much stricter. In particular it requires proof for a number of time designations in the tokens in question and only accepts revocation data that is strictly younger than the signature it is used for.

The mentioning in the ETSI document that it's necessary to re-apply the document-time-stamp and DSS just before it expires to keep the signature valid, implicitly assumes the latter validation policy for European qualified electronic signatures where time stamps are important and required.

And this not happen in the adbe.pkcs7.detached document because you validate that document with Adobe Acrobat and its trusting validation policy.

As an aside, this in particular means that the revocation information embedded in your LTV-enabled ISO 32000-1 adbe.pkcs7.detached signatures can not be used in a proper European qualified electronic signature validation: In your case the revocation information are (at least slightly) older than the signature and so unusable for validation.

Objectives

The objective now is to change the subfilter to ETSI.CAdES.detached to comply with some regulations which mention ETSI EN 319 142-1 as the format required.

Then you should check the regulation again. Merely requiring ETSI EN 319 142-1 as the format is unclear, at least they should refer to one or more of the baseline profiles specified therein.