> IANAL, but only one person in this discussion has mentioned that they
> HAVE consulted one that specializes in data privacy - who confirms that
> specifically, for a US keyserver operator operating a US keyserver, GDPR
> has *absolutely no bearing* even if we *weren't* exempt.
Minor nit: that
> Hansen its 2019 not 1990 and you need to evolve your thinking beyond your own
> personal interests!
Yawn. Call me when you've given up on the ad hominem.
> Do you think the GDPR is a bad thing?
I think it's a law enacted by a nation I'm not party to and am not
obligated to obey. That means
Mostly this is a response to Arnold, as for some reason his email never
showed up in my inbox:
> I thought SKS and PGP-keys is about one's ability to hide private
> data (by encryption).
Tools do not have intrinsic purposes. There's the stuff they're
designed for and there's the stuff they
> Well, it was just one of many example sites...
Again: I'm going to go with the real advice given to me by real lawyers.
> So as an example, US SKS key server operators do not have to honor
> removal request (in this case shut-down the server) from EU citizens,
> when they receive a letter from
> Please have a read:
Did.
I'm going to believe the privacy lawyer I pay $450 an hour to more than
I'm going to trust a sketchy website that's not even officially
affiliated with the EU. Quoting from it:
"You may be wondering how the European Union will enforce a law in
territory it does not
> Fair enough. Then you're ignoring the consequences (or rather believe
> that none exist) rather than saying that the GDPR wouldn't apply to US-
> based operators.
Enforcement is the sine qua non of law. GDPR does not apply to purely
US-based operators because there is no way for the EU to
>> There are (or at least were) a large number of US-based keyserver
>> operators who were immune to the GDPR.
>
> I fail to see how this is in accordance with the GDPR.
The EU is free to claim whatever authority it wants, but until it can
enforce that authority it's bluster. If I, as a US
> They are!
No, they're not.
GDPR only applies to business entities that trade with EU citizens in EU
member nations. If a German boards a flight in Colorado to travel to
Texas, they don't get to claim GDPR protections on their tickets. It's
once the flight connects to an EU member state the
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
As the guy who wrote that, yeah, I'm pretty sure we here are aware of
it. ;)
Kristian, who is the major figure behind the SKS keyserver network, has
also apparently been targeted. We are keenly aware of the issue. But
thank
> It is no use to wait a great consensus.
Without exception, I have never met someone who was reluctant to
volunteer someone else's time. I think this is unfortunate. I'd rather
we were as reluctant to urge other people to commit their time and
effort to a project as we are to commit our own.
> I disagree that we have to do a trade off, mostly for technical
> reasons.
Let's call forbidden information 'kryptonite'. Kryptonite is bad stuff.
We don't want it on moral grounds or legal grounds. We would rather
shut down keyservers than have kryptonite on our systems. We then have
three
To spare us all diving through list archives:
The keyserver network is in a lot of ways like a blockchain. In both
cases they are distributed ledgers where any change to the ledger is
propagated through to everyone with a copy of the ledger. (Blockchain
differs by adding more cryptographic
> Is it possible to develop a keyserver thar uses the same interface as
> the current one?
Sort of.
> Meaning that GnuPG-Clients don't need to change
Yes.
> and current keyservers can recon with the new keyservers (since they
> are not all upgraded simultaniously)?
No. Keyserver
> Kristian says in his interview the network was not designed to be resilient?
Kinda-sorta. The basic keyserver architecture was designed in the very
early 1990s, and it's really quite resilient against the sorts of
threats we saw in the 1990s.
But the threat actors and their capabilities have
> Then let's drop keys that don't contain a valid email address in the key id.
How do you propose to validate the email address?
(Hint: this is a surprisingly hard problem.)
___
Sks-devel mailing list
Sks-devel@nongnu.org
> I think the time has come where we have to re-evaluate what the
> keyservers are *for*. Once we answer that, we answer what should be
> done about it.
I agree, although I think maybe you're not taking it far enough.
What threats should we be defending against?
The original idea of a keyserver
> In the new era key owners have to proof their identity. Practically
> speaking key servers accept only keys belonging to the strong set.
> (At least in first step.)
Who says the next technology needs to be key servers? That seems like
an assumption worth challenging.
I'm not throwing this out
> Does a user revolt even matter as the SKS pool is dismantled by
> continuous attacks?
"We had to burn the village in order to save it!", I see.
There are three questions:
1. Can SKS be saved?
2. If so, how?
3. If not, what next?
I believe the answers are "no", "N/A", and "I don't know
> IMHO Photo-ID should be dropped entirely, I see no point and its just
> ripe for abuse like this..
Unfortunately, we really can't. They've been part of OpenPGP
certificates for just about twenty years now. They are an expected part
of the certificate. Users already scream bloody murder about
> Sad but not surprised. Thanks for all your time and effort. It has been much
> appreciated.
Yes.
> I am reluctant to declare defeat, but this calls for a tactical retreat and
> regroup.
Yes.
There's a certain dark lesson to be learned here. The keyserver network
was designed in the
> how can you assume that it was me who uploaded a key with my name on it?
Nobody is. But if you create a public key, then by definition you're
comfortable with it being shared with the public.
If you don't want your public key shared with the public, don't use
asymmetric crypto.
If you didn't
> Please feel free to find the weaknesses in this suggestion !!!
Fine. Remember: you asked for it.
> Suppose we add a POW data to the PGP key data transaction request
>
> We can use the number of 0 in the 160-bit SHA-1 hash as the level of
> complexity indicator.
In *which* SHA-1 hash?
> The
> The administrators of the SKS servers should be able to choose the level
> of complexity of the proof of work using a parameter in the SKS server
> configuration file.
No, they shouldn't. Think about it. If you're an attacker looking to
bypass this mechanism, what do you do? You find the
> Let client solve a simple integer factorization of a random number given
> by server with e.g. 64bit build from two prime numbers.
Please sanity-check your ideas first.
Trial division on a 64-bit number requires trying each prime up to
2**32. There are about 200 million of them. 200 million
> But they kind of do already, so I don't see the point here.
They don't. Let's say a keyserver operator goes rogue and decides to
drop 0xB44427C7 (my cert) from the keyserver network. Great, ten
minutes later it gets replaced during the next sync. So the keyserver
operator deletes it again.
>> 1. What criteria should be met before a key is removed?
>
> Owner of private key or owner of UID/email address requests it.
So far, so good.
>> 2. Who decides that the criteria have been met?
>
> The keyserver operator the request is sent to.
Going off the rails.
>> 3. How are malicious
> I'm not sure whether burn care would be really an issues for (most of)
> us... at least not as long cryptography itself isn't made "illegal".
> Our services are typically not illegal or morally questionable...so
> even if "they" would come after you... well... so what?
The "so what?" is, if
> One thing that does concern me about the current arrangements is how
> manual (and ad-hoc) the peering system is. I can foresee scalability
> problems...
Two thoughts:
1. "Speed it, O Lord! Let Thy Kingdom come!" With 50,000 certificates
in the strong set and only a few million certificates
Thoughts?
Right now the principal SKS developers and maintainers are Yaron Minsky,
John Clizbe, Christoph Martin, Fabi Di Nitto, Daniel Kahn Gillmor, and
... I'm blanking on the Fedora SKS maintainer.
This idea really needs buy-in from them. So long as it's an idea
floated by people who
Even if we did have a better understanding of the filter code, the
difficulty with phasing in filters like this (as you've noticed in
your description) is that either the whole pool opts in, or the
filter doesn't work. Peers with different filtersets cannot gossip
with each other, aiui.
Your tactic adds much, much more significant legal risk since you
could be arrested for sexual offenses (very long prison sentence plus
lifelong branding). Most troll organizations don't cross this line,
and take more technical approaches to DoS'ing a system.
You're thinking like an
Uploading user attribute packets with bogus self-signatures is
probably the easiest way to DoS the entire keyserver network.
No. No, it's not.
The easiest way is to add a single child porn image to a UID and upload
it to the keyserver, and watch as worldwide every keyserver operator
either
This is a DOS because Mallory could effectively increase Alice's
public key to a size that it would be untenable for Bob to
download it from the pool.
There are so many other, better ways to DoS the entire keyserver network
that I have real trouble taking this one seriously.
I think Kristian
On 8/3/2014 3:06 AM, Kiss Gabor (Bitman) wrote:
I'm thinking on structure of graph of key servers for a long time.
IMHO it is too scale free and not designed knowingly enough.
If you haven't read this paper, start with it.
* Watts, Duncan J.; Strogatz, Steven H. (June 1998). Collective
On 6/12/2014 2:41 PM, Travis Megee wrote:
... forgive a silly question, but I have to ask: is that your real name,
or an homage to Gregory MacDonald? :)
( http://en.wikipedia.org/wiki/Travis_McGee for those who have never
read a MacDonald novel. Brilliant writing, just brilliant.)
You've seemingly overlooked that the message was typed on a cell and
the autocorrect isn't designed for English. 'This message was sent from
my Android phone via K-9 Mail.' And because you instantly become
personal in your first post and aren't engaging with the real issues,
you're dead as a
Agree. Ppl get personal swearing against me but dont had the kindness
to read the post and try to understand it.
I have read all the posts in this thread and done my best to understand
them. Some things I can't decipher, like
Hust bame it.
... which is, IMO, a case study in why standard
On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
Let me also be clearer about why i find this bug serious...
I am still not seeing why this bug is serious. It still seems to be a
case of mountains and molehills.
I have told numerous people that the keyserver network will not
propagate
On 9/13/2013 5:48 PM, Daniel Kahn Gillmor wrote:
RFC 4880 is explicit:
Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local
certifications from any key they handle.
I don't see a MUST in there. The
keyservers.org will be down for approximately 8 hours on Tuesday for a
server relocation. As with all server relocations it's possible that
things will spring up that keep it offline for a longer period, but at
present I think 8 hours is about right.
On 8/10/2012 11:31 AM, Kristian Fiskerstrand wrote:
Would it be possible for you to share some information* about the system
so that I can try to replicate it? (OS, SKS version, etc...).
This is an Ubuntu 12.04 AMD64 system running the latest SKS available
from the normal Ubuntu repository.
John Clizbe and I have both had a problem recently with sks recon
crashing in a way that completely borks the PTree/ subdirectory. If
your sks recon process dies and, upon restarting it, you see this in the
log:
2012-08-10 00:38:56 Raising Sys.Break -- PTree may be corrupted:
Due to a catastrophic set of thunderstorms that have hammered public
utilities in the DC area, keyservers.org is experiencing prolonged
downtime. I don't expect it to be operational for the next couple of
days, and the downtime may extend more than a week. My apologies to
those who are
On 6/30/2012 4:31 PM, Javier Henderson wrote:
Weird.
Not particularly: Ashburn is about 30mi/55km due west of my location.
The storm hit the greater DC Metro Area badly, but 55km due west is well
out of the Beltway.
keyserver.kjsl.org is at Equinix in Ashburn and remained online. This
On 6/30/2012 9:31 PM, Brian D Heaton wrote:
Glad you and yours are all in one piece. With no power to over a
million folks, the next few days may get a bit interesting.
Thanks, Brian.
Yeah, as of right now 1.3 million people are without power during one of
the worst heat streaks DC has ever
On 06/04/2012 03:28 AM, Gabor Kiss wrote:
Actually it is not true that SKS does not modify certs.
AFAIK, no one in this discussion ever claimed it does. It was claimed
that SKS never deletes information, which rather moots the rest of your
email. :)
On 6/4/12 4:27 PM, Jeffrey Johnson wrote:
But there are also reasons to add better policies like Do Not
Modify or I live in the EU and privacy laws permit me to insist
that my pubkey be removed. to manage server-to-server distribution.
The problem here is that the keyserver network would
On 05/31/2012 01:41 AM, Gabor Kiss wrote:
You have trust a long and thin chain of signatures between you
and your abroad comrade. What if a government agent edged in the chain?
1. Then you're goatscrewed, because you're trusting the wrong people,
and there is *no* technology that can help
On 5/27/12 5:50 AM, Giovanni Mascellani wrote:
I'm just a newbie here, but actually I'd like to see the same concept
applied in a more general way: I think there is much garbage in the
keyservers, even behind the PGP robo-signer.
The problem here is this violates one of the principle design
On 5/27/12 6:53 AM, Gabor Kiss wrote:
My idea: there shoud be five wise and trusted peoples -- i.e.
a committee.
Theoretically possible, although it'd be very difficult to find five
people the entire PGP community could/would trust. As soon as you
introduce a committee of people with some kind
At present, there are no credible reports of the keyserver network being
used to distribute illegal data. I'd like to repeat that: at present
there are *NO* credible reports of the keyserver network being used to
distribute illegal data. Please don't think I'm crying that the sky is
falling,
On 05/16/2012 01:12 PM, Kristian Fiskerstrand wrote:
As upstream bandwidth capacity is one of the considerations that is
taken into account in [0] I would appreciate if the server operators
that have not already done so would kindly email me this information
off list (My UIDs in 0x6b0b9508
On 05/11/2012 10:34 AM, Sebastian Urbach wrote:
server name(s) to delete ?
keyservers.org, please. Thank you.
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/10/2012 06:34 PM, Arnold wrote:
The readme says: This ... version ... is intended to humiliate
and expose the following persons
Likewise.
More to the point, when using a precompiled binary one must trust the
good intentions of the
The other major problem with static linking is it forces the maintainers
to sync their releases with BDB security releases. If a defect is found
in BDB and sks is statically linked, a new sks has to be released. If a
defect is found in BDB and sks is dynamically linked, no new release of
sks
On 04/29/2012 05:42 PM, Jeffrey Johnson wrote:
If there were any BDB security releases, you might have a point.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1436
Yes, that's actually a bug in the libc db interface, not BDB itself, but
the point still stands: this is something that
On 04/21/2012 01:28 AM, Daniel Kahn Gillmor wrote:
If the packaging meets debian quality standards, i think we can pretty
easily get it into debian proper -- no need to host it on the google
code download page.
I've never packaged for the Debian trees: I've only ever made .debs for
my own
If we're in need of 1.1.3 packages for Debian and Debian-derived
distros, I might be able to help. My OCaml is no better than functional
(pardon the pun) and my knowledge of .debs is far from comprehensive,
but I have free time to devote to this.
At present I have zero interest in taking over
On 12/11/2011 8:55 PM, Daniel F wrote:
Please see my response above. I am sorry if the proposal as is
didn't make it patently clear, but it was originally written for
people with the right context, and I failed to realize that there is
that significant omission from the POV of a third-party
On 12/9/2011 12:36 AM, Daniel Kahn Gillmor wrote:
I'm not sure this is OT on sks-devel, unfortunately, so it'll be my last
post on-list on this thread.
Likewise, although I suspect here is as on-topic a place as we'll find.
On 11/2/11 5:49 AM, Andrey Korobkov wrote:
Is there any chances that SKS would be ported to some other, more
common databases like MySQL?
Berkeley DB isn't quite ubiquitous, but it's close.
What is the reason behind choosing BDB as a storage?
It is exactly as much hammer as we need for the
On 10/14/2011 1:39 AM, oakwhiz wrote:
In my opinion, you're better off with a self-signed certificate,
because you cannot trust the certificate authorities not to sign a
fake certificate for use in a man-in-the-middle attack.
Although there are certainly some unreliable CAs (Diginotar as an
On 9/26/2011 10:51 AM, Timothy Holtzen wrote:
Is it just me or is that not a valid key ID.
It's just you: it's a valid key ID.
A complete key ID is the same as the fingerprint of the key. A short
ID is the final eight hexadecimal digits of the key; a long ID is the
final sixteen; a full ID is
(I hate to sound unhelpful: it's only because I'm presently @work and
can't spare the time to give this the full attention it deserves. Expect
more later.)
John, although I heartily approve of what you're trying to do, your page
does not pass the W3C's validation tests:
On 8/29/11 2:17 AM, Phil Pennock wrote:
After seeing Samir's suggested index.html page, I decided to make a few
updates to my own. It's a nasty competitive streak that sometimes comes
to the fore.
Although I don't mean to dissuade anyone from following their muse, why
HTML5? Wouldn't 401+CSS
On 7/30/11 2:42 AM, Scott Grayban wrote:
How is that rude ? All I asked was why are you using beta software on a
production server ?
Yes. And notice all the hidden assumptions and implications:
1. I am, or should be, running a production server.
2. Fedora is beta software.
3. Beta software
On 7/29/11 11:47 PM, Scott Grayban wrote:
Why Fedora? Why use beta software for a production server?
This is a whole set of rude assertions and implications masquerading as
a question, and for that reason I'm going to ignore it.
___
Sks-devel mailing
categorized the U.S. as an endemic surveillance state. And since
that time it has continued to pursue private information and to do
so often without a warrant--though the FISA court has yet to decline
a single warrant request.
Although I don't mean to open a political can of worms here, why
It will eventually become larger than a standard DVD, making it more
difficult to transport via 'sneakernet' (physical media.)
Not appreciably difficult: pretty much every halfway respectable archiver on
the planet lets you break up archives across multiple media. Heck, even
Microsoft .CAB
On Wed, 1 Jun 2011 15:10:01 -0400, Phil Pennock
sks-devel-p...@spodhuis.org wrote:
Note that we've already lost one valued keyserver operator in Germany
Austria, I think -- not that it matters to your example, but I don't want
to make Austrians feel we're treating them as southern Bavaria. :)
On Wed, 01 Jun 2011 15:06:08 -0700, Scott Grayban sgray...@gmail.com
wrote:
You can search the keyserver using just the email address and they would
still get the new pub key
Why would they use it? Oh, hey, I see a new public key has been
uploaded. But the one I currently have has worked for
On Wed, 01 Jun 2011 11:09:27 -0700, Scott Grayban sgray...@gmail.com
wrote:
Maybe I'm the rookie here but not a linux rookie, I have been using
linux for the past 15 years, just google my name, and I always run into
the group that would rather take the easiest way and ignore a issue
that is
I'm starting to think that a non-reconciliation keyserver protocol should be
developed separately from SKS. This will allow the robustness of SKS to
coexist with the convenience of traditional peer-to-peer networks where nodes
with lower redundancy are constantly being added and removed.
In theory an optimal value could be computed but there are
too many parameters (e.g. network delay and bandwidth...
Additionally, these parameters are in effect constants. The SKS algorithm will
have roughly logarithmic speed in propagating keys through the network:
everything else
On 11/29/10 3:55 PM, Daniel Kahn Gillmor wrote:
I'd like to suggest that they should, but i'd be interested in hearing
arguments to the contrary as well.
Many keyserver operators run under the aegis of larger networks, and are
beholden to the decisions made by network administrators above them.
The issue is one off vs. wholesale, and the initial inquiry from the .edu
poster demonstrates that it is not generally known how to get all 2.9 million
without effort beyond that of a casual attacker
The initial inquiry from the .edu poster demonstrates only that the original
poster didn't
On 10/14/10 10:07 AM, R P Herrold wrote:
Trimming away and ignoring clearly stated questions to reframe away hard
parts is a common 'debate society tactic' -- engage or be ignored
This has become tedious. Rather than answer my questions, you accuse me
of engaging in cheap theatrics and attempt
On 10/14/10 12:42 PM, R P Herrold wrote:
Review the bidding. I rather believe you initiated the uncivil tone,
and I have been mild in reply:
Hansen:
herrold:
and [impairing] the privacy of a whole community's members
This is nonsense.
and an EOM. I think that qualifies as rude.
That
On 9/7/2010 2:45 PM, Peter Pramberger wrote:
Several weeks ago I got a complaint from a user getting his old PGP
key removed from my keyserver. He got the usual answer in such cases,
but unfortunately wasn't accepting it. Instead he insisted on his
right to get the key removed, in accordence
On 9/7/2010 6:55 PM, Anakin-Marc Zaeger wrote:
Just out of curiosity, what effect, if any, would said Austrian
legislation have on those of us with keyservers in countries other than
Austria? While the law itself is domestic in nature (I doubt that
Austria or any other country would be able
On 9/7/2010 9:50 PM, Yaron Minsky wrote:
I think that a basic form of deletion is pretty easy, and requires no
real research The algorithm is simple. You simply add a new kind of
pseudo-key to be gossiped around: a deletion token. In the simplest
version, the deletion token never expires;
On 9/7/2010 10:57 PM, Jeff Johnson wrote:
Well yes but ... this is NOT an illegal piece of information until
litigated afaik.
Imagine some well-meaning but deranged Wikileaks activist decides to
take GIFs of the most salacious Wikileaks documents, creates a phony
public certificate, and a ton
On 8/22/2010 8:04 AM, Arnold wrote:
This is a national law / ruling applicable to just one country.
Even less than that. It's a state law applicable to just one state --
neither one of our largest nor most populous. (It is beautiful and I've
found the people there to generally be quite
On 8/22/2010 10:47 AM, David Shaw wrote:
Robert, are you really saying what you seem to be saying? The action
of the owners doesn't make a keyserver a CA. That makes the person
running the keyserver a CA.
Yes. I was using keyserver as synonymous for keyserver operator.
Imprecise language, I
On 8/22/2010 10:54 AM, C.J. Adams-Collier KF7BMP wrote:
Because none of the information provided indicates in any way that the
private key corresponding with the public key provided is under Chris'
control.
If Christoph were himself making assurances about certificates, this
would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello!
keyservers.org is now online, running SKS 1.1.1. It's running on a
small server in Silver Spring, Maryland, on an IPv4 network. The key
dump is current as of last week, and has already reconciled with a peer
and is current.
keyservers.org
86 matches
Mail list logo
