The poppler api exposes it. Has done it since more or less the incarnation of pdf signing in poppler I think.

Don't do that. The key usage extensions rarely useful. This is the usual X.509 DbC (design by commitee) mess. See for example https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt . Let's not try to follow this path.

The poppler API exposes key usage extensions, and I'm trying to reconstruct them from the canX flags, which of course is highly inaccurate.

Technically, the canX are already checking a flag internally because _gpgme_key stores the can_X values as single bits. There are still 17 unused bits in _gpgme_key, i.e. there's plenty of space for more flags like can_haz_cheezeburger.

OK, still the whole usage stuff screams for a flag style api IMO. With all the canX then reduced to checking for the according flags internally.
@werner I am assigning this to you for triage. Basically set it to wontfix or whishlist if you think it would be worthwhile or not for future canHazCheezeburger things

Use the is_qualified flag to figure out QES certificates. This is more than just a capability flag.

NonRepudiation is not a well defined term. It is used by X.509 but often used similar to a digital signature. Thus this does not make sense. The is_qualified flag is what we need for QeS and it seems we already got this in gpgme.

gpgme puts digitalSignature and norRepudiation into canSign. We need them separated at the sources (maybe exposing keyUsage directly in gpgme. That would also make the code in poppler better and more accurate. I'm trying to reconstruct the keyUsages from the canSign&friends functions.

signing works, too

Ready for testing. I could view a signed PDF and verify the signature with the gpg backend, but other things may not work because of missing dependencies.