Openpgpkey revocation: If a client is 'openpgpkey unaware', they will be unaware of the latest OPENPGPKEYREVOC update. If they always check for the revocation, then they might as well be 'openpgpkey aware' and always refresh the key instead? Or am I missing a trick somewhere?
Stephen Nightingale. On 7/25/2014 1:22 PM, Petr Spacek wrote: > 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 > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
