Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

From: Petr Spacek <[email-masked]>
Date: Fri, 25 Jul 2014 19:22:06 +0200

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

---

From: Stephen Nightingale <[email-masked]>
Date: Fri, 25 Jul 2014 13:30:51 -0400

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:
> 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).
> 
> - 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).
> 
> - 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.
>

---

From: George Michaelson <[email-masked]>
Date: Fri, 25 Jul 2014 13:33:19 -0400

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-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: James Cloos <[email-masked]>
Date: Fri, 25 Jul 2014 16:12:20 -0400

>>>>> "PS" == Petr Spacek <[email-masked]> writes:

PS> I was asking dane-list [1] if it makes sense to publish PGP key
PS> revocation certificate in OPENPGPKEY. I haven't heard any reply to
PS> this idea yet (maybe it is too dumb idea to warrant single reply).

I must have missed that last paragraph when I replied to the other part
of that mail.

If one is to publish openpgp keys in dns, then also publishing related
revocation certs seems reasonable.

If the querier already has a path through the WoT to the revoked key, a
revocation signed by that key indeed does not need a dnssec trust path,
too.  But if the querier does not have a WoT path, they would benefit
from the dnssec path.

So as you wrote a signed revocation is useful even w/o dnssec, but
dnssec does benefit some.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Derek Atkins <[email-masked]>
Date: Fri, 25 Jul 2014 14:10:56 -0400

Petr Spacek <[email-masked]> writes:

> revocation certificate in OPENPGPKEY. I haven't heard any reply to
> this idea yet (maybe it is too dumb idea to warrant single reply).
>

Note that this public key could still (theoretically) be signed.  Unless
DANE is specifying it differently there should be no limitation that it
be *just* the public key.

> certificate itself is signed.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: James Cloos <[email-masked]>
Date: Sun, 27 Jul 2014 18:23:11 -0400

>>>>> "DA" == Derek Atkins <[email-masked]> writes:

DA> Note that this public key could still (theoretically) be signed.  Unless
DA> DANE is specifying it differently there should be no limitation that it
DA> be *just* the public key.

That is an important point; unsigned OPENPGPKEY provides similar
benefits as using the key servers.

Part of the motivation for OPENPGPKEY was to provide an additional trust
path to the dnssec root for those who lack a existing or sufficient path
through the WoT.

(I think everyone agrees that a nice path through the WoT to a key with
ultimate trust is better, but if you WoT path is weak or non-extant than
dns can at least provide /some/ trust.)

Another aspect of the motivation is to have similar discovery paths for
openpgp and smime -- where a dns trust path is arguably more useful.

-JimC