Subject: [DNSOP] regarding dnssec-key-timing RFC 7583

From: shabbir ali <[email-masked]>
Date: Mon, 10 Sep 2018 23:56:00 +0500

Hi all,
My question is that instead of messing with the DNSSEC key Rollover timing
and all that manual and automation tools dependencies, why not simply use a
key revocation list just like a certificate revocation list (CRL) ?

---

From: Michael StJohns <[email-masked]>
Date: Mon, 10 Sep 2018 16:07:01 -0400

Generally, CRLs work reasonably well for revoking intermediate CAs and 
leaf certificates, not so well for dealing with trust anchors.   CRLs 
work by the parent signing the revocation (and by being able to re-issue 
new certificates). Root certs/trust anchors by definition do not have 
parents.

There's a lot more - but that's the gist of the issue.

Mike

On 9/10/2018 2:56 PM, shabbir ali wrote:
> Hi all,
> My question is that instead of messing with the DNSSEC key Rollover 
> timing and all that manual and automation tools dependencies,**why not 
> simply use a key revocation list just like a certificate revocation 
> list (CRL) ?
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 06:21:11 +1000

Firstly you can’t avoid dealing with time if you want validators to always successfully validate answers from a signed zone as there are coaches involved and the DNS is loosely coherent.   The DNS isn’t HTTPS, you aren’t always directly dealing with the authoritative server or a proxy like you are with HTTPS.

Secondly we already effectively have a crl at the DNSKEY name if you set the revoke bit.

Mark
-- 
Mark Andrews

> On 11 Sep 2018, at 04:56, shabbir ali <[email-masked]> wrote:
> 
> Hi all,
> My question is that instead of messing with the DNSSEC key Rollover timing and all that manual and automation tools dependencies, why not simply use a key revocation list just like a certificate revocation list (CRL) ?