Mailing List Archive

subkey binding signature with no usage flags and/or a critical notation
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".
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
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@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@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@quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On 03/13/2013 07:22 AM, Christian Aistleitner wrote:

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

Ah, interesting. Thanks for pointing this out. I was only looking at
it from the keyring which generated the subkey binding signature in the
first place.

When i gpg --import with 1.4.12, i see something similar to what you see:

0 dkg@alice:~/src/gnupg/usage-tests$ chmod 0700 x
0 dkg@alice:~/src/gnupg/usage-tests$ export GNUPGHOME=x
0 dkg@alice:~/src/gnupg/usage-tests$ gpg --import < example.key
gpg: keyring `x/secring.gpg' created
gpg: keyring `x/pubring.gpg' created
gpg: assuming bad signature from key C9A3FA35 due to an unknown critical bit
gpg: x/trustdb.gpg: trustdb created
gpg: key C9A3FA35: public key "test key with dsa subkey" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
0 dkg@alice:~/src/gnupg/usage-tests$ gpg --edit-key test
gpg (GnuPG) 1.4.12; 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


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

So there might be three cases (setting aside the notation business for
the moment):

0) the first case has no key usage flags subpacket at all -- this might
be a legacy key, for example, before the usage flag subpacket existed.

1) a key usage flags subpacket exists, but is 0 octets

2) a key usage flags subpacket exists, is 1 octet in length, with a
value of 0x00.

I think gpg is definitely doing the wrong thing with case 2. I think
it's doing the right thing with case 0, and i haven't managed to test
case 1 yet (i think case 1 should properly be handled like case 2 based
on the section you quote above.

>> * (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 :-)

that's why i'm asking :)

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Mar 12, 2013, at 4:51 PM, Daniel Kahn Gillmor <dkg@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


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
I'm a little worried by this thread and a similar thread. If I understand
correctly, the key usage flags are there in large part to ensure the
integrity of the underlying cryptography by ensuring that a key meant for
signing is not used for encryption and vice-versa, and thereby to close
some potential weaknesses. I can see that the "Certification" flag muddles
things a little, but I think the principle is still there that the flags
designate fairly fundamental operations.

Hints as to what a key should be used for are typically part of the User-id
packets. And perhaps there is no harm in having a subkey marked with a
critical notation hinting at an application-sepecific use. And if it
really is "critical" that this be observed, then of course applications
that do not understand that notation should not use the key.

All the same, wanting to use one subkey for one application (email) and
other for another service seems to me to be attempting to push the
key-subkey framework beyond its design limitations. I *certainly* think
you shouldn't be generating keys that have no usage flags. That looks to
me as if it is certain to (at best) introduce interoperability issues and
(at worse) introduce the potential for some security-undermining errors.

But I'm not a cryptographer, so perhaps I've misunderstood.

At any rate, I've always thought that people would be best off generating a
new key for each individual use (the classic case being home vs work)
rather than attempting to do complicated operations involving subkeys and
the like.

But perhaps I've just misunderstood the intention.

Best wishes,

N.
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On 03/14/2013 10:34 AM, Nicholas Cole wrote:

> Hints as to what a key should be used for are typically part of the User-id
> packets.

I disagree with this pretty strongly. User IDs are associated with
primary keys, and subkeys are also associated with primary keys. There
is no linkage between User IDs and subkeys.

Also, a User ID is supposed to indentify the keyholder -- placing
non-identity-related text in the User ID can be problematic.

If a keyholder wants to indicate that a given subkey is for a specific
use, this should be done in the subkey binding signature; with key usage
flags if they are able to express the desired details, or with notations
(or other subpackets?) if key usage flags are insufficient.

> All the same, wanting to use one subkey for one application (email) and
> other for another service seems to me to be attempting to push the
> key-subkey framework beyond its design limitations.

This is precisely what the key-subkey framework is designed to do as far
as i understand it. why is this pushing it beyond its design limitations?

> I *certainly* think
> you shouldn't be generating keys that have no usage flags. That looks to
> me as if it is certain to (at best) introduce interoperability issues and
> (at worse) introduce the potential for some security-undermining errors.

Here's the concern: if we use a known usage flag, one that indicates
that keys should be acceptable in a given context, then they will most
likely be used in that context. So if you want to add a subkey that
should *not* be used in any of those contexts, you need to ensure all
those usage flag bits are cleared.

Alternately, you can pick the broader category via the usage flag (e.g.
authentication-capablility), and supply a notation to indicate what
scope it is supposed to apply to. If you do that, and you don't mark
the notation as "critical" then the key usage will be applied more broadly.

I don't really see a clear alternative, though i'm willing to consider
other proposals.

> At any rate, I've always thought that people would be best off generating a
> new key for each individual use (the classic case being home vs work)
> rather than attempting to do complicated operations involving subkeys and
> the like.

I think this would be a waste of the existing certification
infrastructure, and it would make it even harder to verify people across
domains. How many fingerprints should two people need to exchange in
person to be able to identify each other online?

Practically, one fingerprint per person is about the upper limit of what
most people are willing to do. OpenPGP's subkey mechanism permits
people to bootstrap a wide variety of keys useful for different contexts
off of a single exchange of a primary key fingerprint.

Suggesting that people maintain multiple primary keys as part of
managing a single identity seem like it would make it more difficult
for people to participate in a process that is already probably more
complicated than people want it to be. I think that's a bad tradeoff.

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On 03/13/2013 06:27 PM, David Shaw wrote:
> Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior.

yeah, i think this needs fixing.

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

OK, i'm glad to hear that certification isn't treated this way (though
it's a bit weird for gpg to show the "C" usage flag if it doesn't
consider it acceptable).

However (certification aside), the other capabilities are just as
relevant. it's not appropriate for a subkey marked clearly as "not for
signing" to be treated as acceptable for signing documents, and it would
be a mistake for a subkey to be considered acceptable for encryption if
the keyholder had explicitly marked it as "not for use with encryption".

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Thu, Mar 14, 2013 at 4:02 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net>wrote:

> On 03/14/2013 10:34 AM, Nicholas Cole wrote:
>
> > Hints as to what a key should be used for are typically part of the
> User-id
> > packets.
>
> I disagree with this pretty strongly. User IDs are associated with
> primary keys, and subkeys are also associated with primary keys. There
> is no linkage between User IDs and subkeys.
>
> Also, a User ID is supposed to indentify the keyholder -- placing
> non-identity-related text in the User ID can be problematic.
>

I think we just disagree, and I completely respect your opinion and what
you are trying to achieve. I don't (quite) see the point of having keys
dedicated to (e.g.) email vs instant messaging, but I do see what you are
trying to achieve.

Of course, you are right that UIDs attach to the primary key not the subkey.

But the second part of what you've written above is not really true. Most
UID packets contain an email address, or things that look very much like
email addresses. I know that email addresses are sometimes used as IDs on
different services, but it would be very possible (if you were prepared to
have different primary keys for different purposes) to specify a service
that they key was used for in the UID (either in the "email" or the
"comment" part. There is already a huge blurring of the line between
identity and application in the UID, both by design and in use.

If a keyholder wants to indicate that a given subkey is for a specific
> use, this should be done in the subkey binding signature; with key usage
> flags if they are able to express the desired details, or with notations
> (or other subpackets?) if key usage flags are insufficient.
>
> > All the same, wanting to use one subkey for one application (email) and
> > other for another service seems to me to be attempting to push the
> > key-subkey framework beyond its design limitations.
>
> This is precisely what the key-subkey framework is designed to do as far
> as i understand it. why is this pushing it beyond its design limitations?


Again, I'm not sure this is true. The subkey was intended to do two things:

First and foremost to make sure that the same key was not used for both
signing and encryption (generally, not on an application-sepcific basis).

Second to make sure that it was possible to change encryption (and perhaps
signing) keys while preserving the trust of the primary key (in an attempt
to solve the problem of a reluctance to change primary keys every few
years).

What you are trying to do is introduce the idea of application-sepcific
keys. It seems like a niche area to me. Totally fine if you can achieve
it with notations, of course, but probably not something with wide
application.

I put my initial point badly, and perhaps what I mean to propose is this:

- don't get rid of the usage flags, because I think there is an importance
of saying "it's ok to use this key for encryption" or for signing or
whatever. But make sure that your application uses BOTH the notations and
the usage flags when deciding whether to use a particular subkey for a
given purpose. Set the critical notation bit for those subkeys that you
absolutely never want to be used outside of a specific application, and
hope that OpenPGP software respects the standard enough to ignore them.



> Here's the concern: if we use a known usage flag, one that indicates
>
that keys should be acceptable in a given context, then they will most
> likely be used in that context. So if you want to add a subkey that
> should *not* be used in any of those contexts, you need to ensure all
> those usage flag bits are cleared.


Well, as I say, isn't it the case that the critical notation bit achieves
this without removing the flags?


>
> > At any rate, I've always thought that people would be best off
> generating a
> > new key for each individual use (the classic case being home vs work)
> > rather than attempting to do complicated operations involving subkeys and
> > the like.
>
> I think this would be a waste of the existing certification
> infrastructure, and it would make it even harder to verify people across
> domains. How many fingerprints should two people need to exchange in
> person to be able to identify each other online?


Well, this is a bigger problem with openpgp. You are quite right. The web
of trust has never worked quite as easily as hoped (is this related to the
Eternal September problem?) and the problem looks set to get worse if a new
key standard introduces even longer fingerprints that people will be even
more reluctant to exchange.

I don't have a solution, of course.

I completely accept that you don't want to maintain different primary keys
for different purposes. Though just for the sake of completeness I'll
point out that you could use Trust Signatures and multiple primary keys to
achieve the effect of what you want. Maybe.

There is a practical security point here, too. In the real world, it would
be much easier, (for example) when leaving an employer, to leave a copy of
a primary key and subkeys than to leave a collection of subkeys (even
though I know it is technically possible.)

N.
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Thu, 14 Mar 2013 17:05, dkg@fifthhorseman.net said:
> On 03/13/2013 06:27 PM, David Shaw wrote:
>> Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior.
>
> yeah, i think this needs fixing.

What about this untested patch against master:

commit 8f8f3984e82a025cf1384132a419f67f39c7e07d
Author: Werner Koch <wk@gnupg.org>
Date: Fri Mar 15 15:46:03 2013 +0100

gpg: Distinguish between missing and cleared key flags.

* include/cipher.h (PUBKEY_USAGE_NONE): New.
* g10/getkey.c (parse_key_usage): Set new flag.
--

We do not want to use the default capabilities (derived from the
algorithm) if any key flags are given in a signature. Thus if key
flags are used in any way, the default key capabilities are never
used.

This allows to create a key with key flags set to all zero so it can't
be used. This better reflects common sense.

Modified g10/getkey.c
diff --git a/g10/getkey.c b/g10/getkey.c
index 9294273..8cc5601 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1276,13 +1276,19 @@ parse_key_usage (PKT_signature * sig)

if (flags)
key_usage |= PUBKEY_USAGE_UNKNOWN;
+
+ if (!key_usage)
+ key_usage |= PUBKEY_USAGE_NONE;
}
+ else if (p) /* Key flags of length zero. */
+ key_usage |= PUBKEY_USAGE_NONE;

/* We set PUBKEY_USAGE_UNKNOWN to indicate that this key has a
capability that we do not handle. This serves to distinguish
between a zero key usage which we handle as the default
capabilities for that algorithm, and a usage that we do not
- handle. */
+ handle. Likewise we use PUBKEY_USAGE_NONE to indicate that
+ key_flags have been given but they do not specify any usage. */

return key_usage;
}
Modified include/cipher.h
diff --git a/include/cipher.h b/include/cipher.h
index 191e197..557ab70 100644
--- a/include/cipher.h
+++ b/include/cipher.h
@@ -54,9 +54,14 @@

#define PUBKEY_USAGE_SIG GCRY_PK_USAGE_SIGN /* Good for signatures. */
#define PUBKEY_USAGE_ENC GCRY_PK_USAGE_ENCR /* Good for encryption. */
-#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys. */
+#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys.*/
#define PUBKEY_USAGE_AUTH GCRY_PK_USAGE_AUTH /* Good for authentication. */
#define PUBKEY_USAGE_UNKNOWN GCRY_PK_USAGE_UNKN /* Unknown usage flag. */
+#define PUBKEY_USAGE_NONE 256 /* No usage given. */
+#if (GCRY_PK_USAGE_SIGN | GCRY_PK_USAGE_ENCR | GCRY_PK_USAGE_CERT \
+ | GCRY_PK_USAGE_AUTH | GCRY_PK_USAGE_UNKN) >= 256
+# error Please choose another value for PUBKEY_USAGE_NONE
+#endif

#define DIGEST_ALGO_MD5 /* 1 */ GCRY_MD_MD5
#define DIGEST_ALGO_SHA1 /* 2 */ GCRY_MD_SHA1


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On 03/15/2013 10:52 AM, Werner Koch wrote:

> What about this untested patch against master:

I just tested it against 1.4.12, and it works for me:

0 dkg@alice:~/src/gnupg/usage-tests$ gpg --list-keys
tru::1:1362476341:1365068202:3:1:5
pub:u:1024:1:F848882DC9A3FA35:1362476202:1365068202::u:::scSCA:
uid:u::::1362476202::8A8AA0A65B6EC7E3D344786B37602CE3D91C1642::test key
with dsa subkey:
sub:u:1024:17:39476078BD60397C:1362476412:1365068412:::::a:
sub:u:512:17:24940DE048B80074:1362695370:1365287370:::::sca:
sub:u:768:17:867E55E65BA8B581:1363119647:1363724447::::::
0 dkg@alice:~/src/gnupg/usage-tests$

thanks! one minor note below:

> diff --git a/include/cipher.h b/include/cipher.h
> index 191e197..557ab70 100644
> --- a/include/cipher.h
> +++ b/include/cipher.h
> @@ -54,9 +54,14 @@
>
> #define PUBKEY_USAGE_SIG GCRY_PK_USAGE_SIGN /* Good for signatures. */
> #define PUBKEY_USAGE_ENC GCRY_PK_USAGE_ENCR /* Good for encryption. */
> -#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys. */
> +#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys.*/

^^ this whitespace change in the comments doesn't seem to be relevant or
necessary to me.

Do you think it's worth applying the small changeset i suggested earlier
that allows creation of all-zero usage flag subpacket as well, or is
that something that we should treat separately?

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Fri, 15 Mar 2013 21:34, dkg@fifthhorseman.net said:

> i think the empty string is a clear and unambiguous description of "no
> key flags set". I don't see a need to special-case a "-", but i'd be

There is another option: Add an '?' if tehre is any unknown key flag.

> My patch was just removing 3 lines ( ~ 30 bytes ) from
> do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright
> pertaining at all, but i'm fine waiting if you want me to wait.

Okay, send again.

> Out of curiosity: why only apply this to master? is the goal to ensure
> that there is a chance for the handlers to propagate widely before any
> tool makes it easy to build?

New features should only go into master. In particular changes which
are not really needed by todays users. Granted, it is also an incentive
to migrate to newer versions.

> I'm assuming you are OK applying the subkey flag usage fix (your patch)
> to all maintained branches; it's just the patch that allows one to

Sure. It is a bug.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On 03/19/2013 10:52 AM, Werner Koch wrote:
> On Fri, 15 Mar 2013 21:34, dkg@fifthhorseman.net said:
>
>> i think the empty string is a clear and unambiguous description of "no
>> key flags set". I don't see a need to special-case a "-", but i'd be
>
> There is another option: Add an '?' if tehre is any unknown key flag.

yep, this makes sense to me, assuming you mean that some unknown key
flag is set (that is, that the bit is 1, not 0) -- but ? shouldn't be
present if there is an all-zero usage flags subpacket.

>> My patch was just removing 3 lines ( ~ 30 bytes ) from
>> do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright
>> pertaining at all, but i'm fine waiting if you want me to wait.
>
> Okay, send again.

it's attached to this mail.

>> I'm assuming you are OK applying the subkey flag usage fix (your patch)
>> to all maintained branches; it's just the patch that allows one to
>
> Sure. It is a bug.

great. thanks!

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Tue 2013-03-19 11:25:25 -0400, Daniel Kahn Gillmor wrote:

> On 03/19/2013 10:52 AM, Werner Koch wrote:
>> On Fri, 15 Mar 2013 21:34, dkg@fifthhorseman.net said:
>>> My patch was just removing 3 lines ( ~ 30 bytes ) from
>>> do_add_key_flags() in g10/keygen.c -- i don't see any sort of copyright
>>> pertaining at all, but i'm fine waiting if you want me to wait.
>>
>> Okay, send again.
>
> it's attached to this mail.

--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -210,9 +210,6 @@
if (use & PUBKEY_USAGE_AUTH)
buf[0] |= 0x20;

- if (!buf[0])
- return;
-
build_sig_subpkt (sig, SIGSUBPKT_KEY_FLAGS, buf, 1);
}

I don't think the above patch (to enable creation of a subkey with a
usage flags subpacket, but no usage flags set) was ever applied to
either the 1.4 or 2.0 branches -- is this something you would be OK
adding to a stable branch, or is it only going to be in 2.1/master?

thanks,

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Fri 2013-03-15 10:52:16 -0400, Werner Koch wrote:

> On Thu, 14 Mar 2013 17:05, dkg@fifthhorseman.net said:
>> On 03/13/2013 06:27 PM, David Shaw wrote:
>>> Yes. Having no flags set at all is treated as if there is no subpacket present. This may not be the best behavior.
>>
>> yeah, i think this needs fixing.
>
> What about this untested patch against master:
>
> commit 8f8f3984e82a025cf1384132a419f67f39c7e07d
> Author: Werner Koch <wk@gnupg.org>
> Date: Fri Mar 15 15:46:03 2013 +0100
>
> gpg: Distinguish between missing and cleared key flags.
>
> * include/cipher.h (PUBKEY_USAGE_NONE): New.
> * g10/getkey.c (parse_key_usage): Set new flag.
> --
>
> We do not want to use the default capabilities (derived from the
> algorithm) if any key flags are given in a signature. Thus if key
> flags are used in any way, the default key capabilities are never
> used.
>
> This allows to create a key with key flags set to all zero so it can't
> be used. This better reflects common sense.
>
> Modified g10/getkey.c
> diff --git a/g10/getkey.c b/g10/getkey.c
> index 9294273..8cc5601 100644
> --- a/g10/getkey.c
> +++ b/g10/getkey.c
> @@ -1276,13 +1276,19 @@ parse_key_usage (PKT_signature * sig)
>
> if (flags)
> key_usage |= PUBKEY_USAGE_UNKNOWN;
> +
> + if (!key_usage)
> + key_usage |= PUBKEY_USAGE_NONE;
> }
> + else if (p) /* Key flags of length zero. */
> + key_usage |= PUBKEY_USAGE_NONE;
>
> /* We set PUBKEY_USAGE_UNKNOWN to indicate that this key has a
> capability that we do not handle. This serves to distinguish
> between a zero key usage which we handle as the default
> capabilities for that algorithm, and a usage that we do not
> - handle. */
> + handle. Likewise we use PUBKEY_USAGE_NONE to indicate that
> + key_flags have been given but they do not specify any usage. */
>
> return key_usage;
> }
> Modified include/cipher.h
> diff --git a/include/cipher.h b/include/cipher.h
> index 191e197..557ab70 100644
> --- a/include/cipher.h
> +++ b/include/cipher.h
> @@ -54,9 +54,14 @@
>
> #define PUBKEY_USAGE_SIG GCRY_PK_USAGE_SIGN /* Good for signatures. */
> #define PUBKEY_USAGE_ENC GCRY_PK_USAGE_ENCR /* Good for encryption. */
> -#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys. */
> +#define PUBKEY_USAGE_CERT GCRY_PK_USAGE_CERT /* Also good to certify keys.*/
> #define PUBKEY_USAGE_AUTH GCRY_PK_USAGE_AUTH /* Good for authentication. */
> #define PUBKEY_USAGE_UNKNOWN GCRY_PK_USAGE_UNKN /* Unknown usage flag. */
> +#define PUBKEY_USAGE_NONE 256 /* No usage given. */
> +#if (GCRY_PK_USAGE_SIGN | GCRY_PK_USAGE_ENCR | GCRY_PK_USAGE_CERT \
> + | GCRY_PK_USAGE_AUTH | GCRY_PK_USAGE_UNKN) >= 256
> +# error Please choose another value for PUBKEY_USAGE_NONE
> +#endif
>
> #define DIGEST_ALGO_MD5 /* 1 */ GCRY_MD_MD5
> #define DIGEST_ALGO_SHA1 /* 2 */ GCRY_MD_SHA1
>

