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
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:
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'
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?
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
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:
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
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
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
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
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
>
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
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
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
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
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
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
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
> 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
> 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
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
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
> 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
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
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
> 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
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
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
>
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.
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
> 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
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
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
> 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
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
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
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
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
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
> 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:
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
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
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
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.
> >
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.
>
>
> 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
> 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:
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.
> >
>
> 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
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
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
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
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
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
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
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
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.
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
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
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
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
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
62 matches
Mail list logo
