off-list was Re: [ietf-provreg] Revision of 4310

[Edward Lewis <Ed.Lewis@neustar.biz>]

I think this has veered off-topic for EPP. ;)

At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>>>  I don't think I understand this one.  Do you mean that there's no
>>>  RRSIG for that DNSKEY record?
>>
>>  To clarify - Yes.  In this instance, "in-active" would cover having a DS
>>  appear, the DNSKEY appear, but no RRSIG created by the private key.  That
>>  would make the DS "in-active" in terms of building a chain of trust.
>
>I like this idea better than just not putting the DNSKEY in the DNSKEY
>RRset.  Is anyone doing their deployment this way?
>
>On the other hand, I suppose it doesn't really matter whether one does
>it this way or by just not including the DNSKEY on the child side.  In
>either case, you have to use the old key until the TTL expires
>(because without an RRSIG, the new key won't be useful either).

If you are doing SEP=KSK and ZSK for all other keys, the best (IMO) 
thing to do is to add the SEP to the DNSKEY set and include the 
signature when you begin the process of changing.  After appropriate 
timing, add the new DS and remove the old DS (or swap in one atomic 
transaction).  After more appropriate time, revoke and later remove 
the old key.

We plan to always have an emergency key on-line.  So, add new key #3 
to the set of #1 and #2.  Later swap #1 with #2.  Eventually revoke 
#1.  One cycle later, add new key #4, swap #2 with #3, retire #2. 
And so on.  From add new key to remove there are three KSK 
signatures, two otherwise.  There is always just one DS record (per 
key algorithm and DS hash).

If one does not have a KSK/ZSK model, things will be different.  I 
haven't thought through that though.

>So why add the key to the DNSKEY RRset at all?

So the validator can get the key.  (If it weren't there, it's not 
going to be anywhere.)

Put the key at the parent...you're back to RFC 2065...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se