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.

I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.

I use the internal driver.

Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. Enable… changed the default to no-rfc2440-text.

I see. Thanks for your explanation.

I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:

The secret key is this series of multiprecision integers:
o  MPI of RSA secret exponent d;
o  MPI of RSA secret prime value p;
o  MPI of RSA secret prime value q (p < q);
o  MPI of u, the multiplicative inverse of p, mod q.

At the time the verification is done some output has already been written to the file 'signed'. When checking whether the deprecated abbreviated format

The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.

Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.

What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.

Thanks. The mail is a standard, non-crypto mail with one attachment. That attachment is a TNEF file which has according to ytnef(1) just one file. That file has the name gpgolPGP.dat and contains a clearsigned message.

Sure, I zipped the eml which failed and I´ll send it by e-mail to you

Is it possible that you upload or send me a copy of such a mail (wk gnupg.org)? ZIP or tar the eml file and send it in an encrypted mail to me to make sure it won't be modified on the transport.

I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.

I agree. It also happens to me. But only with mails coming from "Microsoft security update releases". Mails coming form "Microsoft security advisory notification" and Microsoft security update summary for..." are ok and are signed by the same key. It could be some trouble in MS automated email treatment.

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

No info received.

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.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.