Thoughts on PGP vs signify and age?

[CranialRitalin5084]

What are your thoughts, is it time to retire PGP for newer tools?

Will Qubes transition at some point?

[Konstantin Ryabitsev]

On Sat, Mar 14, 2020 at 01:38:05PM -0700, CranialRitalin5084 wrote:
> What are your thoughts, is it time to retire PGP for newer tools?

Signify is solving a slightly different problem than PGP is --
specifically, it doesn't concern itself with trust delegation or key
management.

For example, if you wanted to check a signify signature, you'd need to
get the public key from somewhere -- the project website, an email
message, a forum post, etc. All of these cases require that you trust
the medium and the connection (the site isn't hacked to show the wrong
public key, and nobody is reading your email to substitute the proper
key with a bogus one).

Furthermore, if the private key is compromised and can no longer be
trusted, there is absolutely no mechanism to tell minisign/signify
"don't use that key!". You are just supposed to be paying attention and
switch to the newer key when you're told to do so.

Now, PGP has a solution for these problems in the form of the Web of
Trust and a key revocation framework. Both of these things suck -- but
not because GnuPG's implementation of them sucks, but because it's a
hard problem to solve and any solution is going to be complicated and
cumbersome. Nobody outside of niche communities is using the Web of
Trust, and very few people refresh their keyrings frequently enough for
the key revocation to work reliably.

However, at least PGP tries to offer *some* solution to delegated trust
and key management. For those who don't care about these aspects, GnuPG
is now offering the Trust-On-First-Use (TOFU) trust model, in which a
key is marked as trusted the first time you encounter it. If you come
across another key with the same identity on it, GnuPG will mark both
keys untrusted and let you figure out which one is "the real one."

In my mind, signify-style signatures make sense when signing software
releases or packages, since in this case we implicitly trust the
distribution to do all trust management. For software releases, the
public key can be published in a signed DNS zone (trust delegated to
DNSSec) or posted on the website (trust delegated to commercial CAs).

For all other uses, and until signify gains some kind of key management
framework, e.g. via various Distributed-Identity (DID) frameworks, PGP
is still the way to go.

> Will Qubes transition at some point?

I think Qubes should offer signify-style signatures on its released
objects, sure.

-K

[Chris Laprise]

On 3/18/20 1:48 PM, Konstantin Ryabitsev wrote:
>> Will Qubes transition at some point?
>
> I think Qubes should offer signify-style signatures on its released
> objects, sure.

But how does this help?

I find myself often using GPG the same way you describe signify. The WOT
stuff is optional and can be used on a case-by-case basis. Most people
don't realize this when they start reading PGP/GPG guides... importing
keys can be a mere formality if you want it that way.

GPG does have a UI problem; the listings in particular are cryptic (no
pun). So I don't see an actual reason to change, and also I think Joanna
Rutkowska (although no longer with Qubes) is right to be supportive of
the GPG project.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Konstantin Ryabitsev]

On Wed, Mar 18, 2020 at 02:16:34PM -0400, Chris Laprise wrote:
> On 3/18/20 1:48 PM, Konstantin Ryabitsev wrote:
> > > Will Qubes transition at some point?
> >
> > I think Qubes should offer signify-style signatures on its released
> > objects, sure.
>
> But how does this help?

Mostly, because it's easier. I maintain the following page on how to
verify linux kernel release signatures:

https://www.kernel.org/signature.html

For someone who doesn't already have the proper PGP key in their
keyring, the process is:

gpg --locate-key ...
gpg --tofu-policy good [keyid]
gpg --trust-model tofu --verify filename

For a signify/minisign signature, the process is a one-liner:

minisign -P [pubkey] -Vm filename

It's a single copy-paste from the website.

> I find myself often using GPG the same way you describe signify. The WOT
> stuff is optional and can be used on a case-by-case basis. Most people don't
> realize this when they start reading PGP/GPG guides... importing keys can be
> a mere formality if you want it that way.
>
> GPG does have a UI problem; the listings in particular are cryptic (no pun).
> So I don't see an actual reason to change, and also I think Joanna Rutkowska
> (although no longer with Qubes) is right to be supportive of the GPG
> project.

I'm not at all saying we should abandon PGP -- I'm just suggesting that
Qubes releases can offer .minisign signature *in addition* to PGP. I
believe this has a benefit of making one-off verification a more
straightforward process.

-K

[Sven Semmler]

On Wed, Mar 18, 2020 at 02:24:48PM -0400, Konstantin Ryabitsev wrote:
> I'm not at all saying we should abandon PGP -- I'm just suggesting that
> Qubes releases can offer .minisign signature *in addition* to PGP. I
> believe this has a benefit of making one-off verification a more
> straightforward process.

You are clearly an authority on the topic, so please take this as a
question not critisism ... what's the point of a signature if I
haven't verified they key?

That's my take-away from this thread. That signify makes it easier for
people who don't care to validate the key.

Some years ago when I first started using Qubes I followed this
instruction: https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity

In particular the part where I searched they web for fingerprints of the
qubes master signing key and also looked at slides from Joanna using
serveral machines at different locations / networks. Only then I trusted
it.

I get all of that. That makes sense to me. And the trust flows from the
master key to the release signing keys.

Without that ... what's the signature worth?

/Sven

--
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

[Chris Laprise]

On 3/18/20 2:24 PM, Konstantin Ryabitsev wrote:
> On Wed, Mar 18, 2020 at 02:16:34PM -0400, Chris Laprise wrote:
>> On 3/18/20 1:48 PM, Konstantin Ryabitsev wrote:
>>>> Will Qubes transition at some point?
>>>
>>> I think Qubes should offer signify-style signatures on its released
>>> objects, sure.
>>
>> But how does this help?
>
> Mostly, because it's easier. I maintain the following page on how to
> verify linux kernel release signatures:
>
> https://www.kernel.org/signature.html
>
> For someone who doesn't already have the proper PGP key in their
> keyring, the process is:
>
> gpg --locate-key ...
> gpg --tofu-policy good [keyid]
> gpg --trust-model tofu --verify filename

How about simply:

gpg --import key.asc
gpg --verify <etc>

In this case gpg will tell you if a signature is good, even though it
will also say the key isn't marked as trusted. That marking isn't needed
for the simple kind of verification process we're talking about. The
difference here really comes down to aesthetics.

[Konstantin Ryabitsev]

On Thu, Mar 19, 2020 at 06:01:52AM -0400, Chris Laprise wrote:
> > Mostly, because it's easier. I maintain the following page on how to
> > verify linux kernel release signatures:
> >
> > https://www.kernel.org/signature.html
> >
> > For someone who doesn't already have the proper PGP key in their
> > keyring, the process is:
> >
> > gpg --locate-key ...
> > gpg --tofu-policy good [keyid]
> > gpg --trust-model tofu --verify filename
>
> How about simply:
>
> gpg --import key.asc
> gpg --verify <etc>
>
> In this case gpg will tell you if a signature is good, even though it will
> also say the key isn't marked as trusted. That marking isn't needed for the
> simple kind of verification process we're talking about. The difference here
> really comes down to aesthetics.

Yes, but that big "WARNING THIS KEY IS NOT TRUSTED!!!" inevitably
resulted in a bunch of people thinking something went wrong, despite
instructions saying that it's expected. This is why we switched to
forcing "--trust-model tofu" in these instructions.

-K

[Konstantin Ryabitsev]

On Wed, Mar 18, 2020 at 09:51:48PM -0500, Sven Semmler wrote:
> > I'm not at all saying we should abandon PGP -- I'm just suggesting
> > that Qubes releases can offer .minisign signature *in addition* to
> > PGP. I believe this has a benefit of making one-off verification a
> > more straightforward process.
>
> You are clearly an authority on the topic, so please take this as a
> question not critisism ... what's the point of a signature if I
> haven't verified they key?
>
> That's my take-away from this thread. That signify makes it easier for
> people who don't care to validate the key.

That's not entirely correct. Signify makes it easier for people who want
to delegate trust to the HTTPS layer. They may not have necessarily
grabbed the file they are verifying from www.qubes-os.org -- e.g. they
may have downloaded it from mirrors.kernel.org or from any number of
other locations. For them, having a command they can copy-paste from the
official website to verify that the file is valid and "trusted enough"
is all they need.

> Some years ago when I first started using Qubes I followed this
> instruction: https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity
>
> In particular the part where I searched they web for fingerprints of the
> qubes master signing key and also looked at slides from Joanna using
> serveral machines at different locations / networks. Only then I trusted
> it.

That doesn't need to be any different from minisign. There are still
fingerprints people can post in their slides and in email signatures. :)
Or even the whole key, since it fits well within 80 columns.
Here's mine:

$ cat .minisign/default.pub
untrusted comment: minisign public key 47CC29EB28145245
RWRFUhQo6ynMR/8oMMSHQz0VDlJh/kNV7fVNugMxatoMQbDG5DHgsy8y

> I get all of that. That makes sense to me. And the trust flows from the
> master key to the release signing keys.
>
> Without that ... what's the signature worth?

I laud your dedication and I am not at all suggesting that we do away
with PGP. I merely suggest that it could be used in delegated-trust
situations and make the verification process much simpler for users to
follow.

-K

[Sven Semmler]

On Thu, Mar 19, 2020 at 06:11:05PM -0400, Konstantin Ryabitsev wrote:
> That doesn't need to be any different from minisign. There are still
> fingerprints people can post in their slides and in email signatures. :)
> Or even the whole key, since it fits well within 80 columns.

Got it.

> with PGP. I merely suggest that it could be used in delegated-trust
> situations and make the verification process much simpler for users to
> follow.

Thanks for the clarification!

[dragon788]

I think GPG is probably going to be used by a lot of projects for quite a while. The Web of Trust is a somewhat limiting factor, but I really like how Keybase.io has made it much easier to "follow" a developer or project and detect when the key changes, prompting you the next time you try to interact with it and making it a little easier to discover their new information.