Hello,
On 23.7.2014 23:34, Frederico A C Neves wrote:
Dear Colleagues,
Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC6895.
This message starts a 2 weeks period for an expert review of the DNS
RRTYPE parameter allocation for OPENPGPKEY specified at:
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2
I was asking dane-list [1] if it makes sense to publish PGP key revocation
certificate in OPENPGPKEY. I haven't heard any reply to this idea yet (maybe
it is too dumb idea to warrant single reply).
There is one important detail to note:
- OPENPGPKEY as proposed requires DNSSEC protection (it is public key).
- Key revocation certificate doesn't require DNSSEC because the certificate
itself is signed.
I think it is worth considering support for key revocation certificates in DNS
because they can be deployed even more easily and rapidly (because DNSSEC is
not required).
The question is if it makes sense to publish both types of data using:
- Different RR type (a la OPENPGPREVOC)
- The same RR type but under different _prefix (_revoc._openpgpkey?)
- Under the same owner name and RR type, which would (I guess) require an
additional field in OPENPGPKEY RR type
Mixing keys and revocation data in single RR set will obviously result in
bigger replies. The question is if client should verify always verify that the
other keys of the same user were not revoked so it could make sense to send
him all the data in one response. (The older key could be obtained via non-DNS
means etc.)
On the other hand, "_openpgpkey aware" clients could always check live data in
DNS and use only keys which are present in DNS at the moment. In that case
removing RR which represents particular key will have the same affect as key
revocation (but only for "_openpgpkey aware" clients).
Unfortunately I will not be available for next two weeks so I'm throwing the
idea to mailing list without any promise to reply before 2014-08-11.
[1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html
--
Petr Spacek @ Red Hat
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
