On Wed, Apr 8, 2015 at 9:35 AM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
On Wed, 8 Apr 2015 15:05, phill(_at_)hallambaker(_dot_)com said:
My point here is that if we want to get a billion people using
encrypted mail then it has to offer iPhone class usability, not OK for
1990s usability.
If that is the goal you only need to care about 140 character messages
or other useless status messages ;-).
Actually I prefer 1990s use of mail instead of todays 50% of mails are
going through Compuserve^WGmail. But yeah, I am on a lost position with
that.
There are plenty of ways that the scheme could be fixed. Since key
server enrollment can be made automatic, it would be pretty easy to
renew the enrollment once every n months and discard keys that have
It is about mail. Mail addresses are defined by the DNS. Bind the keys
to the DNS and your are done. This needs support from the mail
providers, though.
I really don't like the use of the DNS for any scheme requiring more
than host level granularity. We have tried to put user email addresses
in the DNS from the very start [RFC1035]. It has never worked.
Personally, I believe that owning your personal DNS name is as
important for security as having a keypair. I have a huge part of my
brand invested in hallam(_at_)gmail(_dot_)com which I don't own. Which is why I
switched to phill(_at_)hallambaker(_dot_)com for ietf work. But I have yet to
win
that argument.
I really don't like having ICANN as my root CA either. DNSSEC is a
monolithic, single rooted scheme which I don't consider very
trustworthy because of that.
We do need trust hierarchies for key management. But each individual
should be the root of their personal hierarchy.
Having the key servers continue to regurgitate false or stale data
forever because there is no way to stop them does not seem like an
acceptable plan to me.
Think of signature verification. It should work even after a mail/key
association has been disolved for example after a provider change. I
agree that this is onluy a problem for a smaller group but this is
something a keyserver network can be useful even after the migration of
the public key store from keyserver to more controlled service (DNS,
Web, whatever). Deleting keys from the keyservers is thus not going to
work.
I don't think anyone has signature validation done right today. All
signatures are broken unless they are enrolled in an append-only log.
To verify a signature, you need to go back in time to the point where
the signature was created and check the signature in that time
context.
This implies that all the cryptographic credentials should be enrolled
as well. Which is something I am working on right now. But in JSON,
not ASN.1.
The expiry of the hash chain patent is an opportunity to do
interesting stuff that was encumbered before.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp