> If the keyserver implemented a signer blacklist, (which would scrub the
> blacklisted signature from any current or incoming public keys), what
> consequences am I missing?
Someone already chimed in about how this is "enumerating badness", which
runs counter to best practices in security.
Addit
> On 14 Aug 2019, at 23:38, Daniel Clery wrote:
>
> If the keyserver implemented a signer blacklist, (which would scrub the
> blacklisted signature from any current or incoming public keys), what
> consequences am I missing?
This is known as “enumerating badness” and it doesn’t scale. You wou
> On Aug 14, 2019, at 6:32 PM, MFPA via Gnupg-users
> wrote:
> On Wednesday 14 August 2019 at 10:39:56 AM, in
> , Alessandro Vesely
> via Gnupg-users wrote:-
>
>> I'm no expert, but it seems to me that 3rd party
>> signatures should not
>> be allowed.
>
> Perhaps a "keyserver no-third-party-s
On 14/08/2019 16:30, charlie derr wrote:
> I'm running debian 10 buster (upgraded recently from stretch if that
> matters) and i use KDE. I haven't yet tried to logout of my desktop
> environment completely (and just use a native console), but I thought
> I would see if any of you had any ideas. He
If the keyserver implemented a signer blacklist, (which would scrub the
blacklisted signature from any current or incoming public keys), what
consequences am I missing?
In essence, shadowbanning a signing key. Keyservers without blacklist
support would still pass around the toxic keys, but only un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 14 August 2019 at 10:39:56 AM, in
, Alessandro Vesely
via Gnupg-users wrote:-
> I'm no expert, but it seems to me that 3rd party
> signatures should not
> be allowed.
Perhaps a "keyserver no-third-party-signatures" option would re
On Wed, 14 Aug 2019 15:45, r...@sixdemonbag.org said:
> developed *more than twenty years ago* it was decided to support
> arbitrary numbers of third-party signatures. GnuPG faithfully
At least OpenPGP has this:
5.2.3.17. Key Server Preferences
(N octets of flags)
This is a list of o
> I've often wondered why the sks software didn't require
> cross-certification. It seems like that would solve the key poisoning
> issue.
Not enough OCaml programmers, mostly.
Strange but true: SKS has no crypto code in it anywhere. So the moment
you say "I wonder why SKS doesn't do this thing
> Can you give me a valid reason why anyone would want their key signed by
> 150,000 people or more?? How can you meet 150,000 people?
Sure, if you can give me a valid reason why I *should* give you a valid
reason.
Seriously.
I'm not a GnuPG developer. I don't run an SKS keyserver. I know a go
On 14-08-2019 11:38, Alessandro Vesely via Gnupg-users wrote:
> Of course, anonymous key poisoning is a kind of gratuitous vandalism.
> Yet, crypto is supposed to work in a hostile environment.
But this is only an extreme form of what an old keyserver already did:
it issued (I believe every 6 mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've often wondered why the sks software didn't require
cross-certification. It seems like that would solve the key poisoning
issue. It would mean that when signing someone's key, you'd have to
have a way to exchange the signatures first, before su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm running debian 10 buster (upgraded recently from stretch if that
matters) and i use KDE. I haven't yet tried to logout of my desktop
environment completely (and just use a native console), but I thought
I would see if any of you had any ideas. He
On 14/08/2019 12:29, Vincent Breitmoser wrote:
>> The algorithm is designed to withstand very well funded actors,
>> oppressive regimes were what the designers were thinking of.
>
> We are talking about a sand castle here that was kicked down by a kid. It's
> a bit bizarre to claim that it was bui
On 14/08/2019 12:09, Andrew Gallagher wrote:
> Indeed, but that condition is fundamentally incompatible with
> decentralised reconciliation - because deletion without permissions
> management is an open door, and permissions have to be enforced by an
> authority.
H the authority could just
On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong. It must be possible to delete errors.
In that case we need a different algorithm.
Which I had already been advocating, so you are preaching to the choir.
You can keep reiterating that you do not like
Hello David,
> Can you give me a valid reason why anyone would want their key signed by
> 150,000 people or more??
I don't see anybody claiming that this is a valid use case.
There are several issues preventing actually limiting this in the
current keyserver network, but this has already been ex
On 13/08/2019 15:54, Robert J. Hansen wrote:
>> Good write-up. Now I have a question, in hope that SKS operators are
>> reading this too. I have learned from Robert's gist that the max. is
>> 150.000 sigs per key the servers can handle, if I am not mistaken.
>
> I didn't say this.
>
> I said they
> The algorithm is designed to withstand very well funded actors,
> oppressive regimes were what the designers were thinking of.
We are talking about a sand castle here that was kicked down by a kid. It's
a bit bizarre to claim that it was built to withstand rockets.
Given that the recon algori
On 14/08/2019 10:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong. It must be possible to delete errors.
Indeed, but that condition is fundamentally incompatible with
decentralised reconciliation - because deletion without permissions
management is an open door, and p
On Tue 13/Aug/2019 13:07:07 +0200 Peter Lebbing wrote:
> On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote:
>> More than a reasonable number of signatures makes no sense in
>> practice, so I agree lists should somehow be "fixed" so as not to
>> accept an unreasonable number of signatures
On Tue 13/Aug/2019 12:08:31 +0200 Werner Koch Via Gnupg-users wrote:
> On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said:
>
>> The bug, however, is in the program that chokes on poisoned keys!
>
> Nope. This is a long standing DoS protection by limiting the total
> length of a keyblock. The
21 matches
Mail list logo
