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

[Christian Aistleitner]

Hi Daniel,

since you said to have patched GnuPG 1.4.12, I tried on GnuPG
2.0.19. See below.

On Tue, Mar 12, 2013 at 04:51:20PM -0400, Daniel Kahn Gillmor wrote:
> 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?

With GnuPG 2.0.19, this signature is considered a bad signature. It
says so, when trying to import the key:

__________________________________________________________
christian at spencer
cwd: ~
LC_ALL=C gpg --import ~/example.key 
gpg: assuming bad signature from key C9A3FA35 due to an unknown critical bit
gpg: key C9A3FA35: "test key with dsa subkey" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1


And in fact GnuPG 2.0.19 does not add the first subkey:

__________________________________________________________
christian at spencer
cwd: ~
LC_ALL=C gpg --edit-key C9A3FA35
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  1024R/C9A3FA35  created: 2013-03-05  expires: 2013-04-04  usage: SC  
                     trust: unknown       validity: unknown
sub   512D/48B80074  created: 2013-03-07  expires: 2013-04-06  usage: SCA 
sub   768D/5BA8B581  created: 2013-03-12  expires: 2013-03-19  usage: SCA 
[ unknown] (1). test key with dsa subkey

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

As seen above, this also holds true for GnuPG 2.0.19

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

As seen above, this also holds true for GnuPG 2.0.19

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

About the critical bit, RFC 4880 §5.2.3.1 says

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

So I'd say, GnuPG should do just that. GnuPG should consider the
signature to be in error.

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

RFC 4880, § 5.2.3.21:

   If a
   list is shorter than an implementation expects, the unstated flags
   are considered to be zero.

Although this sentence comes with a vague precondition of the
implementation expecting something, I'd nevertheless interpret a key
flags subpacket being all-zero, as signalling that this key should
/not/ be used for signing, encrypting, ...

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

If it's hidden behind --expert, I would not mind. However, I do not
see a really compelling use case for allowing to generate such a
key. Well, maybe the OTR usage you mentioned on the IETF mailing list
just is such a use case :-)


Best regards,
Christian




-- 
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
                           Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a        Email:  christian at quelltextlich.at
4040 Linz, Austria           Phone:          +43 732 / 26 95 63
                             Fax:            +43 732 / 26 95 63
                             Homepage: http://quelltextlich.at/
---------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130313/7cbcc4cc/attachment-0001.sig>