On Fri, Aug 05, 2011 at 02:48:06PM -0400, Daniel Kahn Gillmor wrote: > On 08/05/2011 09:41 AM, John Walsh wrote: > > First of all a hat tip to dkg for an excellent presentation. > > thanks, i'm glad you found it useful :) > > > Keys are needed to encrypt everything (doh!) > > I'd actually argue that signing things is in some ways more fundamental > than encryption things, but yes, i agree that keys are needed to encrypt > things too. > > > so keys cannot be > > avoided and much be built-in to the FBX UI. > > i think keys must be built into the FBX stack, and there must be some > certification and verification mechanism/experience in the UI, as well > as some more-general identity management which would be tied > (under-the-hood, as it were) to keys. But I would hope that this UI > wouldn't expose the raw public keys to the user, since they're pretty > ugly :/
+1 Btw, I've started a page on the wiki to begin to draft this idea: http://wiki.debian.org/FreedomBox/IdentityManagement That would be very usefull if we could use it to define the way we envisage this question. > > Secondly, if you add a new > > service (email server) you can generate a new subkey which is used as a > > password for the email server - cool I don't have to worry about passwords - > > leaving you with one "master key" for everything. > > I think the idea here is to have a way to identify yourself to anyone. > public keys can do that without even necessarily needing a new subkey > per peer. that is, if you need to authenticate to two different SMTP > servers, it's possible to use the same key with both, and you wouldn't > need to worry about replay attacks (that is, one server couldn't use the > fact that you authenticated to it with key X to authenticate to the > other server, even if that other server recognizes you as the holder of > key X). > > > 1) Do certs/keys have to contain personable identifiable information? Could > > the certs contain pseudonyms to protect people's privacy which is a goal of > > the FBX? > > keys on their own have no personally-identifiable information; they're > just mathematical constructs. > > certificates are data structures which contain one or more keys, plus > some identifying information, and some markers or description about how > the keys and identities are intended to be used. The key material and > the identity and/or authorization material are bound together with one > or more cryptographic signatures. > > None of these things requires the use of legal or birth-given names. > > I'd be cautious about the claim that pseudonyms "protect people's > privacy". It requires a lot of work to maintain a pseudonym and keep it > separate from a "meatspace" identity. > > > 2) The WebID solution is to generate an "unsigned" cert which points back to > > your public key on your "username web page", i.e. your username page is > > acting like a key server. So, if I have the private key (in my cert) for the > > public key held on a username page, then I control the username on that web > > page, thus confirming I am the owner of that identity/key/cert. Why are keys > > held on centralised public key servers when the WebID model seems more > > secure? > > the OpenPGP keyservers aren't centralized; there is a mesh of > "gossiping" peers, which all publish all keys. SKS is the main > implementation today. The keys which are published there are *public* > keys, not secret keys; there's no risk that secret material would leak > to the keyserver network. > > Note that WebID only works if you can find the public web page in the > first place, so it actually relies (in its present form) on DNS and the > Certificate Authority Cartel. > > > I question the value of getting "Bob from the key signing party" or > > your friends to sign your key. > > If i know Bob, and i think he is responsible about only making > reasonable certifications, why wouldn't it valuable to have him sign > your key? If i don't know Bob, or i think he's sloppy or lazy (so i > don't rely on his certifications), what's the harm? > > > Having your friends sign your keys raise > > privacy concerns even if they are allowed to use pseudonyms. > > What are these concerns? > > > I would prefer > > to have my key signed by the traditional real-world identity providers i.e. > > government agencies which would remove any privacy concerns about your > > friends using the WOT model and offer a lot more credibility than "Fred's > > CA". > > This is not an "either/or" choice. With a sensible certification > architecture, there's no reason that multiple parties can't certify the > same thing. > > Then I thought why aren't governments filling this traditional role and > > this made me think that although it's required in the real world maybe there > > is no *current* need for it in the online world. So, do we really need a > > WOT/ CA model for clients? The paranoid side of me wonders can you track > > someone if you have signed their key like openid providers can track you? > > The answer is No, at least not currently, in the OpenPGP certification > scheme. > > Some other approaches (e.g. X.509 certificates used with OCSP-enabled > endpoints) do allow the issuer of the certificate to track its use, > though they don't get the same amount of information that an OpenID > provider gets. They just get a ping from some peer on the network > saying "hey, has certificate X (that you issued) been revoked yet?". > > OpenID providers get much, much more information when a credential is > used (they learn where it was used, and what information was passed to > it). Note that you can run your own OpenID provider. > > > > So, obviously you can see my train of thought. When you create a username > > you automatically generate a key and on the > > http://username.mydomain.tld/about_me page you hide/store your public key. > > it's not hiding if you want people to find it :) > > > I would argue that it's not currently required in the > > online world otherwise there would have to be a WOT attached to your email > > address. > > I'm not sure exactly what you mean here; but if you're saying "e-mail is > currently not cryptographically-verifiable or safe from snooping" then > i'd say "you're right!" But I don't think this is a good argument that > e-mail should *not* be cryptographically-verifiable or safe from > snooping. We're trying to fix things here :) > > > If/when it's required in the future, I think keys should be signed > > by government agencies as long as they can't track you through signing your > > key!! > > Why governments instead of some other parties? Tracking isn't the only > issue. Another issue is impersonation. If some government happens to > be your adversary, they can issue themselves certificates in your name, > and masquerade as you on the public network. > > ----------------- > > Here's a thought experiment about who should be an "acceptable" certifier: > > Imagine that you and i met up in a cafe to chat about these things. We > have a nice discussion (without coming to perfect agreement, naturally), > drink some lemonade, exchange key fingerprints, eat some tasty cookies, > and go home. > > Later, you get a communication over the network that purports to be from > me, inviting you to connect to a server that i run that hosts, say, a > jabber service you might want to use. > > How do you know that the message came from me in the first place? > Should you need to trust a government to identify me? What about a > member of the CA cartel? > > Let's say you decide to connect to the jabber service my message refers > to; is this the right service? Should you need to rely on a government > to properly (cryptographically) identify the service? What about a > member of the CA cartel? > > My point is that we can bootstrap *all* of these authentication > questions entirely without the aid of any government or CA. And then we > can build nice things like authorization and confidentiality based on > that authentication. The insertion of a government or a member of the > CA cartel, or any other third party into this story can only weaken the > integrity and confidentiality of the communications involved. > > ------------------- > > The next step to the above hypothetical of course involves people who > haven't had a chance to meet together in a cafe. Does the government or > the CA cartel become more useful in that case? What if the people > involved have a mutual acquaintance or two? > > --dkg > > _______________________________________________ > Freedombox-discuss mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
