subkey binding signature with no usage flags and/or a critical notation

[Daniel Kahn Gillmor]

following a discussion on the IETF mailing list [0], i did a couple of
experiments with GnuPG, to see if i could make a subkey with the usage
flags subpacket set to an all-zero byte, or with a critical notation.
(this would allow specific alternate uses to be identified with notation
subpackets without needing to navigate the WG resistance against
expanding the usage flag bits)

Below is an example OpenPGP key with three subkeys:

 * the first (1024bit DSA) is marked authentication-capable, with a
   critical notation that gpg doesn't know about.  gpg marks this with
   usage flags "a", depsite the critical notation.  should this subkey
   binding signature be acceptable to gpg even in the face of the
   critical notation?

 * the second (512bit DSA) has no usage flags subpacket at all in the
   binding signature.  gpg marks this "sca", presumably because those
   are all the capabilities supported by DSA.

 * the third (768bit DSA) has a usage flags subpacket with all bits set
   to zero.  gpg marks this also as "sca".

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: example.key
URL: </pipermail/attachments/20130312/e4d2b185/attachment-0001.ksh>
-------------- next part --------------

To generate the second subkey, I used:

 gpg --expert --edit-key "$test_uid" addkey

and toggled off all the flags for the subkey.

As you can see, the resultant key had no usage flags subpacket at all,
which led GnuPG to interpret it as "any usage allowed" (sca, in the case
of a DSA key, since DSA can't be used for encryption).

To generate the third subkey binding signature, i had to modify
do_add_key_flags() in g10/keygen.c, since it currently declines to add a
usage flags subpacket if all bits are off.

I think GnuPG's handling of (at least) the third subkey is buggy, and
potentially dangerously so -- for example, if the "certify" bit is
present and set to 0, GnuPG should not accept a certification made from
the given subkey.

The attached patch (against 1.4.12) seems to work to permit the creation
of an all-empty set of usage flags:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: allow-empty-usage-flags.patch
Type: text/x-diff
Size: 291 bytes
Desc: allow empty usage flags
URL: </pipermail/attachments/20130312/e4d2b185/attachment-0001.patch>
-------------- next part --------------

It looks to me like this code can only be reached via --expert mode
anyway, since otherwise there is no way to turn off all the usage flag
bits through the UI.

So i think we need to think through a few questions:

 * what should GnuPG do when presented with a subkey binding signatures
   with critical subpackets that it does not understand?

 * what should GnuPG do when presented with a subkey binding signature
   with an all-zero usage flags subpacket?

 * (less importantly) should GnuPG be able to generate such a subkey
   binding signature?

Any suggestions or proposals?

Regards,

     --dkg

[0] http://thread.gmane.org/gmane.ietf.openpgp/7333



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20130312/e4d2b185/attachment-0001.sig>