[Freedombox-discuss] Debian as though cryptographic authentication mattered Questions
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 :/
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110805/0b0edb9c/attachment.pgp>
Reply to: