Re: OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

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

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext