Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

JINMEI Tatuya / 神明達哉 <> Sat, 08 February 2014 19:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 134201A0203 for <>; Sat, 8 Feb 2014 11:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.481
X-Spam-Level: *
X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hCgh5aPXPSsy for <>; Sat, 8 Feb 2014 11:06:34 -0800 (PST)
Received: from ( [IPv6:2001:500:60::65]) by (Postfix) with ESMTP id E1EEE1A055C for <>; Sat, 8 Feb 2014 11:06:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2211A2383E2; Sat, 8 Feb 2014 19:06:22 +0000 (UTC) (envelope-from
Received: from (localhost []) by (Postfix) with ESMTP id F1D3A16004B; Sat, 8 Feb 2014 19:07:02 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id C419016004A; Sat, 8 Feb 2014 19:07:02 +0000 (UTC)
Date: Sat, 08 Feb 2014 11:06:20 -0800
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: Olafur Gudmundsson <>
In-Reply-To: <>
References: <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: dnsop <>
Subject: Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Feb 2014 19:06:35 -0000

At Fri, 7 Feb 2014 13:26:53 -0500,
Olafur Gudmundsson <> wrote:

> > In that, technically, an empty CDS / CDNSKEY RRset should mean the DS
> > RRset at the parent should be empty.  I have no problem with treating
> > an empty set as an exception, but I think it would help if the draft
> > explains that more explicitly.
> Semantics semantics,  
> No we are defining the semantics to be "IF C* is published parent DS should mirror that,
> if no C* in child --> parent has no action to perform" 

Yes, I now understand that.  Please see my latest response to Warren;
I still think it helps to clarify that explicitly.

> > I'd also note that "absence of CDS" (or CDNSKEY) cannot happen once
> > one such RR is published, and it should mean something erroneous (most
> > likely an operation error at the child or a bug in its tool).  I think
> > it's worth noting in Section 4.1
> Why?
> Here is a perfectly fine time line
> <At start parent DS reflects key A and child uses A to sign DNSKEY RRset> 
> Child publishes CDS with A and B 
> Parent updates DS to reflect A and B 
> Child deletes CDS   

Right, I was still a bit confused here.  Now I understand it, but I
also wonder why would the child deletes the CDS's (again, please see
my latest response to Warren).

> Do you think it is helpful to add an appendix with some examples of use of C* records ? 

Yes, I think so (I don't think I wouldn't need the example myself now
that I understand it, but I guess it helps other fresh readers:-).

> > Finally, I'd suggest explicitly clarifying that CDS / CDNSKEY cannot
> > be used for a child from signed to unsigned (since it would have to
> > remove all CDS / CDNSKEY records to do so).  And, I suspect this is a
> > "MUST NOT", unlike the case of initial enrollment described in Section
> > 9, because this would break interoperability.
> > 
> In theory we can use C* to perform the Going-Unsigned operation, and earlier version of this
> document proposed that, but people objected and we removed that text. 
> We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. 

That's fine.  I just tried to point out that (even if allowed)
"removing all *Cs as a signal of signed->unsigned" and the "no change
if no *Cs rule" can't coexist.

JINMEI, Tatuya