[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] Debian as though cryptographic authentication mattered Questions



On 5 August 2011 20:48, Daniel Kahn Gillmor <dkg at fifthhorseman.net> 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 :/
>
>> 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.

Thanks for some insightful comments.

Wasnt aware that key servers gossiped, that's a good approach.

>
> 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.

While the WebID Protocol is designed such that you publish your key on
a webpage, nothing would stop you getting the public key out of band,
from a proxy, or from a key server, or a trusted store.

Here's one I'm playing with

http://publickey,info/

Which is going to keep track of profiles that publish public keys, and
checks them over time.  e.g.

http://publickey.info/?webid=http%3A%2F%2Fmelvincarvalho.com%2F%23me

Note that you get an extensible read only distributed social network
for free with this approach (currently with around 100 million ids,
and google have said they'll join too). One of the next tasks is to
make this read/write, which is a topic in itself.

The nature of WebID is that public information is machine readable and
mirrored in many places.  So while the obvious place to look for a
public key is on the users homepage, it can be found from one of the
many structured data stores out there, such as:

http://sindice.com/

You've intrigued me with the gossiping idea.  I spoke to someone this
week who has crawled 50 million WebID profiles, so perhaps this is a
good option.

In general it would be fair to say WebiD has a dependency on DNS but
so does email email.  In both systems there are cases where you can
work without DNS.

Unsure of the supposed dependency of the CA Cartel, given that
certificates are self signed.  Perhaps I'm missing something, tho.

>
>> 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: