subkey binding signature with no usage flags

[Daniel Kahn Gillmor]

On 09/14/2013 04:51 AM, Werner Koch wrote:
> On Wed, 11 Sep 2013 23:46, dkg at fifthhorseman.net said:
>> Without this patch, if a subkey with a usage flags subpacket that is
>> all-zero appears, GnuPG thinks that the key is valid for all
>> capabilities (usage: SCEA).
> 
> Yes.  It is the key owner's decision.

Please consider a keyholder who makes their subkey with a tool other
than GnuPG, and that tool deliberately marks the subkey with a key flags
subpacket with none of the standard usage flags set -- the intent here
is to say "do not use this subkey for your standard uses".

When that subkey is seen by GnuPG, GnuPG fails to interpret it correctly.

It is the key owner's decision to make such a subkey, but GnuPG is
misinterpreting the key owner's stated intent if GnuPG uses it to
encrypt a message.

> No.  Key signatures (certifications) are only allowed by the primary
> key.  This is an OpenPGP requirement.

Oh!  that's good to know, thanks.  Can you point me to the part of the
standard that says it?  I looked but all i could find was
(https://tools.ietf.org/html/rfc4880#page-71):

   In a V4 key, the primary key MUST be a key capable of certification.
   The subkeys may be keys of any other type.  There may be other
   constructions of V4 keys, too.

This seems to require that the primary key be certification-capable, but
doesn't explicitly exclude certification-capable subkeys (i admit i find
this paragraph pretty unclear, though, particularly as it seems to avoid
any explicit requirements with that last sentence; any guidance in
interpreting it would be much appreciated)

At any rate, if the intention is that subkeys cannot be
certification-capable, it seems odd that gpg would mark a subkey as
certification-capable, which is what happens if the key flags subpacket
is all-zeros:

 Usage: ECSA

>> I'm inclined to see this as a security vulnerability (because of the
>> confidentiality and certification-following concerns); i'd like to see
> 
> Sorry, I don't understand.  Only the owner of the key can create a
> subkey.  We can't forbid him to shoot in his own foot.

I hear you, but gpg *can* avoid misinterpreting explicitly-structured
data that indicates that a key is *not* for some specific use.  It
should do that.

>> it fixed in the stable branches and assigned a CVE, so that i can push
>> for getting it resolved in those distros that care about CVE coverage.
> 
> Huh?

I'm not sure which part doesn't make sense, so i'll expand them both a
bit.  I'm happy to try to clarify further if i've missed the point of
confusion.

GnuPG is currently willing to encrypt a message to a key that is marked
explicitly by the keyholder as *not* acceptable for encryption.  This
violates the assumption (which i suspect most GnuPG users have) that
GnuPG will only encrypt messages to keys that are marked by their
keyholders as encryption-capable.  This is a security vulnerability
because it exposes messages that should be confidential to decryption by
keys that are not intended or designated for that purpose.  Granted,
this is not a huge problem due to the current rarity of the situation
and the requirement that the other subkey must also somehow be
compromised by the attacker.

re: "those distros that care about CVE coverage" -- this is a relatively
small patch (thank you for sorting it out!) and I would like to
encourage organizations like debian to adopt it even in cases where they
would need to backport it, to avoid the risk described above.

Thanks for taking these concerns seriously, and thanks (as ever) for all
your work on GnuPG.  It's very much appreciated.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130914/5966e598/attachment.sig>