Here is an example containing such a Attestation Signature:

Oh, this report is about libgpg-error.

@dkg First step toward the canonical OpenPGP certificate export: http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=75372cac01501ae427dec1ae18805449bf28d087

@wiktor-k Thanks for your interest.

IIUC, there is only a single recipient, but it has 256 SKESK packets, while only a single SKESK is valid and others are all dummy, right?

Unfortunately, for my use case the corresponding SKESK packet number is not known when calling GnuPG.

@dkg You are right. The term "issuer" was too ambiguous.
I like your proposal and would try to implement it. However, "export" of dkg-keycheck and other programs from DKGPG are very limited.

But that's exactly my use case in DOTS: an easily to create 'decryption puzzle' (including the hardness of iterated and salted S2K) for the serving party in order to make DoS harder. I don't see how public-key crypto can help here. Moreover, I would keep the user interaction as cheap as possible, i.e., copy'n'paste an ASCII-armored message and passwort to GnuPG without importing public keys etc.

@gniibe Thanks for explaining the background. Are there any ideas for fixing? (e.g. the decrypted content could be checked for a valid packet structure or at least for starting with a valid packet header)

then they are sorted by their binary content.

Recently, I started a new project at savannah for developing free software and documentation in order to operate a Distributed OpenPGP Timestamping Service. Everyone is welcome to join.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

By the attached test program I can confirm that the issue is solved.

BTW: For TSA keys an additional key (usage) flag ("This key may be used for time-stamping") in RFC 4880bis would be nice. What do you think?

According to RFC 3628 there are two additional conditions to consider:

A timestamp or a time mark (which is an audit record kept in a secure
audit trail from a trusted third party) applied to a digital
signature value proves that the digital signature was created before
the date included in the time-stamp or time mark.

Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.

DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.

What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?

I've made the parsing less strict in LibTMCG: https://github.com/HeikoStamer/libtmcg/commit/be7963b33cf8bace9d031074521acc4e89930d33

Please note that Section 13.6 of RFC 4880 says:

I have attached a small patch to show this two additional key flags with "--list-keys":

After having a look at the code base I guess this behaviour is intentional.