There would be *no* relationship between any DNSSEC signing chain, trust in the path, and the actual contents of the REVOKE, right?
I mean, a REVOKE is just an assertion by fiat. Its innately testable. How you find it is immaterial. That hasn't changed has it? -G On Fri, Jul 25, 2014 at 1:30 PM, Stephen Nightingale <[email protected]> wrote: > > 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 >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
