[Freedombox-discuss] Debian as though cryptographic authentication mattered Questions
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
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Reply to: