Answering phb and dkg:
I looked at it with Petr Spacek after the meeting, and i plan on
providing Paul with a more detailed review shortly.
Greatly appreciated!
DANE is trying to do three different things. It is trying to be a key
discovery service, a security policy publication mechanism and a way
of validating keys using the DNSSEC.
I think this overview is accurate.
That's not how I see it. It is surely a discovery and distribution
system for keys. But it is not a policy publication mechanism. The
draft (carefully) does not tell you what you can or cannot do with the
key. Some people tried to propose this (mostly for smime) by having
different prefixes for _encrypt or _sign, but this was not adopted.
Of course, one can deduce policy. If you get the key
fedora22(_at_)fedoraproject(_dot_)org from DNS you could expect that is the key
which we use to sign our packages. But that's not different from grabbing
a key from a random key server and assuming you can use it for email. the
assumption of what to do with the key really lies in the ID/email address
used for the key. So I do not think the openpgpkey draft changes that.
I do not find the idea of relying on the DNS for my keys remotely
comforting and would not want to rely on such a record directly.
You dont have to rely only on DNSSEC. You grab the key from DNS, and
then you can go out to other places (keyservers, your personal pubring,
etc) to attempt to gain enough trust in the key for your personal taste.
The DNS
has no persistence to it. Give me the MIT keyserver any day.
Let me generate another 1000 phb keys and upload those to the MIT
keyserver. What DNS does provide is that you don't have to look through
the chaf to find the wheat. You cannot add a bogus key for
paul(_at_)nohats(_dot_)ca into my DNSSEC zone. And importantly, if you control
part of my network, you cannot confuse me into believing there is no
such key published for paul(_at_)nohat(_dot_)ca. Compare this to the MIT key
server
that accepts requests on port 80 and can easilly be MITM'ed to filter
results.
What would interest me is if I could take a DNSSEC trust chain and intern
it in a blockchain. At that point the whole process becomes transparent and
I have a key I can place quite a bit of reliance on.
So turn your pubring.pgp into a blockchain? I don't see why it matters
that the keyblob came from MIT or DNSSEC. In fact, I can also argue
that the keyservers are worse because there is no sign that the key is
still actively supported/known by its user, while the fact that the key
is still in DNSSEC (or no longer in DNSSEC) gives me additional
information to make a decision on whether or not to use the key or
postpone my email until I know more.
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.
Agreed [*]
Paul
[*] speaking without my trans co-chair hat
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp