To clarify the point I was attempting to make at the mic.
1) The draft is approaching IETF last call. People working on OpenPGP
should review it now.
2) If people find it does not meet OpenPGP needs, they should say so and
have no qualms about objecting. It is much more important that there be a
spec people use than that the document progress quickly.
If people want their drafts to progress quickly they should do that by
getting buy in from the community they purport to be serving.
3) It is quite possible that it is better that there be no DANE for PGP RFC
either at this stage or ever.
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. This was a task that really demanded a
high level of systems thinking if it is going to succeed. All such advice
was rejected.
People have been attempting to put email address related records into the
DNS since the first drafts of the spec and none has taken off.
It might well be that the best way to take advantage of the opportunities
DNSSEC affords would be to make changes at the OpenPGP end rather than the
DNS end.
I remain convinced that the interface between a DNS based PKI and any other
PKI should be approached as a cross-certification type activity and the
hand over between DNSSEC and whatever other PKI is to be used should be a
single 'certificate' (or key signing or whatever you want to call it).
So the way that I would approach using DNSSEC to validate a key for '
alice(_at_)example(_dot_)com' would be to introduce a record in the DNS with the
semantics 'X is authorized to sign for *@example.com'. I would not attempt
to fill the DNS with keys for Alice, Billybob, Carol, Doug, Ethelred and
co. It is not working for TLS and I don't think it will work for OpenPGP or
S/MIME.
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. The DNS
has no persistence to it. Give me the MIT keyserver any day.
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.
The above might sound a bit handwavy because it is. But I can demonstrate
the claims mathematically in terms of work factor. If the work factor for
introducing a bogus key is $100 at time t and we intern the key (and chain)
in a blockchain at time t, then the work factor becomes > $GDP(USA) after
time t.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp