[148543] in cryptography@c2.net mail archive
Re: [Cryptography] The next generation secure email solution
daemon@ATHENA.MIT.EDU (Joe St Sauver)
Fri Dec 20 16:02:13 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 20 Dec 2013 09:03:17 -0800 (PST)
From: "Joe St Sauver" <joe@oregon.uoregon.edu>
To: crypto@senderek.ie
X-VMS-To: SMTP%"crypto@senderek.ie"
Cc: cryptography@metzdowd.com, guido@witmond.nl
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Hi,
Ralf commented:
#A user finds some website interesting and trustworthy and
#signs on. He gets a client-side X509 cert from the site
#that is stored on his local computer (including unprotected
#private key) under a globally unique name, that can be but
#needn't be his own.
Solutions that rely on client X509 certs inevitably run into
a fairly common set of issues, a subset of which include:
-- a client cert is dropped by site in user's browser, but
the user then changes and begins to use a different browser
(which potentially has a different trust store and no
knowledge of the user's cert from the other browser)
-- user uses only one browser, but has multiple devices (which
again implies, "How do we get the certs to those other
devices?)
-- some systems (hypothetically, systems in a university drop-in
computer lab, a family system, systems in a public library)
have multiple users and may not support individual accounts
with persistent storage for secure credentials
-- fragile as PKI support is in some products, the more certs you
attempt to support, the more fragile that support appears to
become (at least that's been my experience)
#Users need their certificate to log into the website that
#has issued the cert, there are no passwords any more and whoever
#*has* the unprotected private key *is* the person and can
#use the SEI.
Do you have concerns about malware harvesting the user's private key?
#The user's local machine (the endpoint) is secure.
I think it is, as a practical matter, hard to assume that a typical
user's local machine is secure...
#Any website can create these certificates for users as long
#as SEIs are globally unique but only for local users.
So help me to understand what the user identitifier might look
like on that client cert. Would it be a locally assigned
"customer-ID"? cust1234@example.com ?
And at some other site, that person might be user456@example.org ?
#How does a user get a key?
#Read: How does the software on the user's computer fetch the
#correct recipient's public key without the user noticing what
#happens behind the scenes?
#
#The user knows the recipient's SEI, it's like an email address
#stored in the contacts list. The machine searches for the
#recipient's public key in the local key store, which contains
#all keys for SEIs that have been used before. (like ssh's known_hosts file)
Do you envision privacy issues related to the maintenance of a
global directory of this sort?
How would the global directories maintained by individual providers
be synchronized, linked, or at least be searchable from all the other
providers?
#And if the endpoint (local machine) is the place where the private key is
#stored we will soon have another pile of SEIs becoming unusable, when laptops
#get stolen, hard drives die and local OSes become unreliable without proper
#backup procedures. This will happen.
Do you envision user discontent if their old email ceases to be accessible
when that event occurs?
#So in the end we will have a mix of working addresses and dead addresses and
#nobody can tell the difference.
If that's the case, how will users select the "right" address to use for a
given individual?
Regards,
Joe
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography