Page MenuHome GnuPG
Create Task
Maniphest T6633

GPGME: Add API for extended key usage flags like nonRepudation
Open, NormalPublic
Actions

Description

Currently we only have the fields can_encrypt, can_certify, can_encrypt and "is_qualified"

For digital signature we would need non_repudation.

My proposal would be to have this more extendable as we can maybe in the future also make a difference between dataEncipherment or keyEncipherment. Or with even more usages.

So why not just use flags like we do at other places

#define GPGME_KEY_USAGE_ENCRYPT 1
#define GPGME_KEY_USAGE_SIGN         2
#define GPGME_KEY_USAGE_AUTHENTICATE 4
#define GPGME_KEY_USAGE_KEYENCIPHER 8
#define GPGME_KEY_USAGE_DATAENCIPHER 16
#define GPGME_KEY_USAGE_NONREPUDIATION 32


typedef unsigned int gpgme_capability_flags_t

With maybe some more intelligent values? Just as a more extendable suggestion so that we can either base the high level checks on this and give the application access to the more low level / protocol specific capabilities below that without having to add new API for every new capability?

Event Timeline

• aheinecke triaged this task as Normal priority.Aug 3 2023, 4:41 PM
• aheinecke created this task.
• werner added a subscriber: • werner.Aug 3 2023, 8:54 PM

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.

• aheinecke assigned this task to • werner.Aug 4 2023, 7:58 AM
• aheinecke raised the priority of this task from Normal to Needs Triage.

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

• aheinecke removed a parent task: T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures.Aug 4 2023, 7:58 AM
• aheinecke renamed this task from GPGME: Add API for extended key usage flags aka nonRepudation to GPGME: Add API for extended key usage flags like nonRepudation.Aug 4 2023, 8:04 AM
• ikloecker added a subscriber: • ikloecker.Aug 4 2023, 9:31 AM

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.

svuorela added a subscriber: svuorela.Aug 4 2023, 10:59 AM

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

• werner added a comment.Aug 8 2023, 11:57 AM

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.

svuorela added a comment.Aug 8 2023, 12:02 PM

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

• werner added a comment.Aug 8 2023, 3:09 PM

That does not mean that this is a good idea. And well, I heard that Poppler does not have a stable API.

• werner added a comment.Aug 8 2023, 3:31 PM

Here is an example from my QES cert:

$ gpgme/tests/run-keylist --cms --validate 0x66A25385
keyid   : DF3634E266A25385
caps    : s
flags   : secret qualified cardkey
upd     : 0 (0)
fpr    0: 60ECCA6D9073C8F8164318AADF3634E266A25385
grip   0: 861BB08728E3D97749CAB6D97CD1EB5BBF309ECA
curve  0: nistp256
caps   0: s
flags  0: secret qualified cardkey
userid 0: 2.5.4.5=#34,CN=Koch[...]
[...]

You can see the "qualified" flag. Unfortunately we get this info only
if we do the validation. Just for key selection we might be able to
give a "might be a QES" state back. I need to think about it.

• werner triaged this task as Normal priority.Aug 8 2023, 3:36 PM