On Sun, Jul 26, 2015 at 8:42 AM, Paul Wouters <paul(_at_)nohats(_dot_)ca> wrote:
On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote:
Agreed. But OpenPGP already has a fairly effective key distribution
infrastructure.
You mean 3 or so commonly used pgp key servers, with the main MIT one
being down for some considerable time recently? I takes about 5 firewall
rules for any nationastate to block you from fetching pgp keys.
Nationstates can also block DNSSEC resolution without breaking anything.
I am happy to leverage the DNS as one way to validate keys but it can't be
the only way. And the way it is designed means it
isn't actually a particularly convenient one.
No one saying it must be the only way.
How would you design it differently to make it more convenient? We have
an easy known QNAME, a dedicated RRtype, a known specified wire format
payload of something you can feed straight into any pgp/gpg tool, and
a DNS presentation format that is ascii armor format in the same way as
the RFC and openpgp tools use themselves. How can I make this more
convenient for you?
Yes, every end entity should have their own key. But if all you do is
domain validation then the domain owner is alway going
to be able to sign for alice(_at_)example(_dot_)com by publishing a key.
Right now with what you call "fairly effective key distribution
infrastructure", anyone can make a key for phill(_at_)hallambaker(_dot_)com
and
publish it there. Limited bogus keys to only those who control the domain
you picked based on the people running that domain seems like a great
win to me.
But no one thinks that the presence of a key on a server is proof of
identity. By contrast the whole point of DANE is to use DNSSEC
signatures as such proofs. This notion of validity is pretty bad when
we consider gmail.com or hotmail.com. The change to the trust model is
being smuggled in here under the guise of key discovery, and it's a
pretty big change. I don't see how you get the information to use PGP
WoT with the keys discovered with DNS except through keyservers.
Yes, the key servers work. They are deployed. The only reason to replace
them would be with something better.
if openpgpkey saw as much usage as for example OTR, these servers would
contain millions of bogus keys generated by adversaries. As I said
before, it's hard to create infrastructure that's worse than the current
key server scheme.
The question is not how many bogus keys are there. The question is
will users use them.
It sounds to me like you're interested in DNSSEC Transparency.
Perhaps
you could take that up in the trans WG? I know there are other
people
interested there (i am!) but this discussion doesn't belong on the
OpenPGP mailing list.
Yes, I have written a TRANS notary (besides the one Rob wrote). I know the
spec. But that is an infrastructure targeted at a
single task and working within a set of rather obnoxious constraints
(PKIX).
Right now, that discussion certainly does not belong in TRANS any more
than OpenPGP. I am suggesting we use
therightkey(_at_)ietf(_dot_)org for that sort of discussion.
<trans wg chair hat>
There is currently interest in picking up CT for DNSSEC. One of items
that needs discussing is which records to allow in the log. Some of
that discussion would definitly be useful on the trans mailing list.
</hat>
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
"Man is born free, but everywhere he is in chains".
--Rousseau.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp