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

[David Shaw]

On Mar 12, 2013, at 4:51 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> 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?

It should not be acceptable.  If someone imports this key, the marked subkey is left off.  The problem here seems to be that you generated (rather than imported) the key.  It's a bit of a messy situation.  On the one hand, you have a subkey with a critical notation so it shouldn't be used, but on the other hand, how could you generate such a thing if GPG didn't at least accept it to the point of generating it?  Note if you export that key, you won't be able to re-import it.

> * 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.

Correct.  Lacking a key flags subpacket, the assumption is that all uses are permissible.  There is a minor caveat here where subkeys do not get the "certify" capability for web of trust reasons.

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

Yes. Having no flags set at all is treated as if there is no subpacket present.  This may not be the best behavior.

> 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.

It doesn't.  Try it.  The certify bit on subkeys is a slightly weird case.  Briefly, all primary keys MUST be able to certify, but subkeys are not required to.  In practice, GPG simply doesn't allow *any* subkey to certify.  Even if you hacked the code to force creation of such a certification, GPG does not include it in the web of trust.

David