As i reported earlier, this fix works fine. I've backported it against
1.4.14 and it works there too (below). It does not seem to be applied
to the stable branches (1.4 and 2.0). I think it needs to be applied
to the stable branches.

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

This is dangerous in several ways:

* if it's your own key, GnuPG will use it to sign messages or certify
other OpenPGP certificates

* if it's someone else's key, GnuPG will encrypt to it

* if it's someone else's key, GnuPG may be willing to rely on OpenPGP
certifications made by the key, despite the owner having clearly
marked that it is not acceptable for that use.

Depending on how such a key is actually used in practice, this may cause
unrelated confidential data to be revealed, or it may let GnuPG follow
spoofable paths through the WoT. It can can also cause invalid
signatures to be issued, which has already affected me in as a mini
self-DoS (i have a primary key with a subkey with such an empty
usage-flags subpacket that i have avoided publishing out of wariness; i
sent a message to an automated service which requires signed mail, and
the message was rejected because it was made by this subkey).

While very few people have such keys in practice right now (i might be
the only person experimenting with them -- i'm trying to circumscribe
the use of experimental subkeys to much more specific application
domains than the usage flags permit), it would be bad if these keys
continue to misinterpreted by GnuPG.

I'm inclined to see this as a security vulnerability (because of the
confidentiality and certification-following concerns); i'd like to see
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.

Any objections to this plan? I am happy to request the CVE myself, and
will report it back here once it is assigned.

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Wed 2013-09-11 17:46:41 -0400, Daniel Kahn Gillmor wrote:
> 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).
>
> This is dangerous in several ways:
>
> * if it's your own key, GnuPG will use it to sign messages or certify
> other OpenPGP certificates
>
> * if it's someone else's key, GnuPG will encrypt to it
>
> * if it's someone else's key, GnuPG may be willing to rely on OpenPGP
> certifications made by the key, despite the owner having clearly
> marked that it is not acceptable for that use.
>
> Depending on how such a key is actually used in practice, this may cause
> unrelated confidential data to be revealed, or it may let GnuPG follow
> spoofable paths through the WoT.

[...]

> I'm inclined to see this as a security vulnerability (because of the
> confidentiality and certification-following concerns); i'd like to see
> 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.

This is now CVE-2013-4351.

Regards,

--dkg
Re: subkey binding signature with no usage flags and/or a critical notation [ In reply to ]
On Wed, 11 Sep 2013 23:46, dkg@fifthhorseman.net said:

> As i reported earlier, this fix works fine. I've backported it against
> 1.4.14 and it works there too (below). It does not seem to be applied
> to the stable branches (1.4 and 2.0). I think it needs to be applied
> to the stable branches.

It is quite possible that I lost track of it.

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

> * if it's someone else's key, GnuPG may be willing to rely on OpenPGP
> certifications made by the key, despite the owner having clearly

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

> sent a message to an automated service which requires signed mail, and
> the message was rejected because it was made by this subkey).

Old PGP versions (iirc < 6.58) were not abale to handle sugnature
subkeys. Same hoes for old keyservers.

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

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


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags [ In reply to ]
On 09/14/2013 04:51 AM, Werner Koch wrote:
> On Wed, 11 Sep 2013 23:46, dkg@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
Re: subkey binding signature with no usage flags [ In reply to ]
On 9/14/2013 11:44 AM, Daniel Kahn Gillmor wrote:
> 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.

You have not discovered a security vulnerability in either GnuPG or SKS.
You have discovered that users who are not as clever as they think can
use the --expert flag to do foolish things, and that some of these
foolish things have consequences attached.

To this, all I can say is I hope the GnuPG developers triage this as
NOTABUG and WONTFIX.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags [ In reply to ]
On 09/14/2013 12:26 PM, Robert J. Hansen wrote:
> On 9/14/2013 11:44 AM, Daniel Kahn Gillmor wrote:
>> 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.
>
> You have not discovered a security vulnerability in either GnuPG or SKS.

The issue under discussion in this thread has nothing to do with SKS.

> You have discovered that users who are not as clever as they think can
> use the --expert flag to do foolish things, and that some of these
> foolish things have consequences attached.

This also has nothing to do with gnupg's --expert flag. Neither stable
branch of GnuPG can in its current form generate keys with all the usage
flags set to zero.

This is about interoperability with other OpenPGP implementations
(including possible future versions of GnuPG, but that's a separate
issue) that may include the ability to set an all-zero key flags
subpacket in their subkey binding signatures.

> To this, all I can say is I hope the GnuPG developers triage this as
> NOTABUG and WONTFIX.

This bug is already fixed in the master branch. Are you suggesting that
the fix should be reverted?

Regards,

--dkg
Re: subkey binding signature with no usage flags [ In reply to ]
On 9/14/2013 12:45 PM, Daniel Kahn Gillmor wrote:
> This bug is already fixed in the master branch. Are you suggesting that
> the fix should be reverted?

My apologies: I read that message and (erroneously) believed it was the
current thread on sks-devel@nongnu.org. Mea culpa!



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags [ In reply to ]
On Sat, Sep 14, 2013 at 5:45 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On 09/14/2013 12:26 PM, Robert J. Hansen wrote:
>> On 9/14/2013 11:44 AM, Daniel Kahn Gillmor wrote:
>>> 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.
>>
>> You have not discovered a security vulnerability in either GnuPG or SKS.
>
> The issue under discussion in this thread has nothing to do with SKS.
>
>> You have discovered that users who are not as clever as they think can
>> use the --expert flag to do foolish things, and that some of these
>> foolish things have consequences attached.
>
> This also has nothing to do with gnupg's --expert flag. Neither stable
> branch of GnuPG can in its current form generate keys with all the usage
> flags set to zero.
>
> This is about interoperability with other OpenPGP implementations
> (including possible future versions of GnuPG, but that's a separate
> issue) that may include the ability to set an all-zero key flags
> subpacket in their subkey binding signatures.
>
>> To this, all I can say is I hope the GnuPG developers triage this as
>> NOTABUG and WONTFIX.
>
> This bug is already fixed in the master branch. Are you suggesting that
> the fix should be reverted?

This wasn't a bug, it was a new feature request. I still don't
understand the wisdom of it. As far as I know there are no other
implementations that do anything like this. As such, there is no
'interoperability' issue, and for that matter I don't know how other
implementations handle keys with no usage flags set. It all seems a
bit too clever. If I remember correctly, you want this so that you
can have subkeys reserved for specific protocols. I've never quite
understood what the benefit of this is. Moreover, I never understood
why it couldn't have been achieved with a critically flagged notation,
without needing to change anything about the key usage flags.

I really don't mean to sound unduly negative - but key management is
already very complicated in gpg. I'm all for adding things with a
genuine utility, but not really for adding things that add complexity
without really adding security.

But, as you say, it's in the Master now.

N

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: subkey binding signature with no usage flags [ In reply to ]
On 09/14/2013 01:42 PM, Nicholas Cole wrote:

> This wasn't a bug, it was a new feature request.

i'm sorry, but i don't agree with this. I have made a (related) feature
request, which was to enable gpg to *create* subkeys without any usage
flags set for --expert users. (and yes, that's been merged in master as
well, and i recognize that it is less likely to be adopted in the stable
branches -- that's fine)

That was separate and distinct issue from what i'm asking about here.

Here, i'm asking GnuPG to properly interpret received signatures that
have the usage flags subpacket present but empty.

This latter issues is a bug report, not a feature request.

--dkg