Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jul 2013 20:42:14 -0600
From: Kurt Seifried <>
To: Daniel Kahn Gillmor <>
CC:, Yves-Alexis Perez <>
Subject: Re: CVE Request: evolution mail client GPG key selection

Hash: SHA1

On 07/25/2013 02:10 PM, Daniel Kahn Gillmor wrote:
> On 07/25/2013 03:19 PM, Kurt Seifried wrote:
>> One problem moving it to the backend is I may trust your key to
>> sign email, but not to sign code and vice versa. At least for RPM
>> this is handled internally (you install the key into RPM) so
>> that's one less worry.
> gpg doesn't claim to know *anything* about what you "trust" keys to
> do other than whether you're willing to rely on that key to certify
> other keys.

Yeah that was why I think in some cases it's better to have the policy
decision in the front end which would support more subtle distinctions
than "trust" and "no trust".

> gpg can tell you "this message was signed by dkg" but it cannot
> (and should not) say "dkg is allowed to upgrade your libc".

True, but as a thought experiment, an extension to GPG or perhaps a
layer sitting on top of it that let you specify properties with the
key like "allow signing of sandboxed apps" or "allow signing of core
system apps" or "allow signing of documents" or "allow signing of
legal document" and so on, allowing you to keep that policy in one
spot rather than in your software package manager, your word
processor, etc. seems like not the worst idea. Although realistically
it would become hideously complicated and messy and no-one would have
any idea what their settings were or what they meant (much like
browser security settings back in the day).

> basically, gpg's job is to handle the authentication side of
> things (which is all that an MUA cares about) but *not* to handle
> the authorization side of things.
> Authorization is rightly scoped by different uses of the
> infrastructure, as you suggest.  Some work is being done on this
> too: Stef Walter's current developments of p11-kit aim at allowing
> tools in a similar domain (initially, web site X.509 certification
> and potentially code signing) to share authorization information.

Interesting. For completeness:

>> Yup. Key management sucks even with good software, and we don't
>> have good software for this. Witness CRL/OCSP and then all the
>> vendors shipping browser updates to specifically blacklist
>> compromised certificates.
> indeed.  Same sort of problem, same shitty non-scalable solutions
> :(

Well of all people (not to surprising) it looks like entities like
CloudFlare might actually be able to provide reliable OCSP responders
(which sadly no CA ever has AFAIK).

>> Yeah the use of KeyIDs is just stupid (although I get why they
>> did it, I still think it was stupid), they're to short. We should
>> be using fingerprints only. Sigh.
> even if it uses full fingerprints, the fact that i can associate
> your primary key as a (revoked) subkey of mine means i can force
> the keyservers to include one of my keys when anyone goes to
> refresh yours.
>> True, and trust me if my key ever gets compromised (and I know
>> about it) I'll be phoning certain people and not relying on key
>> revocation to let them know.
> That's a good idea, but i hope you don't see the two tactics as
> mutually exclusive.  Personal notification is guaranteed to miss
> some people, especially for people whose key is used publicly (like
> yours is).

Yup, but I'm not relying on my boss/coworkers/you guys noticing key
revocation, I'm calling them and whatnot =)


> --dkg

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.13 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.