Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)
> 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 was the advice I received, tailored to my specific situation. Other US-based operators in different situations may have different legal exposure. The more connections a US operator has to the EU, the greater the EU's ability to apply leverage. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
> 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 any and all arguments that start with "but it's the law!" are meaningless for me and many others. It may be your law but it's not mine and I'm not obligated to follow it. > Do you think people having the right to better privacy is bad? Of course not. But you seem to believe the GDPR is clearly a win for the liberties of all people involved, whereas the truth is it prioritizes one kind of liberty for one person (your right to be private) above another kind of liberty for another person (my right to share facts with others). It's okay for people to disagree with the tradeoffs of liberty that are baked into laws. That's called political dissent, and respecting dissent is every bit as important as respecting privacy. Start showing some. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
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 actually wind up getting used for, and very often the two are nothing alike. The #1 use of OpenPGP today is for Linux distros to verify system packages. That accounts for 95% of all OpenPGP usage -- maybe more. Tools are just tools. We, we human beings, are the ones who have purposes and ambitions and goals. > GDPR is also about one's ability to hide private data They are different far more than they are similar. If I use OpenPGP to secure my communications, I'm not imposing anything on people who acquire my communications. If they can break the crypto, go for it. If they can't, tough luck. But I'm not telling people who already have the data, "oh sorry, you can't have it now." The GDPR is completely different. You can give me your personal information. I can give you complete up-front disclosure about what you're getting into. You can review it, you can decide that yes you want to do this, you can give me your data... and then, ten years later, you can force me "hey, I changed my mind, you've got to erase data now." The OpenPGP model *compels absolutely no one*. GDPR is built around the idea *the EU has the right to compel people to delete data.* I'm an American. If the EU thinks it has the right to compel me to obey a law I had no say in, well, good luck. > To me, it is very strange to read one strongly supports one form of > privacy, while totally ignoring other forms. Then I think you really need to study ethics. *How we do something* is just as important as *what it is we do*. I think there's a lot to be said about pursuing privacy in a way that imposes no obligations on any other people. And I think there's a lot to be said against pursuing privacy in a way that imposes obligations on people who don't even live in the EU. > Remember, people in different parts of the world do have different > values and different needs. Yep. And in America, we value our right to be left alone from the government telling us that we're required to take certain acts just because some people in Europe insist we follow their laws. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
> 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 a lawyer? Depends on the individual. I rarely travel to Europe and have no financial holdings there. It gives me a great ability to say "no, I'm not signatory to your treaty, go away." Other Americans may have enough ties to Europe to make it possible for EU courts to apply leverage. > I remember also that plenty of US sites (small and large), where I > did business with, asked for my consent as EU citizen, when they > changed their privacy policy once the GDPR took place. Some of them do business in Europe and are susceptible to pressure by the EU. Some of them were just jumping on the bandwagon. > Has an US SKS key server operator then not 'business' ties with EU > citizens, when storing their personal data like name and email address? No. Those are considered facts no different than tracking a name and phone number. Mere facts cannot be suppressed by the United States government; citizens are allowed to share them to our heart's content. > And has Mr. Rude then the right to freely distribute this data, without > protecting it, to the whole world? I don't know anything about him or where he lives or which laws he must follow. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
> 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 control." Yep. "The fact is, foreign governments help other countries enforce their laws through mutual assistance treaties and other mechanisms all the time." Yep. Except that in America, the government *can't* help enforce many parts of the GDPR. The courts prohibit them from doing it. You walk into an American court waving a GDPR writ and it doesn't matter how many EU bureaucrats sign it: if it intrudes on an American citizen's freedom of speech the government is prohibited from participating. This is bog-standard American Constitutional law. "GDPR Article 50 addresses this question directly." No it doesn't. Have you *read* Article 50? "In relation to third countries and international organisations, the Commission and supervisory authorities shall take appropriate steps to..." It doesn't enact *anything*. All it says is, "We want the Commission to do X. We don't know if it's even possible to do X. We don't really care. We're ordering them to do X anyway." It's great to have aspirations, but Article 50 isn't even *law*. All it says is, "we're instructing our guys to look into it." > If this applies to US companies do you think non-profit US SKS operators are > excempted? It does not apply to US companies, except those that have business units in the EU or have extensive business ties with the EU. Doesn't apply to me. Have a nice day. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
> 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 either compel our compliance or punish our noncompliance. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
>> 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 citizen with no overseas business ties, receive a GDPR notice, I'm going to laugh and throw it away as it's not binding within the US. The EU can't even haul me into court over it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] The pool is shrinking
> 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 airline has to worry about GDPR. There are (or at least were) a large number of US-based keyserver operators who were immune to the GDPR. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new attack on sks keyserver ?
> 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 you for your thoughtfulness! :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> 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. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] A brief recap
> 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 choices: * Keep it from entering the system (vetted users, approved submitters) * Find a way to purge it from the system (ending append-only) * Shut down keyservers Saying "we can use blacklists to avoid serving up data" leaves you still in possession of the data. This has bad consequences for certain kinds of kryptonite. And the moment you say, "well, if you're not going to serve it up then you don't need to store it, either" you've just agreed to waive the append-only property. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] A brief recap
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 verification, but in the broad strokes they're very similar.) Why did keyservers evolve in such a way? Because in the early 1990s it seemed like a good idea. The idea was the distributed redundant ledger of cryptographic certificates would make it impossible for a corrupt government to force the removal of a dissident's certificates. During the Clinton-era crypto wars this was a very real concern. It has also never happened in practice. To the best of my knowledge -- and I've been watching keyserver operations for literally more than a quarter-century -- no keyserver operator anywhere has ever been coerced by a government to even try to remove a certificate. The attack we were concerned about never materialized. It's reasonable to ask if, a quarter-century later, it's time to stop defending against it. Further: in the intervening time we've learned that append-only world-writable distributed databases are inherently unstable. Trolls, hooligans, and criminals will poison it with information which is irrelevant to the database's purpose (spam), offensive to many of the maintainers (hardcore pornography), or flat out criminal (child pornography). So we have a few basic choices: *which condition do we waive?* being foremost. * Append-only? Reconciliation just got unspeakably harder. * World-writable? This means restricting keyservers to vetted users. * Distributed? Then there is no more keyserver network. Waiving the "distributed" is technically easiest but it ends the era of keyserver networks. Keyservers become completely balkanized. Waiving the "append-only" criterion sounds nice, because if we can figure out how to do that then we get to keep the keyserver network while gaining GDPR compliance and ending spam and porn in the network. Unfortunately, we have basically fuck-all zero idea of how to actually do it: the engineering challenges are significant. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
> 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 reconciliation is 90% of the problem. Fixing this would make it impossible for older keyservers to reconcile with a next-gen design. > Are there any more problems that need to be fixed? Like seriously, > everyone please write the problems they have with SKS. Please, *don't*. We have had this discussion so many times over the past ~15 years that I can't stand to go through it again. Go through the list archives, read those past discussions, and then if you come up with anything new post it to the list. > To answer my first question, I guess that it is possible to implement > a keyserver with the same interface for GPG users that can still > recon with older servers. Let's not make this situation worse by guessing. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Withdrawal of Service - keys.flanga.io
> 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 vastly changed since 1992, and the network was not designed to be secure against the threats that would emerge a quarter-century later. > So why is the network made immutable by design? If you don't understand how this was important in the 1990s and why, perhaps you should take that as a hint you don't know the system anywhere near as well as you insist you do. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] heads-up: another attack tool, using SKS as FS
> 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 https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] heads-up: another attack tool, using SKS as FS
> 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 network came out of the early 1990s. It was the product of that vision -- where even liberal democracies of the West were tightly controlling crypto and the general belief was that even nations like the US and UK might make it illegal to use strong crypto. We also believed governments would try to coerce keyserver operators into cooperating with man-in-the-middle attacks, and that keyservers would be high-value targets because they were the principal way people could look up certificates. This vision informed pretty much every single engineering decision that went into the keyserver network. It is still the vision influencing the keyserver network today. It is also, as near as I can tell, batshit nonsense. AFAIK, _no_ keyserver operator in the West has ever been served with a court instrument compelling cooperation with MITM attacks or removing a key from the server or whatever. In 26 years this fear has literally never come to pass. Maybe we should rethink our threat model. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] heads-up: another attack tool, using SKS as FS
> 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 as a completed idea. About twelve years ago I looked into something that could be used as a replacement keyserver technology; it went as far as me preparing a grant proposal to look into it further. Unfortunately, I no longer have the paper. :( Working off half-remembered memories: = Joke was the "Jabber-oriented key exchanger". The idea was to have an XMPP bot which could remember key submissions, respond to queries, and send notifications. Alice might start by telling Joke, "I control key 0xDEADBEEF, which I've enclosed in this message." Joke would send back a 128-bit base-64 random challenge for Alice to sign and send back. If Alice did, her public key would get entered into a database with indexes of both Alice's JabberID (JID), the key's fingerprint, the last time Alice connected, and so on. Alice could of course put additional user IDs on the key, and Joke was free to store as many or as few of them as it wished or apply whatever standards were necessary. Bob would then send a message to Joke. "When al...@example.org updates her cert, please send the update to this JID." So when later on Alice updates her key and sends it on to Joke, not only does Joke update its record in its database but it also informs b...@example.com about the change. When Bob's Jabber agent receives the message, it updates Bob's local keystore. Presto: we've solved the problem of ensuring key updates are distributed in a timely fashion (which SKS never solved, nor even attempted to). If a user doesn't connect to Joke for three years, the user's account (and keys) are deleted; this helps prevent cruft from building up on the servers. Joke servers can be kept in sync without resorting to special-case technology. Distributed database replication is a pretty well-established discipline. Two Joke servers with MySQL backends? Pretty easy. What this would destroy is *untrusted* federation. In a distributed MySQL database, nodes need to be able to trust that others aren't malicious. Federated Joke is possible, but requires trust between instances -- but that's manageable, really. I think you could imagine a federation of university-sponsored Joke servers that would have local points-of-presence on almost every continent. = Don't get me wrong: this is nowhere near a ready-for-implementation idea. (It was once upon a time, but once upon a time was a long time ago, and this outline is all I remember off the top of my head.) But it should hopefully go to show you that we don't *have* to repeat the architecture of the SKS network. We can do things differently. Any discussion about an SKS replacement that doesn't start from a completely blank sheet is, IMO, starting off wrong. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] heads-up: another attack tool, using SKS as FS
> 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 yet." If you're pitching a "let's drop all photo IDs", you're in effect answering them "no", "N/A", and "let's make sure dropping photo IDs are part of the next spec". Which may be a good idea, don't get me wrong, but it's not part of a saving-SKS discussion. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] heads-up: another attack tool, using SKS as FS
> 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 GnuPG and Enigmail dropping support for SE packets and those have been deprecated since 2003. The idea of just waving a wand and getting rid of a non-deprecated part of a public key is just ... no. Is it technically possible? Yes. But it would require a significant amount of redesign: we'd have to parse out the key, recognize images, drop them, etc. Right now SKS does *zero* cryptographic verification of the key data; we'd need to change SKS to introduce at least some crypto support. Is it possible without facing a user revolt? No. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] withdrawal of service: sks.spodhuis.org
> 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 anticipation that governments and/or intelligence agencies were the principal threat. The principal threat is actually our own users. And that's a hell of a demoralizing thing for a volunteer network. "And I lift my glass to the Awful Truth, Which cannot be revealed to the ears of youth Except to say it isn't worth a dime." -- Leonard Cohen, _Closing Time_ ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Request: Install an efficient robots.txt file
> 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 generate this key, then please accept my condolences on some low-life jerk creating a key in your name with your email address on it and uploading it to the keyservers. Those people are jerks. Unfortunately, we have no good way to stop them. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Oh, Jeeez...!
> 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 servers who receive a request from an user software to add a key can > easily check the number of zero to find the level of POW and accept or > not the request. If you're talking about the key fingerprint, then this idea is stupid because we already have millions of certificates which we need to preserve, permit to be gossipped/uploaded/etc., without a Hashcash-like POW idea. Your idea is a "give up, nuke the entire GKN, and start over" idea. And while I admire the purity of your notion -- honestly, I do -- if we're going to start over, we can do so much better than this. > The same mechanism can be used between servers for database reconciliation. No, it can't. I'll let you think about this one a while. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Oh, Jeeez...!
> 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 keyserver operator with the lowest proof-of-work, upload there, and bam, they're propagated to the high proof-of-work servers. The proof-of-work required through the system is the *lowest* of all the keyserver operators. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Oh, Jeeez...!
> 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 * 4 bytes per is a <1GiB database. You can spread the task over cores -- it's trivially parallelizable; Amdahl's Law looks at this and starts licking its lips. A smartphone can factor a 64-bit composite in ~100 milliseconds. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Verification of keys on upload and removal options
> 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. Ten minutes later it comes back. The keyserver operator sets up a cron job to delete it every ten minutes... and a week later other keyserver operators ask, "So why is it you're always missing this one certificate?" I would be surprised if at least one keyserver operator today didn't do a second resync a minute after the first, just to make sure no certificates were getting dropped. > If there is doubt in the trustworthiness of a keyserver (operator), other > keyservers can execute the same verification process, and if discrepancy is > found, block deletion/all requests from the rogue keyserver until the issue > is > resolved. But that's not what you said. What you said is, the individual keyserver operator gets to decide whether the removal criteria has been met. Now you're saying, "well, other keyserver operators do, too, so other people get a say in it as well." Make up your mind, draft a formal proposal, and try again. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Verification of keys on upload and removal options
>> 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 removals prevented? > > If owner of private key and owner of UID/email address disagree, the key > stays > off the servers. If they agree there should be no malicious removal. Gone completely. If a keyserver operator can decide that "the owner of this certificate has requested its removal", how can the certificate owner's wish that it NOT be removed be honored? You're giving keyserver operators carte blanche to remove certificates at will -- and that's a level of authority they *mustn't* possess. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Tor hidden service - what's the rationale?
> 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 "they" come after you then you're no longer anonymous. Your anonymous server is no longer anonymous. You need to start over again in order to re-establish a new anonymous server. And that's burn care -- "how do I resume normal operations after I've been burned?" ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Well connected?
> 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 overall, we're talking about a DB that you can easily fit on a device that hangs off your keychain. OpenPGP is a fringe technology at best, and partially due to that we're a long, long way from scalability issues. If we were to grow enough that scalability became an issue, I'd be applauding, cheering, and thanking Divine Providence. 2. Ad-hoc is actually a pretty awesome peering system, so long as you've got a system that can exploit the small world effect -- and SKS exploits it like it was a mail-order bride. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
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 neither have commit privs to the SKS tree nor maintain SKS packages for Debian/Fedora/*BSD, it's probably not going to go anywhere. If you can get two or three of them to say yeah, this sounds good, let's do it, then you've got excellent odds of getting it done. I look forward to hearing their thoughts on this. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
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. This is my understanding as well, and if I recall some past conversations with John Clizbe correctly, he shares in this. However, before we bet the farm I think we should see what Yaron thinks -- maybe he has an idea for a next-generation SKS that would permit this. I don't know how it would be done, but then again, I'm not Yaron. :) So if we're going to introduce new filters, we are going to cause a major disruption with the existing SKS network. While such a disruption may be warranted, it is probably not something we want to do twice, so we should roll all the desired filter changes into one massive disruption. Something seems to be handwaved here. This seems to be about the same level of effort as moving the keyserver to an entirely new protocol. (In effect, it would be.) So perhaps we should first ask, can we do better than SKS? If we're going to go down this route I think we should start by looking at academic research and seeing if there's some new idea that could possibly be used to resolve some of SKS's problems. I completely agree that we only want to do this once. For that reason, I think it would be prudent to give serious thought to whether there was something better than SKS to switch over to. My impression is there is not, but I haven't done an in-depth search, either. So the questions i have for a proposal like this: I think limiting this discussion to just filters is a little premature. If we decide that SKS is the best thing going and we need to keep it, then yes, some sort of filter set seems appropriate. But see above regarding keeping our eyes open to other options. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
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 academic. Start thinking like a rogue whose number one purpose is to break the keyserver network and get away with it. (Note: there is a subtle flaw in what follows. It is left in here in the same spirit that science shows like MythBusters often obscure the precise way they do something dangerous.) The rogue knows it's irrelevant whether it's child porn... only whether people *think* it's child porn. Find an 18-year-old who looks 16, pay them a couple of hundred bucks for a sexual selfie, and you're off to the races without breaking any laws. Or find an 18-year-old and Photoshop the image into looking more childlike. Or create CGI of a little kid being exploited. There are lots of possible ways to create technically-legal child porn. Upload that image and contact the media. Next thing you know you'll see the media pushing for an end to the keyserver networks before it becomes the next front in child porn distribution. After all, this thing plays into all of their hot buttons: it's the Internet, it's a mostly-unknown technology they really don't understand and which vaguely scares them, it's about exploited children, clearly something must be done... this will make great fodder for about a week. And within hours after the first newspaper story about it, the keyserver network would become deluged in real child porn because the people who traffic in real child porn read newspapers, too. Sure, it would be a crime if you told child pornographers to do this -- you'd be aiding and abetting their criminal acts. But if the *media* tells them how to do this, then that's just the First Amendment. You've achieved your goals. You've brought chaos and discord to the world, flooded the keyserver network with real child pornography, turned keyserver operators into social pariahs, brought governments all around the world to bear on keyserver operators... man. Epic lulz. And all it took was a photograph and a phone call to the media, and you wouldn't have committed a single crime. (ObDisclosure: I've spent the last seven years working in digital forensics. If you think I am overestimating the cunning of rogues, or the rapidity with which child pornographers adapt to new distribution mechanisms, I assure you that I am not.) Many servers are not located in the EU, so this would not DoS the keyserver system. I think taking down all of Europe's keyservers for about twenty euros of postage is a critical vulnerability. You seem to have fallen back on the let's do nothing, as this single one proposal does not protect us from *all* evil that Arnold previously mentioned. No. What I'm saying is, the patient has cancer and you're talking about treating the patient's headache. The problem isn't the headache. The problem is cancer. You want to talk about fixing the security problems in SKS? Start by addressing the big problems: namely, a distributed, fault-tolerant, zero-deletion database is a really tempting target for illegal data. Come up with an architecture that addresses that problem and I'll eagerly listen. But right now you're talking about treating headaches. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
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 takes down their server, keeps it up but cooperates strongly with authorities, or gets arrested. The *next*-easiest way is to start filing EU data privacy directives. For the price of a postage stamp you can take EU keyservers offline. This has already been done successfully (see Peter Palfreder as an example). If I were in the EU, I would be far more concerned with this than with maliciously large user attributes. Why would I use your mechanism when I can just write a letter and take down any keyserver in the EU? And if I'm enough of a sociopath as to want to take down the entire keyserver network, why would I be dissuaded by the prospect of needing to acquire just one child porn image to make my attack successful? Call this the Ivory Fallacy. When academics and theoreticians think like rogues, we tend to imagine academic and theoretical rogues. But rogues are generally quite pragmatic people, and in many ways more clever than we are. Upload a 1TiB image? Come on, man. You can do better than that. Are we just going to wait around until someone starts doing this? We can solve these vulnerabilities now. When people start talking about the urgency of immediate action, my skepticism alarm triggers. In my experience, frying pans without fires are few and far between. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
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 has the right of it here. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Rationalization (Was: Questions regarding blocking ...)
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 dynamics of 'small-world' networks. Nature 393 (6684). Available online at: http://labs.yahoo.com/files/w_s_NATURE_0.pdf It's three pages and is plenty worth reading. If you haven't already learned about small-world networks, it'll completely change the way you view things like the keyserver network. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking peers for pgp.archreactor.org
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.) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
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 conversational partner to me. Ah, thank you for the correction! :) With respect to the German language -- I spent a good bit of my 18th and 19th years in Saxony, and it literally changed my life. I found Germany to be a warm and welcoming place, and the vast majority of your countrymen were kind to me. I haven't been back since, although I'd like to. And what the hell. This list has had enough drama and bad feelings as of late, so I'll share a funny story from Hildesheim. --- I was on a bus with my host sister, who had a major English test the next day. She asked if we could speak English so that she could get some practice in before the Prüfung, so there we were chatting away. Sitting across from us was a mother with her young daughter, and the girl's eyes were wide as saucers as she watched me. She tugged on her mother's sleeve and whispered to her, Mutti, Mutti! Ein Ausländer! Hier! Er ist Ausländer! For non-German speakers, that's a pretty rude thing to say. Mom, Mom! A foreigner! Here! He's a foreigner! My host sister and I gave her a quizzical we're right here and we can hear you look, her mother made fulsome apologies, and tried to hush her daughter. The daughter just repeated it, louder, so everyone on the bus could hear. The mother looked as if she was about to die of embarrassment. Finally I spoke to the little girl directly. Ich bin nicht 'ein Ausländer,' I said, scare-quoting the phrase with my fingers. Ich bin Amerikaner, ein Exchangestudent, und ein Freund zu meiner Freundin. My host sister elbowed me suddenly and I knew I'd committed some gaffe, but I went on anyway. Ich bin Robert. Was ist deine Name? Wer ist deine Mutti? The little girl looked as if I'd just slapped her. She turned away, stuck her nose high in the air, and said in an imperious voice -- /That's/ all right. /I/ speak /English/. She looked like a little queen, really, and her accent was straight-up Alistair Cooke. The entire bus broke out laughing. After the laughter subsided I asked my host sister what was wrong. Nothing, she said irritatedly. You just kind of implied we're dating. I'm your Freundin? I blinked. What? It's the feminine of Freund... Yes, and it's used for girlfriends. So what's used for friends who happen to be women? Freundin, of course. I shook my head. But it's the /same word!/ She shrugged. It's more about how you say it, I guess. I stared at her a moment. Your language makes absolutely no sense, you know that? She gave me a glower and a smile. This, from the English-speaker. The bus had a second round of laughter over that. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
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 English (of either the US or UK varieties) should be used on this list when possible. This is not a personal attack, Simon: it's simply telling you that your preferred method of writing is unclear and difficult to understand. Further: I would remind to all parties that courtesy and respect are important to the functioning of the keyserver community. Comments such as If you give a fuck for poolmember's feedback then say it. Would save time to write ignored arguments again and again. or And tobias if u put ur emotions above your prpfessionality its ok for me. Hust bame it. Wonder y emotional insulters may have admin privs at a public paid university. are ultimately damaging to the community, and will likely result in the breaking of peering agreements. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
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 local signatures. This is true. However, as Ray Lee once said, every truth has a context. Here the context is, but if you try to prove how clever you are by creating corner-case certificates, you may wind up hoist in your own petard. If the keyserver network actively forwards these certifications, then users of the keyserver network and local certifications stand a greater risk of global data leakage that they do not want. Please show me real users who are having troubles dealing with this bug. Not just you, because we've already established you're in love with weird corner cases. If this is affecting real users then I would be all in favor of further discussion on this subject. Without them, though, I'm inclined to say enough already! At some point you have to apply the instant-reply rule: if after watching the instant reply three times you have no idea what the correct decision is, then there is no wrong decision. Move forward and respect the decision of the person making the call. In this case, whatever decision the SKS maintainers make, I will cheerfully accept. But i still believe this to be a reasonable expectation IMO, the fact RFC4880 implicitly allows a non-exportable self-signature should be considered a bug. IYO, this isn't a bug but a feature, and SKS's willingness to propagate these self-sigs is the bug. Both sides have arguments in their favor. Ultimately, it's up to the maintainers and the keyserver community to decide which will be the canonical behavior. Although I believe SKS's behavior as it currently stands is technically in error, I do not believe the alternatives you are presenting amount to a good fix. I encourage the maintainers and the community to not worry about this until/unless we see real users being impacted by it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
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 language is not explicit without it. Is it a case of they SHOULD always, they MAY always, or they MUST always? Without specification it's unclear. Although I am inclined to think the current behavior is a bug, I'm also inclined to think this is making a mountain out of a molehill. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Keyservers.org downtime
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. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks recon crashes with ptree corruption
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. The problem I was encountering seems to have resolved itself: it's been running for a few hours now without trouble. If the problem reoccurs I'll start anew with the debug level cranked as far as it will go, and will be in touch with a more detailed failure report. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] sks recon crashes with ptree corruption
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: Failure(remove_from_node: attempt to delete non-existant element from prefix tree) 2012-08-10 00:38:57 DB closed ... then you may join the ranks of those affected by this bug. There is no fix yet, nor do we know exactly what's causing this bug to manifest. For now, if your PTree/ subdir gets borked the best way to proceed is to rebuild the entire PTree/ subdir: $ rm -rf PTree $ sks pbuild -cache 20 -ptree_cache 70 I hope that nobody else has hit this bug; but, if so, I hope these instructions help. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] keyservers.org downtime
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 inconvenienced -- but I think you'll be more inconvenienced by Netflix and Instagram outages related to the same storm series. :) http://www.nbcwashington.com/weather/stories/Storm-Damage-Images-160950865.html The entire DC area looks like that right now -- it's really eye-popping. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
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 datacenter is near Dulles airport, for those who care to look at a map and compare locations with the storm path. Near means it's about as far beyond Dulles as from Dulles to my location. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
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 recorded for the month of June. Pepco, the local power utility, says it may take between a week and fifteen days to get everyone back operational. Power around here has been solid as a rock, but TV and internet are both out and connectivity is provided by a 4G wireless card for my laptop. Traffic and street lights are out all over the place. So, yeah, if you're peered with any keyserver in the greater DC Metro Area, be warned they may be down and may be unable to check in here to say so. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
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. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
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 quickly become the lowest common denominator among all these. The U.S.-based keyservers would need ways to remove infringing copyrighted material (DMCA takedown notices), the EU-based keyservers would need ways to remove to conform to privacy laws, and so on. Taken to the logical conclusion we'd be left with a keyserver network that was the set union of all the legal restrictions of all the countries in which participating keyservers operated -- and I think that would be a not-very-useful-at-all network. Better by far, I think, for the keyserver network to undergo a planned fracture: EU and US keyservers running in separate pools and periodically syncing up. But arguing that the problem should not be considered because … several people have come out quite adamantly … isn't exactly a healthy discussion. When have I ever said the discussion shouldn't be had? I've only ever said that the keyservers have always been guided by a no loss of information, ever policy. And I've also outright said that we need a way to change this policy, because otherwise we're one [insert legal challenge] away from all of us having to shut down permanently or else fear criminal charges for [criminal offense or EU data privacy directive]. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
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 you 2. There is no #2. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
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 features of the keyserver network: We never, never, never lose certificates. It is preferable for a keyserver to outright go down than it is for even one certificate to be lost. If a certificate is lost then a malicious actor could re-upload another key with the same short ID (a very easy thing to do), and that could facilitate all different kinds of attacks on people who don't properly validity-check certificates before using them. If the keyserver goes down then everyone knows in short order there's a problem. If a certificate is lost and silently replaced it might be a long time before being discovered. (Discovery is more likely if the keyserver is synchronizing with others, but there are a lot of standalone servers.) Further, expired certificates are still useful. I have some emails more than five years old that are still relevant and useful. If a certificate gets removed just because it expires, how am I to check the signature on those messages in order to ensure they haven't been tampered with? If the expired certificate remains on the servers, though, I can download it, validity-check it, and be confident in the integrity of my message. The same logic applies to revoked certificates: they're still useful for the same reasons. The keyservers never, never, never lose certificates. That's a design goal and one that the SKS maintainers believe is a good one. I agree with them, and want to see this design goal maintained in all future development. That said, welcome to the community, and please understand that although I think your idea is awful I'm honestly happy to see you here. :) The mailing list is a place where ideas come into violent collision, but we try to be reasonable human beings to each other. Welcome! ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
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 of special power, you open the door to conspiracy theories and every whackjob out there screaming that the Keyserver Committee is the Second Coming of the Trilateral Commission. The completely decentralized nature of the keyserver network is a strength, not a weakness: it means there's no central authority which can be corrupted or subverted. As soon as there's a committee, the door is open for malicious actors to start applying leverage for their own ends. So, yes, this proposal is technically possible but I can't imagine it's politically possible. Too much disagreement over who ought be on the committee, and too much opportunity for malicious actors to exercise leverage. Plus, the instant there's a committee the committee members will likely become legally responsible for the content of the network. If someone were to upload child porn to the keyserver network in the form of an image masquerading as a photo ID, the committee members could arguably be on the hook for criminal prosecution and/or civil liability. Frankly, I don't want that. I already have enough nightmares about running just one keyserver and the possible liabilities that could result without becoming responsible for *all* keyservers in *all* countries and *all* jurisdictions. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] RFE: max-*-size and strip-photo-uids
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, because it clearly hasn't fallen and we might go decades more without the sky falling. That said, the best time to prepare for a crisis is before the crisis hits. I would like to propose two feature requests for SKS. One (which I'll just call the max-*-size feature request) will limit the maximum size of a user ID, user attribute, subkey, signature, etc.: anything larger than this will not be accepted into the database nor shared with clients or other servers. This will help prevent the network from being used to distribute arbitrary binary data, although it could still be evaded by, e.g., breaking a large binary into a bunch of signatures and placing them on the certificate in order, so that they can be reassembled on the other side. The second (which I'll call the strip-photo-uids feature request) will strip all photo UIDs regardless of size. Again, this is not an ironclad solution: dedicated malcontents will just encode their images some other way. *These feature requests have clear, obvious downsides.* (Not the least of which is they won't work particularly well.) I don't believe either of these features is ready for implementation, but I hope that if we talk about it for a while we might be able to reach a better idea that will more appropriately address our needs. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Request for reporting of upstream bandwidth capacity
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 can be used for this). This is sort of a black art. Depending on which online service is providing the test, I've seen my upload and download speeds vary by more than two orders of magnitude. Further, since pretty much all cable ISPs were at one point in league with the Devil before finally usurping Lucifer's throne, I can't even rely on the vague promises made by their tech support imps and balseraphs. This isn't to say there's no point in what you're doing -- I think there's a lot of merit to it! -- but if we all use a different service we're going to introduce an awful lot of statistical noise. Is there any particular bandwidth capacity test that you would prefer we use? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] De-peer sks-peer.spodhuis.org please
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 https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian binary replacement
-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 packager. When I see something like this, it leads me to distrust the packager's intentions altogether. This package is in very poor form, and I am happy to have nothing to do with it. -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iFYEAREIAAYFAk+sS60ACgkQI4Br5da5jhCfiQDfUqXYvsOk3bJvCECaY8BF+XZK BNgbSu8TX9pr/ADfYgFe21QDzpyY7ypmut7VCXpB1wuyqth5Nd+Egg== =OwBG -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
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 needs to be made. Static linking has a place, but the place does not appear to be here. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
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 would be embedded into sks with static linkage, and something that could be trivially fixed out-of-band with dynamic linkage. No nontrivial piece of software -- I repeat, *no* nontrivial piece of software -- has *ever* been released without security bugs, and it is both unprofessional and reckless to state otherwise. If you don't understand this, then I think we're done here because we're not going to agree on anything. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
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 local installation. Should I set up a VM with Debian Unstable and build against that? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
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 from anyone. I think any discussion of that is incredibly premature. But if we need 1.1.3 .debs, I'll do my best to get some stitched together in the next few days. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Requesting your thoughts on a web of trust scheme
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 reader. As per above, this is about trade trust, and nothing else. In that case, I think this proposal fails to take into account the major problems with economic trust over the internet. The principal one is the internet offers both ephemeral identities and pseudonymous identities. If I'm J. Random Person, I have an incentive to become trusted to the point where someone trusts me with a big trade, and then I have an incentive to betray that trust, walk away from my ephemeral pseudonym, reap my windfall and start over again somewhere else. There are a lot of ways people have tried to solve this. You can try to structure trades such that the benefit of future trades is always greater than the benefit to be had from selling out on any one particular trade: but that involves unrealistic models of economic growth. You can try to abolish ephemerality or pseudonymity, in which case, the trust metric becomes quite straightforward and you really don't need this system. (I gave a large sum of money to a complete stranger a few months ago in order to purchase a Mustang GT sports car. Didn't bother me in the slightest -- I knew who he was, I knew where he worked, I knew how long his business had been in operation, and he knew that if he screwed me over I'd sue him. I could've paid for it in BitCoins via an electronic transaction and told him to leave the car in my apartment building's garage and the keys at my desk, and still been perfectly confident the car would've arrived as ordered. The existence of enforceable contracts radically simplifies trust calculations.) Anyway. I hate to sound dismissive, but -- I think you're solving the wrong problem and not paying enough attention to the eight hundred pound gorilla in the room. And with that, I think I'm done here. It's not that the question isn't interesting, but we're now entering the realm of game-theoretical questions and that's unquestionably off-topic for this list. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Requesting your thoughts on a web of trust scheme
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. http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal I see two main ways the proposal could use improvement as presented: I'll reduce my criticisms down to a very simple one: Trust is a human concept, not a mathematical one. We all know someone who trusts someone they shouldn't, even though they know better. Odds are good that we're examples of this ourselves (I know I am). OpenPGP gets around this by using the word trust in an extremely narrow sense, one that makes it useful for a particular task and not much more. This proposal never defines trust with sufficient precision for me to feel comfortable with the document: it attempts to create an infrastructure to support ... what, exactly? Until the problem can be precisely and accurately described, no solution is possible. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 3 million keys and community help requested
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 nail. MySQL and its ilk are tremendously capable databases that can do everything up to and including preparing your morning latte. We don't need those capabilities. Berkeley DB is much more limited, basically working on key/value pairs... which happens to map quite neatly to our problem domain. I think, having SKS work with client-server databases rather than file-based could give it more scalability... I hate to sound harsh, but in my experience the overwhelming majority of the time complex systems do not act in ways that conform to our thoughts and expectations. If you believe this is a good idea and worth pursuing, I'm sure many people on this list would welcome performance metrics between Berkeley and MySQL/MariaDB/Postgres. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.cns.vt.edu updates
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 obvious example), I think it's a leap to go from that to saying there exist *no* reliable CAs. Isn't this the point of using the OpenPGP trust model instead of the flawed X.509 trust model? OpenPGP and X.509's trust models are essentially interchangeable. They work in fundamentally the same way, to the point where the commercial version of PGP lets you use OpenPGP certs as X.509 certs and vice-versa. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Request for SKS key server peer connection
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 the complete forty. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] HTML5 in index page
(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: http://validator.w3.org As of right now, your page has almost 80 errors -- most of which seem attributable to just a very small handful of errors on the page. Kind of like template errors in C++, one error can result in many more spurious error messages. I'm sure it can be fixed without too much headache, though, and I'd be happy to work with you on it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] HTML5 in index page
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 be better supported by existing browsers? Or does 5 add some vital capability that I'm just completely missing? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
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 is inappropriate for a production server. 4. Unless I have a very good reason, I'm doing it wrong. 5. I have some vague obligation to do it right. Let's address each point in turn: 1. This is not a production server (whatever that is: that phrase is about as meaningless as beta). This is the server that lives in my closet, hosts my private Subversion repos, and serves up keys. The total number of users impacted by this machine going down for even a period of weeks is precisely 1, no more, no less. My announcement to the list was so that people I peer with could have advance notice and not be surprised by the downtime. (The downtime is for a most quotidian reason: I'm rewiring part of my kitchen, and I have to throw the breaker that also controls the outlet the server lives on.) 2. Fedora is in no way beta software. It's a mature product and perfectly capable of supporting large projects, the same as any other reasonable Linux distro. I wouldn't mind in the least if someone were to run a production server on Linux Mint, for crying out loud, so long as that person was attentive and knowledgeable. 3. Beta is a meaningless term anyway. I've seen showstopper bugs released in stable releases (such as Java 7's misoptimization of loops) and I've seen beta software that's impressively reliable and feature-complete (GMail). Discounting something just because it's beta software is a cop-out: it means, I am going to latch onto this label and think it means something because doing my own evaluation of the software is too difficult. 4. I reject this one out of hand. 5. Sure, I do. But I don't think you've got much of a place to stand on declaring what is or isn't right. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
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 list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
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 do people believe the low rejection rate by FISC (they've rejected five warrants, incidentally, not zero) is evidence of malfeasance? For quite some time the gatekeeper to FISC was an FBI agent named Allan Kornblum, who knew that his career depended on FISC a lot more than it depended on the Executive Branch. He was sort of infamous for telling NSA go away and come back with a better warrant, I'm not going to jeopardize my career bringing this to FISC, FISC will laugh at me if I bring them this and then I will never get the federal judgeship I'm looking for. Stewart Baker, former General Counsel for NSA, former Undersecretary of Homeland Security, and one of the guys who tried to foist Clipper off on us in the early Nineties, has written a book called _Skating on Stilts_ in which he talks a good bit about the bureaucratic wrangling within the intelligence community post-9/11. Kornblum is portrayed in a few different places as an obstructionist who was getting in the NSA's way. Getting warrants past FISC was not the problem, according to Baker: getting warrants past Kornblum was the torment of the damned. Baker tries to portray this as an example of how bureaucratic infighting post-9/11 got in the way of effective intelligence activities, but me, I thought it kind of said the system was working pretty well. FISC, and everything that surrounds it, is not a single monolithic entity with one single hivemind. It's a political bureaucracy, which means that it's full of strong egos in violent conflict with each other. It's tempting to see government action as the result of a single set of policies carried out by people who are in agreement about how to do things, but really, this seems to be wildly the exception rather than the rule. Usually these people can't even agree on whether they're wearing socks... ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
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 files support this. Also, don't discount thumb drives: I've seen 64Gb ones at reasonable price points and I'm sure larger ones are on the way. SKS is currently the only viable keyserver in my opinion, I find it a bit strange that every peer must have a redundant copy of every key. There are really only two options here: redundancy or uniqueness. If there's only one canonical record of each key then it becomes trivial to remove keys from the network: just take down the keyserver (either through legal threats or extralegal actions like DDoS, etc.). If each keyserver has its own record, these hijinks quickly become impractical: if your given keyserver goes down then you just move on to another keyserver. Given that neither hard drive space, bandwidth, nor physical media is a limiting factor... why should we strike redundancy? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
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. :) This is exactly what the keyserver network is meant to avoid. If that's possible, the keyserver system will have failed. Hrm, I thought the primary goal was to be a convenient way to get keys. Depends on your point of view, I imagine. I'm happy running a free service to others, providing a reasonably complete set of keys; but if you start making assertions about what the keyserver network stands for, please point me to the manifesto which I'm supposed to have signed up for as a keyserver operator, else kindly refrain from speaking for others. I'll look around for it -- I know that when I first started becoming active with PGP, back in the early '90s, PGP had a statement of what the keyservers were intended to do -- not allowing keys to be deleted, in order to prevent repressive governments from defeating crypto by inhibiting key exchange was one of them. That's what I'm referring to. Admittedly, though, you're correct in that it's hardly a holy creed that we've all sworn to uphold. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
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 the past few years and I don't see any revocations attached to it: why should I change? Revocations are important because they tell us to stop using a certificate. Prune away revoked certificates and suddenly nobody gets told the certificate should no longer be used. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
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 bound to come up. Appealing to credentials is unlikely to convince people. There's always someone around with more credentials and always someone around with less, and none of that makes much a difference when it comes to deciding what to do and why. I have always found a good rule of thumb for systems to be not to worry too much. If you can see a potential problem when it's on the horizon, then you can watch it for a while and decide what countermeasures need to be taken once you have a better handle on the scope and impact of both the problem and the potential solutions. Problems that are spotted on the horizon almost never come back to bite you. It's problems that you didn't see coming until they're right on top of you that can really wreck your weekend plans. Consider IPv4/IPv6 as an example -- even though we're (effectively) out of IPv4 addresses, this isn't a problem. The internet still works fine. People who needed allocations made sure to get them before we ran out. We're currently in a state of some stress to the system, but it's not any sort of calamity or disaster. Now, if IPv4 exhaustion came out of the blue and nobody saw it coming... then we'd have a big problem. Don't worry so much. :) Is the DB growing? Sure. What's the rate of DB growth? Far less than the growth rate of cheap physical storage media. Are we keeping our eyes on it? Yes. Should we do anything about it right now? Nope. If you want to talk about okay, so what do we do if/when..., go right ahead: I think that's very constructive. Appeals to Chicken Littleism and the sky is about to fall, though -- well, I tune out. I hear that some people are already running into corrupt PTree db's and have to rebuild them every few weeks... just this alone should be a warning. Cite, please. Hearing that is an appeal to apocryphal anecdote. Who's having these problems, and what's been done to determine the cause of the problems? PGP (keyserver.pgp.com) has been allowing keys to be deleted for years and they even scrub their DB of revoked and expired keys and that hasn't degraded the trust yet. Apples and oranges. The PGP Keyserver is trying to meet a different niche than the keyserver network. Speaking just for myself, I wish them luck in achieving their goals, and I suspect they wish us luck in achieving ours. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Separate P2P Protocol Should Be Developed
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. This is one of those things that is far, far easier said than done. Yaron Minsky wrote the SKS algorithms as part of his doctoral thesis in computer science: that should give you an idea of the amount of work involved. If you wish to pursue this I wish you well and I'd be happy to point you to some good academic references, but in my experience when people talk about how something should be done, that usually means I want someone else to do it for me. This is Free Software. If you think it should be done -- do it, and I wish you well! ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Optimum number of peers
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 (including how many peers you're connected with) affects it only by a constant factor. O(lg N) speed is *fast*. Like, really, really fast. So my suggestion: make sure you have at least two peers and you should be golden. Trying to make it even faster is kind of like trying to put racing stripes and aftermarket body kits on a Saturn V rocket: you can do it if you really want to, but there's not much point. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 2 out of 10 pool.sks-keyservers.net not responding to pings
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. Some networks block ping (usually because of claims that ping is a security concern). I don't like the idea of the community adopting a SHOULD -- even informally -- when a large fraction of the community will lack all ability to conform with the SHOULD. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Dump
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 know. Generalizing from a single data point is not wise. Facilitating anonymous wholesale transfers increases the size of the population able to readily have a corpus to spam at, with a set of assumedly valid email addresses and matching ID information (a) they already have it, and (b) people who upload their certificates to servers willingly accept the risk of their email address being public in exchange for the benefit of having their certificates being easily findable -- and who are you to say their wishes should be ignored? ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Dump
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 to claim some kind of moral high ground. (b) people who upload their certificates to servers willingly accept the risk of their email address being public in exchange for the benefit of having their certificates being easily findable -- and who are you to say their wishes should be ignored? 'There you go again' Clearly a false generalization. For it to be a false generalization (much less a 'clearly false' generalization) you must present evidence that most users do /not/ understand the keyserver network is a public resource. So far I've yet to see it. Neither is the message you quoted relevant to the discussion. The person asking this question was running a standalone, *non-synching* server. This person is totally irrelevant to the question of what the *synching* keyserver community should do. Even then, there are always people who don't read the manuals. Exceptions to the rule do not disprove the rule: they only prove the rule has exceptions. By your reasoning it is clearly a false generalization to say that, e.g., citizens must pay taxes, on the grounds that some people manage to successfully commit tax fraud. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Dump
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 qualifies as direct. If I had called you names, questioned your commitment, heaped aspersions on your personal character, etcetera, that would be ad-hominem and beyond the pale. Your *ideas*, though, are fair game. As they should be, as they must be. You are not your ideas. In my daily work, probably ninety percent of my promising ideas ultimately turn out to be crap. When one of my co-workers listens to me pitch an idea, gives it fair consideration, and then says, Rob, it's crap, I thank him for his time. He's given me everything I could ask for: not only his consideration, but also his *judgment*. He has given me his professional opinion in a clear and unambiguous manner. I can choose to abandon my research project or I can choose to continue it. Maybe it will pan out and maybe it won't. But I will never be able to claim my colleagues did not give me the benefit of their clearest, most direct judgment. I have had co-workers who think that you're stupid is a good criticism. I'm glad to no longer work with them. But I am genuinely grateful for my co-workers who have listened fairly and then told me, Rob, this is nonsense. If you really think that criticism of your ideas and proposals -- even harsh and blunt criticism -- rises to the level of a personal attack against you, well... I don't know what to say about that, besides that I have no desire to speak with you further. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.pramberger.at terminating
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 to the Austrian Data Protection Act (DSG 2000). Everything works great up until some idiot decides to get the law involved. I'm sorry it's ended this way, Peter. Thank you for all your work with the keyserver community. It's very much appreciated. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.pramberger.at terminating
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 to enforce their laws in a foreign sovereign nation), are there any international treaties which this issue may fall under? IANAL. I am especially not an expert on international privacy law, which seems to be (to my layman's eyes) a giant no-man's-land where no one can really predict what various courts will do. That said: commonly, businesses that have offices in the European Union are required to obey EU directives on data privacy, regardless of whether those businesses are headquartered in an EU country. As an example, American airlines must abide by EU privacy directives since they fly into and out of EU airports. There are a *ton* of exceptions to this general principle. After going blind on this subject for a few weeks, what I came away with was you are lost in a maze of twisty little regulations, all different. I can't give any guidance as to whether you are going to be affected by data privacy laws in the EU. I can only tell you that it is not outside the realm of possibility, especially if your keyserver is run by a business that operates in the EU. If you are concerned about this, you need to consult legal counsel that's versed in both US and EU privacy law. Good luck. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
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; it's a permanent addition to the database. But the effect of adding the deletion token is that the thing it wants to delete is effectively removed. With a small amount of extra cleverness, one can allow the deletion token to be removed eventually as well. But given the small number of deletions that appear to be necessary, it hardly seems urgent. I see no reason to think the number of deletions will be small. My nightmare scenario involves people with an interest in illegal information discovering the keyserver network makes a good vehicle for dissemination of relatively small pieces of illegal information. All it takes is one person discovering this and others thinking it's a good idea and the next thing you know we've got keyservers drowned in spam. It's just that this spam could get keyserver operators arrested for distribution of illegal information. (Note: although I see no reason to think the number of deletions will be small, there is also no reason to think my nightmare scenario will come to pass. We simply /do not know/ how many deletions will be necessary. I think we ought keep this lack of knowledge in mind when we discuss solutions.) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
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 of photographic user IDs where each one is a classified document. Whether this is an illegal piece of information is really not the question: whether it will put the keyserver network in a world of hurt is the real question. (Note: I am not claiming anyone associated with Wikileaks would do such a thing. I just like to find other things beyond child porn to use as examples.) And the pubkey was a previously legal piece of information or it never would have ended up on a SKS keyserver in the first place. Someone changed their mind and has a right to their privacy. You're assuming the certificate originator originally intended to use the keyserver networks as we intend it to be used. I think we shouldn't make that assumption. The keyserver network is a reliable, scalable, highly deletion-resistant way to distribute small quantities of information. There are a ton of use cases for it which are at odds with the desires of (one would hope) the great majority of keyserver operators. Or am I missing something essential here? Possibly. It's just as likely that I am. :) 73, de kc0sje. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
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 pleasant, but that's beside the point.) I do not understand what Adams-Collier is on about, either. When I posted a couple of weeks ago to ask for peers, I received an email from him simply reading ping? I asked if there was something he needed, and got no response back. I don't know what to make of either my interaction with him, or of his interaction with Christoph. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
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 grant, but that's English for you. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
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 relevant. As he is not, I don't see how it is. The assurances are made by the individual signers on the certificates he distributes. I don't imagine you're going to demand each and every certificate holder contact you to verify their private keys -- so why do you expect Christoph to do so? Perhaps there's a good reason for it, but so far I'm not seeing it. (1) The secretary must recognize one or more repositories, after finding that a repository to be recognized: ... (d) Contains no significant amount of information that is known or likely to be untrue, inaccurate, or not reasonably reliable; I am not a lawyer, obviously. However, it seems to me that if you consider Christoph's private certificate to be a significant amount of information, even though it has absolutely no influence on the public certificates he distributes, you must also consider the individual signatures on those certificates to be significant amounts of information, since those do influence the public certificates. (This doesn't even get into the 45 keys on the keyservers marked as whitehouse.gov, or the ones in the names of various celebrities, and so forth. There is a significant amount of information in the certificate pool which is likely to be untrue, inaccurate, or not reasonably reliable.) All of this is correct. However, the advice is generally applicable to signing- and trust-related activities. It is generally applicable within your security model. I am skeptical that your advice is applicable within mine. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Looking for peers
-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 11370 # Rob Hansen r...@mozilla-enigmail.org 0xD6B98E10 Thanks! -BEGIN PGP SIGNATURE- iFYEAREIAAYFAkxZslwACgkQI4Br5da5jhCDowDgt0bT2gvl8VLeho/vzwkSdl40 xQtDLf2+rLrjpADgw5b+rUF7++676ePAZmIiyHTiFke4a815AA49tQ== =YAI6 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
