I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

Since it was handled in T4908, this task is merged into that.

@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.

I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.

In the SOS branch, rG1c4291c3951d: ecc-sos: Add special leading zero octet removal. should be reverted.
Instead, the S_KEY should be fixed up in read_key_file in findkey.c,
and merge_lists in protect.c.
(Then, no need to be fixed up in extract_private_key.)

Exactly same problem is there in libgcrypt.
In the definitions of curves, it uses negative constant internally in some specific places, but for other parts, we have same problems.

I should concentrate the case of ECC, in particular, ECC with modern curves.
Removing leading zero from RSA/ECC/ELGamal assuming unsigned integer would result more work.

In libgcrypt, we have another problem of GCRYSEXP_FMT_ADVANCED formatting, which is used by gpg-agent of GnuPG 2.3 with name-value list.

Confusingly, in the SSH specification, it is signed MPI.
See RFC4251, for the definition of "mpint": https://tools.ietf.org/html/rfc4251#page-8

There are more places for clean up in GnuPG.
While "MPI" in OpenPGP specification is based on unsigned integer, the default "MPI" handling of GnuPG/Libgcrypt is signed. This difference matters internally.
Formatting by "%m" with libgcrypt, it may result prefixed by 0x00 (so that it represents unsigned value, even if scanned as signed).
And because of this, existing private keys in private-keys-v1.d may have this leading zero-byte.
But the counting bits don't count this byte.

Important interoperability issue:
OpenPGP implementations should implement:

• Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature

Better to paste directly:

# SOS representation
#
# Initially, it was intended as "Simply, Octet String", but 
# it is actually "Strange" Octet String.
#

I wrote this:

Sorry, I don't know what kind of sample data that is. The reference keys have been provided by the RFC6637 author and are part of GnuPG's test suite; see (gnupg/tests/openpgp/samplekeys/ecc-sample-*).

I can't find any places where it is interpreted as signed integer.

It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.

Your example data is malformed, I suppose.

I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.

It is easy to explain:

That means that the GnuPG Backend does not work. I do not think that the office update is the reason, me and others use GpgOL with the most recent versions of Office Pro Plus without issue.
Have you possibly modified you gnupg config files? If there is a bad value in there it would result in such an error.

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.

For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.

It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.

It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.

Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.

I am in charge of editing the current OpenPGP draft, so I will for sure keep an eye on that issue. If would appreciate if you can post your report also to openpgp at ietf org.