Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 04/07/2019 03:29, Phil Pennock wrote:
> Depends upon the implementation.  I'm biased here, I wrote my own in
> Go back in 2016:  https://go.pennock.tech/fingerd/

Nice. I can't see corporate firewall admins buying it though. :-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Phil Pennock via Gnupg-users]

On 2019-07-03 at 09:17 +0100, Andrew Gallagher wrote:
> I didn't even know it supported finger URLs - handy to know! Opening a
> finger port may be a step too far for the security-conscious though...

Depends upon the implementation.  I'm biased here, I wrote my own in
Go back in 2016:  https://go.pennock.tech/fingerd/

See the AttackSurface.md doc therein too.

That provides the finger service for @spodhuis.org ... using the FreeBSD
port 1079 example configuration.  A packet filter redirects port 79 to
the correct port in the Jail which lacks outbound network connectivity
except via NAT state for established connections.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 16:13, Kristian Fiskerstrand wrote:
> potential DoS vector? (probably not the most efficient one, but...)

As in DoS amplification? I create a load of keys with a victim's URL in
the `keyserver` field and the pool does my dirty work? Interesting, but
so long as the keyservers' spiders are well behaved, it should be no
worse than being indexed by Google.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Kristian Fiskerstrand]

On 7/3/19 3:20 PM, Andrew Gallagher wrote:
> On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
>> There are various ways this can be used for other
>> attack vectors as well, so they are mostly just ignored.
> 
> Any of those attack vectors applicable to keyservers attempting to
> refresh from it?
> 

potential DoS vector? (probably not the most efficient one, but...)

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Kristian Fiskerstrand]

On 7/3/19 10:17 AM, Andrew Gallagher wrote:
> On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
>> Beware: the HKP schema of paths is used with the keyserver in that
>> field, in GnuPG at least.
> OK, but what's the failure mode? If it's graceful, then we haven't lost
> much. So long as key updates fall back to a keyserver somewhere it
> should be transparent.
> 
> This does of course need thorough testing, as not all clients will have
> the same failure modes.
> 

at least one issue that has been pointed out historically about relying
on specification of TPK URI for refresh is privacy issues related to
callbacks and/or DoS. There are various ways this can be used for other
attack vectors as well, so they are mostly just ignored.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
> There are various ways this can be used for other
> attack vectors as well, so they are mostly just ignored.

Any of those attack vectors applicable to keyservers attempting to
refresh from it?

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
> Beware: the HKP schema of paths is used with the keyserver in that
> field, in GnuPG at least.

OK, but what's the failure mode? If it's graceful, then we haven't lost
much. So long as key updates fall back to a keyserver somewhere it
should be transparent.

This does of course need thorough testing, as not all clients will have
the same failure modes.

> Using http:/https: didn't help, HKP was still used.

Yes, from my reading this is expected behaviour. It would be relatively
straightforward to create a server-side alias for the HKP URL, depending
on what else is deployed at that location.

> I got around it later by specifying a `finger:` URL.  :)
> It's been 30-40 years since folks last revamped the conventions on top
> of finger.  That one is safe.

I didn't even know it supported finger URLs - handy to know! Opening a
finger port may be a step too far for the security-conscious though...

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Phil Pennock via Gnupg-users]

On 2019-07-02 at 11:56 +0200, Wiktor Kwapisiewicz via Gnupg-users wrote:
> On 01.07.2019 14:36, Andrew Gallagher wrote:
> > OpenPGP already has the "keyserver" field which is rarely used. It is
> > supposedly a hint to clients to tell them to prefer a particular
> > keyserver, but it could also be used as a hint to the keyservers
> > themselves, to tell them where the master copy of any public key can be
> > sourced.
> 
> This sounds like a really good idea.
> 
> This way only one place would have to be updated by the user and keyservers
> would automatically refresh key data themselves.

Beware: the HKP schema of paths is used with the keyserver in that
field, in GnuPG at least.

I can't find the logbooks I'd have kept "somewhere" of my experimenting
at the time, but key 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 in the
first self-sig I see from 2013, includes:

hashed subpkt 24 len 33 (preferred keyserver: 
hkp://ha.pool.sks-keyservers.net/)

and my recollection is that I had tried various alternatives, to point
to a fixed URL where the key was guaranteed to live, but it insisted on
the /pks/ layout, so I gave up and went with HKP, at least pointing
folks towards what at the time was the more reliable option, the HA
pool.  Using http:/https: didn't help, HKP was still used.

I got around it later by specifying a `finger:` URL.  :)
It's been 30-40 years since folks last revamped the conventions on top
of finger.  That one is safe.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 02/07/2019 13:06, Michał Górny via Gnupg-users wrote:
> In Gentoo we're using a CA-like model with a central service signing
> UIDs of all developers.  It is *convenient* for it to be able to inject
> those signatures into keys of the developers, and distribute them along
> with them.

It is convenient, but if it is covenient for you to attach one signature
to the keys of your developers and redistribute, then it is convenient
for an arbitrary person to attach a million sigs and gum up the system.
I think this is one case where convenience will have to be sacrificed no
matter what solution we adopt.

This could be a use case for the "preferred keyserver" extension. If you
ran your own keyserver and your developers set it as their preferred
keyserver, then they would be publicly stating "Allow Gentoo to attach
signatures without my explicit permisson, but distrust everyone else".
This would only have to be done once in advance, and it could be made
part of your new developer onboarding process.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Fri, 2019-06-14 at 10:12 +0200, Oscar Carlsson via Gnupg-users wrote:
> I'm generally curious on your opinions on the latest new keyserver, this 
> time running a new software than the normal keyservers.
> 
> They seem to have a different model which minimize the amount of 
> information available, to be compliant with GDPR and friends. Do you 
> think there are any downsides to this?
> 

Others have already somewhat pointed this out but I believe it hasn't
been emphasized enough: in my opinion, stripping third-party signatures
entirely is a no-go.  I'd go ever as far as to say this key server is
harmful to OpenPGP users, and defeats the purpose of using OpenPGP.

I agree that WoT is nowhere near perfect, and that it is confusing to
a lot of simple users.  However, it's the best solution for validating
keys that we have right now.  With keys.openpgp.org implicitly stripping
third-party signatures on one hand, and explicitly requiring e-mail
verification on the other, it effectively shifts the security model into
trusting e-mail verification done by the server software.

I'm not saying that people running the server encourage that in any way.
I'm saying that it's going to happen to a larger degree than before
because users will be making the wrong assumptions.  In other words, if
users see that the particular key will be associated with the e-mail
address only once that address is verified, some of them will also
assume that if the e-mail address is present, then it is reliably
confirmed.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Tue, 2019-06-25 at 16:30 +0200, Vincent Breitmoser via Gnupg-users
wrote:
> > Hi @ll.
> 
> Hi Dirk,
> 
> thanks for your thoughts!
> 
> > I don't think it's such a good idea to drop Signatures on keys.
> 
> As mentioned in our FAQ, the reason we don't support those is that with the 
> SKS
> model, anyone can attach arbitrary data to others' keys.  It's hard to 
> overstate
> how problematic that is. I can just add a megabyte or fifty of data to your 
> key.
> 
> There are solutions that still allow for some of the TPS-based use cases, but
> until there is at least some agreement on how to proceed, we decided against
> supporting them.
> 
> Free distribution of arbitrary TPSes is quite simply not a viable model for 
> any
> keyserver. The discussion shouldn't be about liking or disliking them, it 
> should
> be about what alternatives could be.
> 
> I see from your signing policy that you do a caff-style workflow. Have you
> considered the option to have keys cross-sign third party signatures for
> publication? It's a very slight switch in tooling if we assume a caff 
> workflow,
> but that way each key remains in control of the public version of itself.
> 

I honestly neither like the idea of requiring the 'first party' to
explicitly confirm all signatures, nor losing compatibility with
existing software in order to implement that.  The latter should be
quite obvious so I'll focus on the former.

In Gentoo we're using a CA-like model with a central service signing
UIDs of all developers.  It is *convenient* for it to be able to inject
those signatures into keys of the developers, and distribute them along
with them.  If we required developers to explicitly import
the signature, certify it and upload the key I'm pretty sure our
coverage would go down because people simply won't care.  The problem is
that this bites not developers who don't care much but users who lose
the ability to verify the key easily.

As an alternative: since keys.openpgp.org makes keys without verified e-
mail addresses practically useless, why not permit only those signatures
that were made using a key that's on keys.o.o and has at least single
verified e-mail address?  If you combine that with accepting only one
signature per certifying key (i.e. pruning old signatures), it should be
'good enough'.  That is, as long as attackers won't decide to create
and verify humongous number of e-mail addresses.

This could work fine alongside 'first-party attested blah blah' model,
or at least work as an interim solution until the latter is widely
deployed.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[David]

On 02/07/2019 03:44, Mirimir via Gnupg-users wrote:
> On 07/01/2019 07:29 AM, David wrote:
> 
> 
> 
>> My take on all this is that I have had to disable Enigmail because it's
>> screwed - I was not able to send mail and all the settings in enigmail
>> were lots of  so I have been infected :(
>>
>> David
> 
> Damn. But all is likely not lost.
> 
> If you can open Enigmail Preferences, go to the Keyserver tab, and
> specify only keys.openpgp.org as the keyserver. That way, if you manage
> to fix gpg, Enigmail won't break it again. Also see "100% CPU usage
> endles loop of gpg --list-keys"  for
> background.
> 
> About hardening and fixing gpg, see
>  at
> Mitigations and Repairs. Also see
> .
> 
> You'll very likely need to use gpg in terminal. I suspect that GPA may
> be just as wedged as Enigmail.
> 
> Maybe someone could post a step-by-step guide for fixing gpg. For people
> who don't commonly use it in terminal. I suppose that I could import one
> of the poisoned keys in a fresh VM, and explore how to fix it. But I'm
> sure that someone reading this could just dash it out.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

My "fix" was simple - I already have a linux laptop - saved all my keys
and my secret key on a usb stick. Whilst reading the thread - I changed
all the key servers from sks - but then I got screwed as sks key servers
refreshed my keys! WTF!!! Having installed everything to the new laptop
I just copied the folder onto my or this working laptop and all is fine.
But as key servers share data - (???) maybe the infected keys will
circulate???

My public key has only one confirmed signing - it had two - but really I
am not that tempted to download from any key server. Not all here attach
their public key - and do not upload to a key server - and well no one
will ever upload to a key server again!!! Ha!

Every key server is at risk. It has been done once - and can be done
again - there is some very sophisticated malware out there. This is a
great shock and a wake up call to tighten security - on all key servers
- and to have a standardised platform - that takes money and developers.

I'm still in shock and very very wary!!!

David


-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com


0x5C6EE7FBAAD8C47D.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Wiktor Kwapisiewicz via Gnupg-users]

On 01.07.2019 14:36, Andrew Gallagher wrote:

OpenPGP already has the "keyserver" field which is rarely used. It is
supposedly a hint to clients to tell them to prefer a particular
keyserver, but it could also be used as a hint to the keyservers
themselves, to tell them where the master copy of any public key can be
sourced.


This sounds like a really good idea.

This way only one place would have to be updated by the user and 
keyservers would automatically refresh key data themselves.


I did suggest something like that but using WKD for Hagrid:

https://gitlab.com/hagrid-keyserver/hagrid/issues/55#note_181162712

but your suggestion Andrew is more generic (key can be put on any HTTP 
host anywhere).


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Mirimir via Gnupg-users]

On 07/01/2019 07:29 AM, David wrote:



> My take on all this is that I have had to disable Enigmail because it's
> screwed - I was not able to send mail and all the settings in enigmail
> were lots of  so I have been infected :(
> 
> David

Damn. But all is likely not lost.

If you can open Enigmail Preferences, go to the Keyserver tab, and
specify only keys.openpgp.org as the keyserver. That way, if you manage
to fix gpg, Enigmail won't break it again. Also see "100% CPU usage
endles loop of gpg --list-keys"  for
background.

About hardening and fixing gpg, see
 at
Mitigations and Repairs. Also see
.

You'll very likely need to use gpg in terminal. I suspect that GPA may
be just as wedged as Enigmail.

Maybe someone could post a step-by-step guide for fixing gpg. For people
who don't commonly use it in terminal. I suppose that I could import one
of the poisoned keys in a fresh VM, and explore how to fix it. But I'm
sure that someone reading this could just dash it out.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 2019/07/01 17:26, Werner Koch wrote:
> p.s.
> As stop-gap solution the next gpg release sports a
> --keyserver-options self-sigs-only to allow importing of spammed keys.

I think this deserves more than a P.S. ;-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 14:55, andr...@andrewg.com said:

> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.

Actually gpg has always set the /Key Server Preferences/ to 

   First octet: 0x80 = No-modify
   the key holder requests that this key only be modified or updated
   by the key holder or an administrator of the key server.

assuming that at some point in the near future we would come up with a
scheme to actually allow to implement such a verification.  The problem
here is that PGP-5 and thus OpenPGP continued to use the PGP-2 model and
didn't defined key-signature as, for example, embedded signatures or
something similar.  We had no other chance here because the WoT was
heavily used for real and for ranking games.

Given that all public keyservers (there used to be others) didn't
verified any signatures it was not possible to implement an upload
scheme which guaranteed that key-signatures had been confirmed by the
key holder.  It has already been mentioned that this would have gone
against the design of the keyserver network to be a perpetual storage
system.  I recall that we discussed all these issues at the keyserver
admins conference in Utrecht back in 2000 and planned to do something
about it.  However, PGP Inc. was soon sold and interest in doing
something with the decentralized keyservers network diminished.  The new
SKS thing then made keyservers working for OpenPGP (the original HKP was
severely limited in accepting OpenPGP keys) but we all knew that if we
ever get really successful with OpenPGP the keyserver would not be able
to solve the key distribution task.  In fact we are here too similar to
X.509 and their CRL and OCSP problems.

> Cross-signing would enforce this, but the client-side tooling is lacking.

Cross-signing is not an easy solution because it can create a catch-22:
You can only import a key which has been cross-signed but for
cross-signing it needs to be imported.

An approval of a key signature by a self-signature would be the right
way - but a straightforward scheme would break the existing WoT and,
worse for some, the ranking.

The other and more important question is whether the WoT and thus
classical key signatures solve a real world problem for the _masses_.  I
doubt that and I can live without public (exportable) key-signatures.
Local key signatures are still a good idea as an annotation of imported
keys.


Salam-Shalom,

   Werner



p.s.
As stop-gap solution the next gpg release sports a
--keyserver-options self-sigs-only to allow importing of spammed keys.

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


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[David]

On 01/07/2019 14:55, Andrew Gallagher wrote:
> On 2019/07/01 14:26, Robert J. Hansen wrote:
>> A thought that would unfortunately require an adjustment to the OpenPGP
>> spec itself: why do we put certification signatures on the target's
>> certificate, anyway?
> 
> I think it's mostly to do with key size. This works fine either way when
> it's among peers, but in large organisations you'll tend to get one key
> that certifies a large number of others, while the median number of
> certifications made by any of the other keys is zero. Better to
> distribute lots of keys each with one signature, than lots of keys with
> no signatures and one key with all the signatures.
> 
> Also, given that there tend to be a small number of super-certifiers, it
> is easier to trace back the possible verification paths given a list of
> certifiers on a newly-encountered key. The question is rarely "what is
> the list of the keys that I can verify?", and almost always "how can I
> verify this particular key?". X509 uses this model also, and for the
> same reason.
> 
>> The current debacle is completely the result of allowing *anyone* to
>> append a cert signature to *anyone else's* cert.
> 
> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.
> Cross-signing would enforce this, but the client-side tooling is lacking.
> 
>>> * It MUST cryptographically verify all fetched material.
>>
>> Note that this amounts to "SKS must die".  SKS does no cryptographic
>> verification of material.
> 
> SKS as we know it must die, but I think that has been obvious for a
> while. Its reconciliation algorithm can live on, however. The crypto
> verification doesn't need to be performed in the synchroniser. It might
> be best if it didn't so that we don't run into potential issues re some
> systems being able to verify, a new algorithm and some not. Better to
> let the synchroniser just do its job, and move all the verification and
> caching stuff to a higher level. It need not be in the same binary.
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

My take on all this is that I have had to disable Enigmail because it's
screwed - I was not able to send mail and all the settings in enigmail
were lots of  so I have been infected :(

David
-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 2019/07/01 14:26, Robert J. Hansen wrote:
> A thought that would unfortunately require an adjustment to the OpenPGP
> spec itself: why do we put certification signatures on the target's
> certificate, anyway?

I think it's mostly to do with key size. This works fine either way when
it's among peers, but in large organisations you'll tend to get one key
that certifies a large number of others, while the median number of
certifications made by any of the other keys is zero. Better to
distribute lots of keys each with one signature, than lots of keys with
no signatures and one key with all the signatures.

Also, given that there tend to be a small number of super-certifiers, it
is easier to trace back the possible verification paths given a list of
certifiers on a newly-encountered key. The question is rarely "what is
the list of the keys that I can verify?", and almost always "how can I
verify this particular key?". X509 uses this model also, and for the
same reason.

> The current debacle is completely the result of allowing *anyone* to
> append a cert signature to *anyone else's* cert.

Yes, which is why we've informally had "let the owner choose whether to
publish her incoming certifications" as best practice for a long time.
Cross-signing would enforce this, but the client-side tooling is lacking.

>> * It MUST cryptographically verify all fetched material.
> 
> Note that this amounts to "SKS must die".  SKS does no cryptographic
> verification of material.

SKS as we know it must die, but I think that has been obvious for a
while. Its reconciliation algorithm can live on, however. The crypto
verification doesn't need to be performed in the synchroniser. It might
be best if it didn't so that we don't run into potential issues re some
systems being able to verify, a new algorithm and some not. Better to
let the synchroniser just do its job, and move all the verification and
caching stuff to a higher level. It need not be in the same binary.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

> On 1 Jul 2019, at 13:36, Andrew Gallagher  wrote:
> 
> We start from hagrid or something like it, and carefully add the ability
> to sync only the absolute minimum of data required to allow revocations
> to propagate. This probably means primary keys, their self-sigs and
> revocation sigs.

Or alternatively, we start with either hockeypuck or SKS (yes, I know) and 
carefully cripple them. 

Thinking about this a bit more, and with the DNS comparison in mind, it may be 
best if caching keyservers and validating keyservers were two entirely 
different things, to make sure we don’t accidentally open ourselves to a cache 
poisoning attack. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Robert J. Hansen]

> We start from hagrid or something like it, and carefully add the ability
> to sync only the absolute minimum of data required to allow revocations
> to propagate. This probably means primary keys, their self-sigs and
> revocation sigs.

A thought that would unfortunately require an adjustment to the OpenPGP
spec itself: why do we put certification signatures on the target's
certificate, anyway?

If Alice 0xDEADBEEF certifies Bob 0xDECAFBAD, 0xDECAFBAD bears a
certification from 0xDEADBEEF.  Why not reverse it?  Why not, when
looking at a certificate 0xDEADBEEF that says "Hi, I'm Alice!", do we
not see "And I certify that 0xDECAFBAD is really Bob"?

In some respects it would permit us to preserve an append-only signature
model.  Only the certificate owner would be allowed to append a cert
signature to their cert.

The current debacle is completely the result of allowing *anyone* to
append a cert signature to *anyone else's* cert.

I am certain there's some subtle problem here I'm not seeing.  But it's
worth a thought.

> * It MUST cryptographically verify all fetched material.

Note that this amounts to "SKS must die".  SKS does no cryptographic
verification of material.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 2019/06/30 18:06, Daniel Kahn Gillmor wrote:
> On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote:
>> Indeed, c) was exactly the killer use case I had in mind.
> 
> so, how do we get there?

We start from hagrid or something like it, and carefully add the ability
to sync only the absolute minimum of data required to allow revocations
to propagate. This probably means primary keys, their self-sigs and
revocation sigs.

(*Maybe* subkeys also, but it's probably unnecessary since distributing
new key material is less urgent than revoking existing material.)

We could repurpose the existing SKS recon protocol, but introduce
breaking changes: a) the protocol is versioned so that implementations
can gracefully degrade, and b) only whitelisted packet types are synced.

>> On the other hand, b) is also quite useful in the short to medium
>> term, until all mail providers decide to support WKD etc.
> 
> WKD is mighty nice, but it is not necessary.  For example, if you don't
> care about first-contact, Autocrypt is a totally reasonable key
> discovery mechanism.

Sure, but WKD and Autocrypt still don't collectively cover all the edge
cases, so some residual need for a keyserver-like system remains.

>> And considering that some companies still don’t fully support PGP/MIME
>> after nearly twenty years of being the preferred standard (I’m looking
>> at you, Apple), “short to medium” effectively means “indefinitely”.
> 
> If you know something specific about Apple failing PGP/MIME in some
> capacity i hope you'll be more explicit about it, because i don't know
> what you're talking about.

iOS's native Mail app cannot be replaced, and all third-party mail apps
must use its API which is less than fully-featured. Constructing a
PGP/MIME message requires access to the MIME headers that the Mail app
does not expose. All PGP apps under iOS must either cut and paste inline
PGP or encapsulate messages as attachments that Mail treats as black
boxes. PGP on iOS is therefore klunky as hell, and it's not going to
improve unless Apple makes a conscious decision to support it.

> Anyone who claimed
> keyservers were authoritative in the past was either confused or
> misleading you.

I am under no illusion that the keyservers are authoritative, don't worry.

A comparison with DNS may be useful. DNS is a distributed cached
database, but there is a distinction between primary, secondary,
recursive etc. Recursive resolvers make the system resilient, but the
primary is consulted regularly and the cache constantly invalidated.

(In DNS of course, the master is also considered authoritative, but this
does not automatically follow in a cryptographically validating system)

The keyservers make no distinction between primary and secondary - all
keyservers are equal, the provenance of data is thrown away, and the
cache can therefore never be invalidated. But provenance matters, and if
synchronising keyservers can't be primaries, something else should be.
That can be WKD, DANE, or just a plain URL on a server that I control.
Keyservers would then be mainly limited to caching information that was
obtained from some master keystore (with the exception of material
strictly required for revocations).

OpenPGP already has the "keyserver" field which is rarely used. It is
supposedly a hint to clients to tell them to prefer a particular
keyserver, but it could also be used as a hint to the keyservers
themselves, to tell them where the master copy of any public key can be
sourced.

> If you want to propose changes to
> https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore
> i'd be happy to incorporate them too.

I'd suggest adding a "caching keystore", either after or as a subsection
of "updates-only keystore", with the following properties:

```
A caching keystore extends the concept of an updates-only keystore, by
supplying user IDs and third-party certifications on the condition that
they were recently available at an original location specified by the
key's owner. This mitigates key-flooding attacks by preventing arbitrary
submissions, and allows for the coordinated deletion of old or
problematic material by removing it from the original location.

* A caching keystore MUST accept submissions of primary keys as well as
cryptographically-valid self-certification and revocation sigs
(including third-party revocations) over those primary keys.

* It MAY synchronise the above key packets from other keystores. It MUST
NOT synchronise, or accept external submission of, any other packets.

* It SHOULD attempt to fetch and temporarily cache user IDs and incoming
third-party certifications over each primary key from the URL contained
in that primary key's "keyserver" field, if defined.

* If more than one "keyserver" definition is found for a given primary
key, then the most recent cryptographically-valid packet MUST take
precedence.

* It MUST cryptographically verify all fetched material.

* It MUST discard any unexpected 

Re: New keyserver at keys.openpgp.org - what's your take?

[Daniel Kahn Gillmor via Gnupg-users]

On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote:
> Indeed, c) was exactly the killer use case I had in mind.

so, how do we get there?

> On the other hand, b) is also quite useful in the short to medium
> term, until all mail providers decide to support WKD etc.

WKD is mighty nice, but it is not necessary.  For example, if you don't
care about first-contact, Autocrypt is a totally reasonable key
discovery mechanism.  It also has a significantly reduced metadata
footprint compared to WKD or DANE OPENPGPKEY, since all messaging is
in-band.

It has other problems, of course, but it can be used directly today (not
just "short to medium term").

> And considering that some companies still don’t fully support PGP/MIME
> after nearly twenty years of being the preferred standard (I’m looking
> at you, Apple), “short to medium” effectively means “indefinitely”.

If you know something specific about Apple failing PGP/MIME in some
capacity i hope you'll be more explicit about it, because i don't know
what you're talking about.

> So maybe we shouldn’t think of keyservers as storage repositories, but
> rather as search engines. The keyservers should not be authoritative,
> but they should be a best effort directory of where the authoritative
> locations are, combined with a cache of the non-identity cryptographic
> material in case the authoritative locations get DOSed.

Of course they're both search engines and storage rpositories, and they
are not and have never been authoritative.  Anyone who claimed
keyservers were authoritative in the past was either confused or
misleading you.

> If the authoritative location is not on a keyserver, then we do not
> need to sync arbitrary data between keyservers, just a list of
> location hints. The keyservers would then fetch from the authoritative
> locations and decide for themselves how much of the content to cache.

i'd be curious to read any specific guidance about how you think a
sensible keyserver would make those decisions.  If you want to propose
changes to
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore
i'd be happy to incorporate them too.

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

> On 21 Jun 2019, at 21:49, Daniel Kahn Gillmor  wrote:
> 
> So if we decide we only want to address use case (c), then it doesn't
> seem too crazy to imagine reconciliation among multiple installations of
> all the distributed, cryptographically-validated *non-identity* data
> that hagrid is designed to distribute.  And this should be
> fully-compatible with hagrid's implementation; each instance which can
> simply augment the reconciled data with the identity information that it
> has independently verified.

Indeed, c) was exactly the killer use case I had in mind.

On the other hand, b) is also quite useful in the short to medium term, until 
all mail providers decide to support WKD etc. And considering that some 
companies still don’t fully support PGP/MIME after nearly twenty years of being 
the preferred standard (I’m looking at you, Apple), “short to medium” 
effectively means “indefinitely”.

So maybe we shouldn’t think of keyservers as storage repositories, but rather 
as search engines. The keyservers should not be authoritative, but they should 
be a best effort directory of where the authoritative locations are, combined 
with a cache of the non-identity cryptographic material in case the 
authoritative locations get DOSed.

If the authoritative location is not on a keyserver, then we do not need to 
sync arbitrary data between keyservers, just a list of location hints. The 
keyservers would then fetch from the authoritative locations and decide for 
themselves how much of the content to cache.

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Michael Kesper]

Hi all,

On 27.06.19 03:18, Vincent Breitmoser via Gnupg-users wrote:
> The definition of personal data, Article 4:
> 
>> (1) ‘personal data’ means any information relating to an identified or
>> identifiable natural person (‘data subject’); an identifiable natural person
>> is one who can be identified, directly or indirectly, in particular by
>> reference to an identifier such as a name, (...), or an online identifier
>> (...);
> 
> Given that there is legal commentary that even IP addresses in logs already
> count as personal data, I don't find it contestable that e-mail addresses do
> constitute personal data.

Definitely.
If you can identify someone by data, it IS personal data.
As many email addresses are firstname.lastname@ they are already directly
identifiable.

See also: https://www.gdpreu.org/the-regulation/key-concepts/personal-data/

Best
Michael





signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk via Gnupg-users]

Hello Vicent.

I read your explainations and will shorten them up to the points I want
to reply to.

Am Donnerstag, den 27.06.2019, 03:18 +0200 schrieb Vincent Breitmoser
via Gnupg-users:

> > (2) ‘processing’ means any operation or set of operations which is
> > performed
> > on personal data or on sets of personal data, whether or not by
> > automated
> > means, such as collection, recording, organisation, structuring,
> > storage,
> > adaptation or alteration, retrieval, consultation, use, disclosure
> > by
> > transmission, dissemination or otherwise making available,
> > alignment or
> > combination, restriction, erasure or destruction;

> This is most certainly what we are doing.

> So assuming that e-mail addresses are personal data, and we process
> this data, there is an (exhaustive!) list of possible situations in
> which we are lawfully allowed to do so, two of which can potentially
> apply. Article 6:

> > 1. Processing shall be lawful only if and to the extent that at
> > least one of the following applies:

> > (a) the data subject has given consent to the processing of his or
> > her
> >personal data for one or more specific purposes;

> > (...)

> > (e) processing is necessary for the performance of a task carried
> > out in the public interest (...);

> The first is clear - if we have consent, we're good. The second
> *could* possibly be argued, but I have a hard time believing the
> haphazard handling of e-mail addresses on traditional keyservers
> serves the public interest. Even if we did assume this, there is the 

As one of the lawyers I work for told me, the consent could be
implicated by the users upload, therefor there must be the mechanism
that users can only upload their own keys, so consent is guaranteed.

> "right to object", which allows data subjects to object to the use of
> their data. Article 21:

> > 1. The data subject shall have the right to object, (...) to
> > processing of personal data concerning him or her which is based on
> > point (e) or (f) of Article 6(1), (...). The controller shall no
> > longer process the personal data unless the controller demonstrates
> > compelling legitimate grounds for the processing which override the
> > interests, rights and freedoms of the data subject (...).

> All in all, I find it pretty clear that GDPR does apply to processing
> of e-mail addresses on public keyservers. There are various nuanced
> conclusions one may draw, for example "it applies, but you probably
> won't get sued, so just keep on running them pool servers". It is
> unclear to me how one could look at this and conclude that keyservers
> aren't affected by GDPR.

The User knows how and why the data is processed, if he uploads his key
to the server. A deletion has to be possible by the regulation, SKS
lacks this mechanism. I haven't tested the new server yet, but I'm
planning to do this in the next day. As far as I read, deletion is
possible there.


> > and the, say, German implementation

> GDPR is a [regulation], not a [directive]. As such, it is an
> immediately enforcable law that does not require a per-country
> implementation to be effective.

Yes and no. The EU construct is a little bit strange in this manner,
but GDPR was transferred into german law by the renewal of the BDSG
last year.

> > along with relevant commentary to show why this is a legal
> > requirement.

> I'm aware of work on this by folks with legal background, but due to
> funny academic publishing culture I'm not at liberty to
> share. Hopefully something will be available to the public soon.

Oh yes, academic publishing culture is indeed a little strange. 

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac




signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser via Gnupg-users]

> Please cite the section from the GDPR

I assume you have looked into this already and are not asking this out of
uninformedness. But, I'll bite.

Article 2, "Material Scope":

> (1) This Regulation applies to the processing of personal data wholly or
> partly by automated means (...).

There are four exceptions to general applicability, none of which even possibly
apply to this scenario. We are obviously operating in the EU, so territorial
scope (Article 3) also applies. Let's look at the definitions of "processing"
and "personal data", then:

The definition of personal data, Article 4:

> (1) ‘personal data’ means any information relating to an identified or
> identifiable natural person (‘data subject’); an identifiable natural person
> is one who can be identified, directly or indirectly, in particular by
> reference to an identifier such as a name, (...), or an online identifier
> (...);

Given that there is legal commentary that even IP addresses in logs already
count as personal data, I don't find it contestable that e-mail addresses do
constitute personal data.

Here's what "processing" means, same article:

> (2) ‘processing’ means any operation or set of operations which is performed
> on personal data or on sets of personal data, whether or not by automated
> means, such as collection, recording, organisation, structuring, storage,
> adaptation or alteration, retrieval, consultation, use, disclosure by
> transmission, dissemination or otherwise making available, alignment or
> combination, restriction, erasure or destruction;

This is most certainly what we are doing.

So assuming that e-mail addresses are personal data, and we process this data,
there is an (exhaustive!) list of possible situations in which we are lawfully
allowed to do so, two of which can potentially apply. Article 6:

> 1. Processing shall be lawful only if and to the extent that at least one of
> the following applies:
>
> (a) the data subject has given consent to the processing of his or her
>personal data for one or more specific purposes;
>
> (...)
>
> (e) processing is necessary for the performance of a task carried out in the
> public interest (...);

The first is clear - if we have consent, we're good. The second *could* possibly
be argued, but I have a hard time believing the haphazard handling of e-mail
addresses on traditional keyservers serves the public interest. Even if we did
assume this, there is the "right to object", which allows data subjects to
object to the use of their data. Article 21:

> 1. The data subject shall have the right to object, (...) to processing of
> personal data concerning him or her which is based on point (e) or (f) of
> Article 6(1), (...). The controller shall no longer process the personal data
> unless the controller demonstrates compelling legitimate grounds for the
> processing which override the interests, rights and freedoms of the data
> subject (...).

All in all, I find it pretty clear that GDPR does apply to processing of e-mail
addresses on public keyservers. There are various nuanced conclusions one may
draw, for example "it applies, but you probably won't get sued, so just keep on
running them pool servers". It is unclear to me how one could look at this and
conclude that keyservers aren't affected by GDPR.

> and the, say, German implementation

GDPR is a [regulation], not a [directive]. As such, it is an immediately
enforcable law that does not require a per-country implementation to be
effective.

> along with relevant commentary to show why this is a legal requirement.

I'm aware of work on this by folks with legal background, but due to funny
academic publishing culture I'm not at liberty to share.  Hopefully something
will be available to the public soon.

 - V

[regulation]: https://en.wikipedia.org/wiki/Regulation_(European_Union)
[directive]: https://en.wikipedia.org/wiki/Directive_(European_Union)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas via Gnupg-users]

Stefan Claas via Gnupg-users wrote:

> Werner Koch via Gnupg-users wrote:
> 
> > On Tue, 25 Jun 2019 17:54, gnupg-users@gnupg.org said:
> > 
> > >> Theres simply one point: "If you do not want your email to be public,
> > >> don't upload your key to a server."
> > >
> > > What if I upload your key to a server though? Keep in mind this is not
> > > just a "nice to have", it is a legal requirement.
> > 
> > For whom, the holder of the mail address, the uploader, or the
> > responsible person for thge keyserver?
> > 
> > Please cite the section from the GDPR and the, say, German
> > implementation along with relevant commentary to show why this is a
> > legal requirement.
> 
> Maybe article 17 makes it clear that at least people have the right
> that their data has to been deleted, which is with the old model not
> possible.
> 
> https://gdpr-info.eu/art-17-gdpr/

And then we should take a closer look at section d):

the personal data have been unlawfully processed;

Maybe worth further discussions. If someone trollwot my pub key
and it has illegal content then it would be IMHO unlawful. Now
I think if I am not giving my consent to upload and process my
pub key it would be also unlawful, right?

Regards
Stefan







___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas via Gnupg-users]

Werner Koch via Gnupg-users wrote:

> On Tue, 25 Jun 2019 17:54, gnupg-users@gnupg.org said:
> 
> >> Theres simply one point: "If you do not want your email to be public, don't
> >> upload your key to a server."
> >
> > What if I upload your key to a server though? Keep in mind this is not just
> > a "nice to have", it is a legal requirement.
> 
> For whom, the holder of the mail address, the uploader, or the
> responsible person for thge keyserver?
> 
> Please cite the section from the GDPR and the, say, German
> implementation along with relevant commentary to show why this is a
> legal requirement.

Maybe article 17 makes it clear that at least people have the right
that their data has to been deleted, which is with the old model not
possible.

https://gdpr-info.eu/art-17-gdpr/

Regards
Stefan




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Tue, 25 Jun 2019 17:54, gnupg-users@gnupg.org said:

>> Theres simply one point: "If you do not want your email to be public, don't
>> upload your key to a server."
>
> What if I upload your key to a server though? Keep in mind this is not just
> a "nice to have", it is a legal requirement.

For whom, the holder of the mail address, the uploader, or the
responsible person for thge keyserver?

Please cite the section from the GDPR and the, say, German
implementation along with relevant commentary to show why this is a
legal requirement.


Shalom-Salam,

   Werner

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


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Daniel Kahn Gillmor via Gnupg-users]

On Tue 2019-06-25 17:41:12 +0200, Dirk Gottschalk via Gnupg-users wrote:
> Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser:
>> Have you considered the option to have keys cross-sign third party
>> signatures for publication? It's a very slight switch in tooling if
>> we assume a caff workflow, but that way each key remains in control
>> of the public version of itself.
>
> I didn't consider it until you mentioned ist. A good idea, thanks.

One concrete proposal for a mechanism for how to do this at the protocol
level is "First-party-attested Third-party Certifications", documented
here:


https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-10

To make this feasible requires some work on the client side.  The
protocol implementation is likely to be the easy part.  The hard part is
the UI/UX work to make this something that a normal human can understand
and do without too much pain.

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser via Gnupg-users]

> The Upload should be restricted to the key owner in some way.

We restrict upload of user ids to the owner of the user id, identified by email
verification. Non-identity data (subkeys, revocations, ...) can be freely
distributed, but only with a verified self-signature.

Is there any other mechanism you can come up with to allow upload by the owner
of some key data or email addresses, but not others?

> I didn't consider it until you mentioned ist. A good idea, thanks.

Great! I've been getting generally positive feedback about this idea, perhaps we
should look into that more seriously.

> Theres simply one point: "If you do not want your email to be public, don't
> upload your key to a server."

What if I upload your key to a server though? Keep in mind this is not just
a "nice to have", it is a legal requirement.

> In my opinion, the UID is essential for the Keys, except of M2M Usage.
> (...)
> No. But if I want to sent you an email and want to encrypt it on a
> machine with an empty keystore, shouldn't I be able to fetch your key
> by Address?

Of course! And we do support that, given consent from the owner of an address.
Without that, only non-identity data (still enough for M2M) is distributed.

> It could be realized by exact match

This is exactly what we do. :)

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk via Gnupg-users]

Hi.

Am Dienstag, den 25.06.2019, 17:54 +0200 schrieb Vincent Breitmoser:
> > The Upload should be restricted to the key owner in some way.

> We restrict upload of user ids to the owner of the user id,
> identified by email verification. Non-identity data (subkeys,
> revocations, ...) can be freely distributed, but only with a verified
> self-signature.

That's what I had in mind.

> Is there any other mechanism you can come up with to allow upload by
> the owner of some key data or email addresses, but not others?

Additionally some kind of authentication mechanism would be required to
avoid fake uploads like just a faked sender address. I implicated this
wordless. Other mechanisms could be possible but I don't have any
special thoughts regarding this at the moment.


> > I didn't consider it until you mentioned ist. A good idea, thanks.

> Great! I've been getting generally positive feedback about this idea,
> perhaps we should look into that more seriously.

Yes, I agree.


> > Theres simply one point: "If you do not want your email to be
> > public, don't upload your key to a server."

> What if I upload your key to a server though? Keep in mind this is
> not just a "nice to have", it is a legal requirement.

This would not be poissible with an authentication mechanism. See
above. Only the owner should be able to modify his key or make
ammendements. Probably except for revocations, in somne cases.

> > In my opinion, the UID is essential for the Keys, except of M2M
> > Usage.
> > (...)
> > No. But if I want to sent you an email and want to encrypt it on a
> > machine with an empty keystore, shouldn't I be able to fetch your
> > key
> > by Address?

> Of course! And we do support that, given consent from the owner of an
> address. Without that, only non-identity data (still enough for M2M)
> is distributed.

M2M keys don't need a UID at all. I made such keys für my automatic
backups and for some of the telematics solutions I work on. We use them
only to encrypt, sign and send tachograph data files which are sent to
our customers by email, for example.


> > It could be realized by exact match

> This is exactly what we do. :)

So you support key search, this is a good point. And it ind of changes
my opinion about the new servers. I didn't have the time to dig deeper
into this new server and my opinion is based upon the things I read on
the list. So this discussion is really helpful.

Just the point of a centralized server is a thing that is not good in
my opinion, but there should and will be a way to implement a
distributed system into this project. A synchronizatio´n mechanism has
to be well overthought, that's one point, but technically there are
some ways to implement a secure and stable mechanism to achieve
distribution. This is a point which should be considered.

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac




signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk via Gnupg-users]

Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser:
> > Hi @ll.

> Hi Dirk,

> thanks for your thoughts!

> > I don't think it's such a good idea to drop Signatures on keys.

> As mentioned in our FAQ, the reason we don't support those is that
> with the SKS model, anyone can attach arbitrary data to others'
> keys.  It's hard to overstate how problematic that is. I can just add
> a megabyte or fifty of data to your key.

The Upload should be restricted to the key owner in some way. That
would mitigate this Problem and it should help against a key mess up I
made a short while ago. 

> There are solutions that still allow for some of the TPS-based use
> cases, but until there is at least some agreement on how to proceed,
> we decided against supporting them.

TPS? Okay, it's warm and I don't get this. But yes, a minimal agreement
about the procedures would at least be neccessary.


> Free distribution of arbitrary TPSes is quite simply not a viable
> model for any keyserver. The discussion shouldn't be about liking or
> disliking them, it should be about what alternatives could be.

That's right. As told, SKS is far away from perfect and your solution
goes the right way. Nothing prevents the implementation of, let's say
key signatures in further versions or different versions to be used in
environments on an in house server.


> I see from your signing policy that you do a caff-style workflow.
> Have you considered the option to have keys cross-sign third party
> signatures for publication? It's a very slight switch in tooling if
> we assume a caff workflow, but that way each key remains in control
> of the public version of itself.

I didn't consider it until you mentioned ist. A good idea, thanks.


> > Also the centralized Approach is a no go in my opinion.

> The open federation model of SKS means all email addresses are
> enumeratable. That's a privacy no-go in my opinion, which people have
> gotten surprisingly used to in this community.

Isn't verifying the origination of an Email, including the address, one
of the PGP approaches? Theres simply one point: "If you do not want
your email to be public, don't upload your key to a server."

If I didn't want my address to be known by others, I shouldn't post to
an open ML. Same thing in my opinion.


> I can imagine a closed federation model, where we have a handful of
> operators but still don't need to have personal information of our
> users in the open.

In my opinion, the UID is essential for the Keys, except of M2M Usage.


> Maybe we'll move in that direction once the dust has settled a bit.
> The keyserver ecosystem has been stagnant in more than a decade, so..
> one step after another.

Yes, the key servers (SKS) have come of age and some things weren't "on
the radar screen" of it's developers for various reasons.


> > Even removing the ability to search for keys by UID is a thing I
> > don't like.

> Why not? Do you think "find all Dirks on the keyserver" is a valid
> use case that should be supported?

No. But if I want to sent you an email and want to encrypt it on a
machine with an empty keystore, shouldn't I be able to fetch your key
by Address? It could be realized by exact match of the email address
instead of spitting everything out that comes near to the requested
string.

Just my 2 cents and I am open to discuss benefits and downsides.

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac




signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser via Gnupg-users]

> Hi @ll.

Hi Dirk,

thanks for your thoughts!

> I don't think it's such a good idea to drop Signatures on keys.

As mentioned in our FAQ, the reason we don't support those is that with the SKS
model, anyone can attach arbitrary data to others' keys.  It's hard to overstate
how problematic that is. I can just add a megabyte or fifty of data to your key.

There are solutions that still allow for some of the TPS-based use cases, but
until there is at least some agreement on how to proceed, we decided against
supporting them.

Free distribution of arbitrary TPSes is quite simply not a viable model for any
keyserver. The discussion shouldn't be about liking or disliking them, it should
be about what alternatives could be.

I see from your signing policy that you do a caff-style workflow. Have you
considered the option to have keys cross-sign third party signatures for
publication? It's a very slight switch in tooling if we assume a caff workflow,
but that way each key remains in control of the public version of itself.

> Also the centralized Approach is a no go in my opinion.

The open federation model of SKS means all email addresses are enumeratable.
That's a privacy no-go in my opinion, which people have gotten surprisingly used
to in this community.

I can imagine a closed federation model, where we have a handful of operators
but still don't need to have personal information of our users in the open.

Maybe we'll move in that direction once the dust has settled a bit. The
keyserver ecosystem has been stagnant in more than a decade, so.. one step after
another.

> Even removing the ability to search for keys by UID is a thing I don't
> like.

Why not? Do you think "find all Dirks on the keyserver" is a valid use case that
should be supported?

Cheers

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Dirk Gottschalk via Gnupg-users]

Hi @ll.

Am Freitag, den 14.06.2019, 10:12 +0200 schrieb Oscar Carlsson via
Gnupg-users:
> Hi,

> I'm generally curious on your opinions on the latest new keyserver,
> this 
> time running a new software than the normal keyservers.

> They seem to have a different model which minimize the amount of 
> information available, to be compliant with GDPR and friends. Do you 
> think there are any downsides to this?

Unfortunately I promised to Werner to not get political anymore about
the EU and GDPR thingies.

To the Server you're Mentioning:

I don't think it's such a good idea to drop Signatures on keys.
Validating the KEys and it's packet would mitigate many of the SKS
issues. But some people and solutions rely on the signatures.

Okay, running an in house keyserver might be an option for this
situations.

Also the centralized Approach is a no go in my opinion.

Reading this thread, I feel like I've done a time travel, back to the
times where people distributed their keys over the usenet due to the
lack of keyserver dunctionality. Keyservers like the desribed one is
less than useless in my opinion.

Even removing the ability to search for keys by UID is a thing I don't
like. But that's the GDPR panic. Yes, I know, no politics from the
angry guy. ^^

So, it's pretty hot here. Werner must have turned on the Heater. I'll
be quite now. :D

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac




signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Daniel Kahn Gillmor via Gnupg-users]

On Fri 2019-06-21 15:26:17 +0100, Andrew Gallagher wrote:
> On 21/06/2019 14:32, Werner Koch via Gnupg-users wrote:
>> That new thing now is the n-th repetition of the same game: Replacing
>> PGP by a centralized approach, or well many centralized approaches, in
>> an attempt to repeat the story of S/MIME.  PGP has its strengths in the
>> idea of not having the one-and-only-distributor-of-all-keys and thus a
>> SPoFailure/Denial/Surveillance.  If we want that it is easier to go with
>> S/MIME.
>
> If hagrid supported an SKS-like reconciliation protocol, would that
> mitigate your concerns?

There might be an impedance mismatch here, depending on what you think
the goals are.

SKS has no validation policy by default, and SKS-style reconciliation
assumes that all peers have the exact same filtering policy.  So: what
exactly is the data that these servers would reconcile between each
other?  Since multiple validating keyservers haven't actually seen the
same validation steps, it's not clear how they'd decide what to filter
in terms of validated data.

it may help to think about the different sorts of things that people use
keyservers for.  we don't have to solve all different use cases at once.

I've written quite a bit more technical detail over here:
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03

But there are basically three main use cases for OpenPGP keyserver
clients (i'm setting aside the use case of people who want to publish
their certificates):

 a) validating a signature that comes from a certificate that the user
doesn't yet have access to.

 b) finding a certificate to associated with a peer the user wants to
communicate with (e.g. lookup by e-mail address).

 c) learning about the status of a certificate that the user already has
(expiration, revocation, new subkeys, etc)

There's a good argument to be made that use case (a) is simply a broken
workflow.  If i'm shipping you a signature, and i have no way of
ensuring that you already know my certificate, i can just ship my
certificate along with the signature.  If i don't do that, and you can't
verify the signature, it's not clear that any keyserver network *should*
be the thing to solve that problem.

Use case (b) is intimately tied to the address validation process, which
introduces the set reconciliation difficulty i allude to above.  (b) is
also well-suited to distributed discovery mechanisms, like DNS
OPENPGPKEY or WKD, at least for users of domains that are willing to
offer such a delegated publication mechanism.  so it might not be a
necessary component for a keyserver network long-term.

But the data required for use case (c) on its own is eminently
reconcilable, with relatively simple and clear filtering logic, and is
likely the most worrisome part for the SPoFailure/Denial/Surveillance
concerns that Werner rightly raises.

So if we decide we only want to address use case (c), then it doesn't
seem too crazy to imagine reconciliation among multiple installations of
all the distributed, cryptographically-validated *non-identity* data
that hagrid is designed to distribute.  And this should be
fully-compatible with hagrid's implementation; each instance which can
simply augment the reconciled data with the identity information that it
has independently verified.

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 21/06/2019 14:32, Werner Koch via Gnupg-users wrote:
> That new thing now is the n-th repetition of the same game: Replacing
> PGP by a centralized approach, or well many centralized approaches, in
> an attempt to repeat the story of S/MIME.  PGP has its strengths in the
> idea of not having the one-and-only-distributor-of-all-keys and thus a
> SPoFailure/Denial/Surveillance.  If we want that it is easier to go with
> S/MIME.

If hagrid supported an SKS-like reconciliation protocol, would that
mitigate your concerns?

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas via Gnupg-users]

Werner Koch via Gnupg-users wrote:

> That new thing now is the n-th repetition of the same game: Replacing
> PGP by a centralized approach, or well many centralized approaches, in
> an attempt to repeat the story of S/MIME.  PGP has its strengths in the
> idea of not having the one-and-only-distributor-of-all-keys and thus a
> SPoFailure/Denial/Surveillance.  If we want that it is easier to go with
> S/MIME.
> 
> An in-house keyserver is sometimes a good idea but a global validating
> keyserver is a failed idea.  Being under the AGPL may also be
> problematic because the code can't be used for in-house deployments and
> the AGPL often smells a little bit like a trigger for an Open Core
> business model.

I think it is a very good idea from Vincent and the Sequoia team to start
new things! The GnuPG and SKS ecosystem is not or was not capable to come
up with an adequate replacement for SKS.

Therefore kudos and big applause to Vincent and his team!

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Fri, 21 Jun 2019 12:03, gnupg-users@gnupg.org said:

> here is a article (only in german) from Heise:

By the very same guy who showed in the past that he has no clue about
keyservers and their goals and ignored all comments gathered about this
before writing an article [1].

That new thing now is the n-th repetition of the same game: Replacing
PGP by a centralized approach, or well many centralized approaches, in
an attempt to repeat the story of S/MIME.  PGP has its strengths in the
idea of not having the one-and-only-distributor-of-all-keys and thus a
SPoFailure/Denial/Surveillance.  If we want that it is easier to go with
S/MIME.

An in-house keyserver is sometimes a good idea but a global validating
keyserver is a failed idea.  Being under the AGPL may also be
problematic because the code can't be used for in-house deployments and
the AGPL often smells a little bit like a trigger for an Open Core
business model.


Salam-Shalom,

   Werner


[1] https://werner.eifzilla.de/20150224-re-die-schlssel-falle.html

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


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Julian H. Stacey]

> From: Juergen Bruckner via Gnupg-users 
> Hey all,
> here is a article (only in german) from Heise:
> 
> https://www.heise.de/security/meldung/Neuer-OpenPGP-Keyserver-liefert-end=
> lich-verifizierte-Schluessel-4450814.html

English:
https://translate.google.com/translate?sl=auto=en=https%3A%2F%2Fwww.heise.de%2Fsecurity%2Fmeldung%2FNeuer-OpenPGP-Keyserver-liefert-endlich-verifizierte-Schluessel-4450814.html

Translate engines I know of:  http://www.berklix.org/trans/
if others please mail me.

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 700,000 Brexit votes stolen from British in EU. 1.9 M UK young had no vote
 & 1.3 M died since.  Paid Lies.  Foreign funders fined.  http://stolenvotes.uk

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser via Gnupg-users]

Pretty happy with how this turned out so far. :)

Feedback I received was almost universally positive, other than the folks on
heise comments who really really really like the Web of Trust. In particular,
I heard of almost no isues with the verification flow, which hopefully means
things "just work" for everybody.

The heise article helped a lot getting the word out, we are closing in on 2k
verified email addresses:

https://keys.openpgp.org/about/stats/week.png

With the patch I recently submitted to gnupg-devel, `--refresh-keys` works very
smoothly for me. I wouldn't say it's blazingly fast, but my 320 keys take about
two minutes to refresh, and almost all of that time is spent in dirmngr. The
patch is already applied in Debian experimental, but hopefully we can get it
upstream soon as well. For those who want to give it a shot:

https://lists.gnupg.org/pipermail/gnupg-devel/2018-October/033969.html

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Juergen Bruckner via Gnupg-users]

Hey all,

here is a article (only in german) from Heise:

https://www.heise.de/security/meldung/Neuer-OpenPGP-Keyserver-liefert-endlich-verifizierte-Schluessel-4450814.html

regards
Juergen

Am 19.06.19 um 00:53 schrieb Earle Lowe via Gnupg-users:
> On Fri, Jun 14, 2019 at 7:35 AM Stefan Claas  wrote:
>>
>>
>> Fully agree. I proposed a couple of years ago to Phil Zimmermann's
>> Silent Circle*, in Switzerland, to run a modern key server in form
>> like we had with pgp.com. Never received a reply ...
>>
>> *IIRC out of business and Mr. Zimmermann now works afaik for
>> startpage.com, in the Netherlands, and is involved in Openspace.
>>
>> Regards
>> Stefan
> 
> Silent Circle is still in business (AFAIK) - but they don't make
> phones anymore, a software-only company now.
> 
> And keyserver.pgp.com is definately still around (the much-maligned
> Global Directory) - which interestingly enough does a number of things
> the new key server does, like email verification, enforcing one email
> one key, stripping off signatures, one can remove keys, and zero
> federation with other key servers.
> 
> -Earle
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juergen M. Bruckner
juer...@bruckner.tk



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Earle Lowe via Gnupg-users]

On Fri, Jun 14, 2019 at 7:35 AM Stefan Claas  wrote:
>
>
> Fully agree. I proposed a couple of years ago to Phil Zimmermann's
> Silent Circle*, in Switzerland, to run a modern key server in form
> like we had with pgp.com. Never received a reply ...
>
> *IIRC out of business and Mr. Zimmermann now works afaik for
> startpage.com, in the Netherlands, and is involved in Openspace.
>
> Regards
> Stefan

Silent Circle is still in business (AFAIK) - but they don't make
phones anymore, a software-only company now.

And keyserver.pgp.com is definately still around (the much-maligned
Global Directory) - which interestingly enough does a number of things
the new key server does, like email verification, enforcing one email
one key, stripping off signatures, one can remove keys, and zero
federation with other key servers.

-Earle

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Robin H. Johnson]

On Sun, Jun 16, 2019 at 04:10:34PM +0200, Stefan Claas wrote:
> Vincent Breitmoser wrote:
> 
> > 
> > > Maybe you can consider in the future at least to allow CA sigs.
> > > Those would be only one sig per key and the CA signing keys
> > > could be stored in your database as reference as well.
> > > 
> > > Currently 3 CAs come to mind: Governikus, Heise and CAcert.
> > 
> > Interesting thought!  I would be a bit worried about slipping into a
> > gatekeeper role, but at least there are no technical issues with this.
> 
> Thanks for your reply! I think this would be also appreciated
> by the CAs, in case they decide later to run your key server
> software as well, or for companies etc. whishing to having their
> own CA and using your key server software too.
Yes, from the perspective of Gentoo Linux, we've recently spun up
dedicated keyservers intended for @gentoo.org keys only. And being able
to include our own CA for approved signatures would fit well with future
plans.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas]

Vincent Breitmoser wrote:

> 
> > Maybe you can consider in the future at least to allow CA sigs.
> > Those would be only one sig per key and the CA signing keys
> > could be stored in your database as reference as well.
> > 
> > Currently 3 CAs come to mind: Governikus, Heise and CAcert.
> 
> Interesting thought!  I would be a bit worried about slipping into a
> gatekeeper role, but at least there are no technical issues with this.

Thanks for your reply! I think this would be also appreciated
by the CAs, in case they decide later to run your key server
software as well, or for companies etc. whishing to having their
own CA and using your key server software too.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

> On 15 Jun 2019, at 22:41, Vincent Breitmoser  wrote:
> 
> 
>> For a start, it only supports email userids - so it is incompatible with
>> monkeysphere.
> 
> Indeed! This is a use case that would be interesting to explore though, feel
> free to open an issue on our tracker if you want to help think it through!

I will when I get back to a desktop, thanks. My first thought would be to use 
domain verification, as in ACME. No point reinventing the wheel.

>> It's also a centralised resource, meaning it's not resilient enough for
>> distributing revocations, which is the main use case for SKS these days
> 
> Is "resilient" really a word you would use to describe SKS these days? Are you
> aware of issues like this?:

I’m well aware of the limitations of SKS. I spammed the SKS list last year re 
modifying the reconciliation algorithm to prevent transmission of problematic 
key packets (tl;dr: it’s harder than it looks). My main concern has always been 
how to reliably distribute revocations; this is a Very Hard problem that other 
PKIs have also struggled with, and the “optimum” solution is heavily dependent 
on your threat model. But even so, SKS worked really well up until relatively 
recently. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

> On 16 Jun 2019, at 12:51, Vincent Breitmoser  wrote:
> 
> 
>> Maybe you can consider in the future at least to allow CA sigs.
>> Those would be only one sig per key and the CA signing keys
>> could be stored in your database as reference as well.
>> 
>> Currently 3 CAs come to mind: Governikus, Heise and CAcert.
> 
> Interesting thought!  I would be a bit worried about slipping into a 
> gatekeeper
> role, but at least there are no technical issues with this.

I would recommend that if you want to go down the road of selectively allowing 
some third party sigs, that the only honest and transparent way is to allow the 
leaf certs to determine which sigs are allowed on themselves, via cross 
signing. If a CA wants to make this process cleaner for the end user, it can be 
done through tooling. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas]

Konstantin Ryabitsev wrote:

> On Fri, Jun 14, 2019 at 05:25:05PM +0300, Teemu Likonen wrote:
> >> The current shortcoming is stripping third-party signatures. So Web 
> >> of
> >> Trust wouldn't work (for good reasons described in the FAQ [0]). For
> >> some people this may be surprising.
> >
> >It may turn out to be a good choice to leave other people's certificates
> >(third-party signatures) out. It seems to solve the storage abuse
> >problem and probably doesn't harm too much communities who need web of
> >trust. Generally web of trust works only in tight communities who can
> >really verify each other's keys. Such communities can easily distribute
> >their keys through their web site or other common resources.
> 
> This is harder than it seems, so inability to use 3rd-party signatures 
> is kind of a deal-breaker. E.g. if you consider a community like Linux 
> kernel, where only very few developers have @kernel.org identities, it 
> would be handy to have a keyserver that did all of the following:
> 
> 1. implement the regular --send-key --recv-key api
> 2. when accepting a --send-key, check to make sure at least one of the 
> uid's matches an allow-list of identities (for example, from a dump of 
> all authors/committers in linux.git)
> 3. perform email verification using the matching identity from #2
> 4. store all key data without stripping out 3rd-party signatures
> 
> I guess it would be easy enough to hack that into hagrid, but that would 
> mean a hard fork and I'd avoid that at all costs.

Maybe you can consider in the future at least to allow CA sigs.
Those would be only one sig per key and the CA signing keys
could be stored in your database as reference as well.

Currently 3 CAs come to mind: Governikus, Heise and CAcert.

Maybe other CAs will show up in the future if you model
would support it and then we don't have to deal with the
classical WoT anymore.

Well, only a suggestion!

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser]

> For a start, it only supports email userids - so it is incompatible with
> monkeysphere.

Indeed! This is a use case that would be interesting to explore though, feel
free to open an issue on our tracker if you want to help think it through!

> It's also a centralised resource, meaning it's not resilient enough for
> distributing revocations, which is the main use case for SKS these days

Is "resilient" really a word you would use to describe SKS these days? Are you
aware of issues like this?:

https://bitbucket.org/skskeyserver/sks-keyserver/issues/57/anyone-can-make-any-pgp-key-unimportable

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser]

Hi Konstantin,

> This is harder than it seems, so inability to use 3rd-party signatures is kind
> of a deal-breaker.

Sure is. There are ways to solve this problem, but at the moment they are all at
an early conceptual state at best.

For example, we could allow third-party signatures if they are cross-signed by
the signee (in an unhashed subpacket, for example).  Assuming a caff-style
workflow, this would be a fairly minor change to user workflows, and solve the
abuse issue because the owner of each key remains in charge of any signatures
published for it.

Wiktor also suggested before to accept key material from signed upload requests
(roughly "gpg --export keyid | gpg --sign-as keyid | curl). But I'm unsure of
how well this can really work in practice, given how hard it is to keep one's
local keyring in any kind of clean state.

Of course, closed user groups with different trust models and abuse
circumstances can solve this much more easily.

> I guess it would be easy enough to hack that into hagrid, but that would mean
> a hard fork and I'd avoid that at all costs.

Maintaining hagrid for the keys.openpgp.org use case takes up all the free time
I can spend on this project - which is why it is currently built to do exactly
that, no more no less.

I would be open to contributions that allowed the use of hagrid in other
scenarios such as this. More eyes on the code base sure wouldn't hurt. (I would
also probably be available for commissions, if you're into that :)

Note that, for better or worse, hagrid uses a filesystem-based database.  We
maintain all keys in the filesystem, and route most requests directly from
nginx, and the rest via x-accel-redirect.  This is not something everybody is
comfortable with, so beware ;)

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Wiktor Kwapisiewicz via Gnupg-users]

Hi Konstantin,

On Fri Jun 14, 2019 at 11:19 AM Konstantin Ryabitsev wrote:
> 1. implement the regular --send-key --recv-key api

This is already implemented.

> 2. when accepting a --send-key, check to make sure at least one of the 
> uid's matches an allow-list of identities (for example, from a dump of 
> all authors/committers in linux.git)

I guess this could be implemented as a white-list of e-mails.

I hope you don't mind but I've mentioned this use-case on their issue
tracker:

https://gitlab.com/hagrid-keyserver/hagrid/issues/55#note_181698023

> 3. perform email verification using the matching identity from #2

If filtering would be implemented this would also work as is.

> 4. store all key data without stripping out 3rd-party signatures

As far as I understood the Hagrid keyserver developers they're not
against 3rd-party signatures per se, just don't like the idea of anyone
appending data to keys. The answer on the FAQ seems quite open:

https://keys.openpgp.org/about/faq#third-party-signatures

> I guess it would be easy enough to hack that into hagrid, but that would 
> mean a hard fork and I'd avoid that at all costs.

I think it would be useful to bring it to Hagrid developers (either on
the issue tracker, via e-mail or #hagrid on IRC). From my experience
they're listening to feedback :)

Have a nice evening!

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Konstantin Ryabitsev]

On Fri, Jun 14, 2019 at 05:25:05PM +0300, Teemu Likonen wrote:
The current shortcoming is stripping third-party signatures. So Web 
of

Trust wouldn't work (for good reasons described in the FAQ [0]). For
some people this may be surprising.


It may turn out to be a good choice to leave other people's certificates
(third-party signatures) out. It seems to solve the storage abuse
problem and probably doesn't harm too much communities who need web of
trust. Generally web of trust works only in tight communities who can
really verify each other's keys. Such communities can easily distribute
their keys through their web site or other common resources.


This is harder than it seems, so inability to use 3rd-party signatures 
is kind of a deal-breaker. E.g. if you consider a community like Linux 
kernel, where only very few developers have @kernel.org identities, it 
would be handy to have a keyserver that did all of the following:


1. implement the regular --send-key --recv-key api
2. when accepting a --send-key, check to make sure at least one of the 
uid's matches an allow-list of identities (for example, from a dump of 
all authors/committers in linux.git)

3. perform email verification using the matching identity from #2
4. store all key data without stripping out 3rd-party signatures

I guess it would be easy enough to hack that into hagrid, but that would 
mean a hard fork and I'd avoid that at all costs.


-K

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas]

Michał Górny wrote:

> Given that SKS pool is entirely open, it is rather trivial for a single
> malicious entity to set multiple new keyservers up, and gain advantage
> over other servers in the pool.  In fact, this is probably easier than
> corrupting the single central server.

Fully agree. I proposed a couple of years ago to Phil Zimmermann's
Silent Circle*, in Switzerland, to run a modern key server in form
like we had with pgp.com. Never received a reply ...

*IIRC out of business and Mr. Zimmermann now works afaik for
startpage.com, in the Netherlands, and is involved in Openspace.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Teemu Likonen]

Wiktor Kwapisiewicz [2019-06-14 11:59:16+02] wrote:

> Storing endless amounts of data without any kind of verification was a
> bad idea. Maybe SKS was designed in good old times when no-one would
> try to take advantage of it but in 2019 validating e-mail address is
> bare minimum a service such as this should do.
>
> The current shortcoming is stripping third-party signatures. So Web of
> Trust wouldn't work (for good reasons described in the FAQ [0]). For
> some people this may be surprising.

It may turn out to be a good choice to leave other people's certificates
(third-party signatures) out. It seems to solve the storage abuse
problem and probably doesn't harm too much communities who need web of
trust. Generally web of trust works only in tight communities who can
really verify each other's keys. Such communities can easily distribute
their keys through their web site or other common resources. For larger
audience it's probably enough to have an easy and automatic key
discovery and key update service, such as this keys.openpgp.org seems to
be. I think.

-- 
/// Teemu Likonen    //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny]

On Fri, 2019-06-14 at 11:56 +0100, Damien Goutte-Gattat via Gnupg-users
wrote:
> Hi,
> 
> On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users 
> wrote:
> > I'm generally curious on your opinions on the latest new keyserver, 
> > this time running a new software than the normal keyservers.
> 
> For what it's worth, my main concern is that it is a centralized 
> service.
> 
> This puts whoever is running keys.openpgp.org in a uniquely good 
> position to do Bad Things™. Of course I don't expect they would, but the 
> point is, they could (or they could be forced to).

To be honest, I've been considering similar problems with SKS lately
and I don't really think a distributed service such as SKS is any better
in this regard.

Given that SKS pool is entirely open, it is rather trivial for a single
malicious entity to set multiple new keyservers up, and gain advantage
over other servers in the pool.  In fact, this is probably easier than
corrupting the single central server.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas]

Damien Goutte-Gattat via Gnupg-users wrote:

> Hi,
> 
> On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users
> wrote:
> >I'm generally curious on your opinions on the latest new keyserver, 
> >this time running a new software than the normal keyservers.
> 
> For what it's worth, my main concern is that it is a centralized 
> service.
> 
> This puts whoever is running keys.openpgp.org in a uniquely good 
> position to do Bad Things™. Of course I don't expect they would, but the 
> point is, they could (or they could be forced to).

Interesting to read young peoples thoughts. Can you give a good reason why
key servers should be a decentralized distributing medium? For Warez etc,
like p2p Networks I can understand this. 

Why not let key servers be run, like this new one, on behalf of Government
Institutions, or commercial Services etc. like S/MIME ldap Servers?

Would a dissident or other people really benefit from the old style key
server medium? I mean when third parties have them on their radar it
would not help them much, right?

The only benefit I see is that 3rd parties, not known to us, can do
"research" with a key dump, without letting us know. With a centralized
approach and run on behalf by proper authorities this would be not
possible, and if, they can do this anyways with what we have now.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users wrote:
I'm generally curious on your opinions on the latest new keyserver, 
this time running a new software than the normal keyservers.


For what it's worth, my main concern is that it is a centralized 
service.


This puts whoever is running keys.openpgp.org in a uniquely good 
position to do Bad Things™. Of course I don't expect they would, but the 
point is, they could (or they could be forced to).


That being said, I have nothing better to propose and overall I welcome 
any attempt, however imperfect, to make OpenPGP slightly easier and/or 
more comfortable to use. (And I do note that Hagrid developers "plan to 
explore options for a distributed service in the future" [1].)


Regards,

- Damien

[1] https://keys.openpgp.org/about/faq


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 14/06/2019 09:31, Teemu Likonen wrote:
> Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote:
> 
>> I'm generally curious on your opinions on the latest new keyserver,
>> this time running a new software than the normal keyservers.
>>
>> They seem to have a different model which minimize the amount of
>> information available, to be compliant with GDPR and friends. Do you
>> think there are any downsides to this?
> 
> You should have added a link to information about this "latest new
> keyserver" and its "different model" which you are referring to. Well,
> here:
> 
> https://keys.openpgp.org/about/news#2019-06-12-launch

I think it's interesting, but it has a few shortcomings. For a start, it
only supports email userids - so it is incompatible with monkeysphere.
It's also a centralised resource, meaning it's not resilient enough for
distributing revocations, which is the main use case for SKS these days
(there are already several alternative systems for discovery).

So it's not an SKS-killer (yet).

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Wiktor Kwapisiewicz via Gnupg-users]

Hi Oscar,

On 14.06.2019 10:12, Oscar Carlsson via Gnupg-users wrote:
I'm generally curious on your opinions on the latest new keyserver, this 
time running a new software than the normal keyservers.


It's definitely faster and more responsive. That was my personal pain 
point when interacting with SKS. For example I'm working on a small 
thing that fetches keys from keyservers. I push my modified key, fetch 
it from SKS and... nope, no changes are visible (because of nginx 
caching). Then a different, old set of data is visible. Then timeout. 
Etc. keys.openpgp.org just works. I push data and it's available.


They seem to have a different model which minimize the amount of 
information available, to be compliant with GDPR and friends. Do you 
think there are any downsides to this?


Storing endless amounts of data without any kind of verification was a 
bad idea. Maybe SKS was designed in good old times when no-one would try 
to take advantage of it but in 2019 validating e-mail address is bare 
minimum a service such as this should do.


The current shortcoming is stripping third-party signatures. So Web of 
Trust wouldn't work (for good reasons described in the FAQ [0]). For 
some people this may be surprising.


[0]: https://keys.openpgp.org/about/faq#third-party-signatures

For the record I don't think keys.openpgp.org is in any way 
revolutionary as it is now. It's a bare minimum keyserver that OpenPGP 
needed for a long time. Fortunately the team behind it has more ideas 
that could only improve the overall image and UX of OpenPGP in the wider 
community.


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Teemu Likonen]

Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote:

> I'm generally curious on your opinions on the latest new keyserver,
> this time running a new software than the normal keyservers.
>
> They seem to have a different model which minimize the amount of
> information available, to be compliant with GDPR and friends. Do you
> think there are any downsides to this?

You should have added a link to information about this "latest new
keyserver" and its "different model" which you are referring to. Well,
here:

https://keys.openpgp.org/about/news#2019-06-12-launch

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Oscar Carlsson via Gnupg-users]

2019-06-14 10:31 skrev Teemu Likonen:

Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote:


I'm generally curious on your opinions on the latest new keyserver,
this time running a new software than the normal keyservers.

They seem to have a different model which minimize the amount of
information available, to be compliant with GDPR and friends. Do you
think there are any downsides to this?


You should have added a link to information about this "latest new
keyserver" and its "different model" which you are referring to. Well,
here:

https://keys.openpgp.org/about/news#2019-06-12-launch


Ah, sorry about that! And thanks for adding it for me.

I had added it to the title and didn't think of adding it to the body as 
well.



Oscar

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

New keyserver at keys.openpgp.org - what's your take?

[Oscar Carlsson via Gnupg-users]

Hi,

I'm generally curious on your opinions on the latest new keyserver, this 
time running a new software than the normal keyservers.


They seem to have a different model which minimize the amount of 
information available, to be compliant with GDPR and friends. Do you 
think there are any downsides to this?



Regards,
Oscar

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users