DER-encoded CMS SignedData object using CMSSignedDataStreamGenerator

[SkyCrawl]

Hello,

in ETSI TS 102 778-3 v1.2.1, and later also ETSI EN 319 142-1 v1.1.1, there is the following requirement:

A DER-encoded SignedData object as specified in CMS (RFC 3852 [4]) shall be included as the PDF signature in the entry with the key Contents of the Signature Dictionary as described in ISO 32000-1 [1], clause 12.8.1.

A DER-encoded SignedData object can be generated with BouncyCastle, but only using the CMSSignedDataGenerator class, not CMSSignedDataStreamGenerator. I was wondering why and whether it would be possible to bring support for DER-encoded SignedData objects to CMSSignedDataStreamGenerator as well.

[peterdettman]

DER encoding includes definite lengths at the start of encodings, which means that it needs to know the exact length of the output before it starts producing any. The purpose of the CMS stream generators is to produce output directly (i.e. without keeping in memory a full copy of the data), which is fundamentally incompatible with DER in the general case.

[bsanchezb]

Hello @peterdettman,

I would like to ask if it is feasible to extend CMSSignedDataStreamGenerator functionality to create DER-encoded CMS, provided that the size of the encapsulated content info is provided in advance?

This limitation on creating only BER-encoded signatures with CMSSignedDataStreamGenerator creates problems on augmentation of CAdES signatures containing archiveTimestampV2, which message-imprint computation is dependent on the data encoding within the signature (see #1983 for more information).

Currently, if we try to extend a DER-encoded signature with a CMSSignedDataStreamGenerator, the produced signature is generated using a BER-encoding, which breaks the available archiveTimestampV2.

Provided that the size of the original ContentInfo and other properties is known in advance, would it be possible to generate all the required DER tags on the fly using CMSSignedDataStreamGenerator or an alternative implementation, so the provided signature result is DER encoded or encoded in the same way as the original signature provided to the augmentation service?