Re: [ietf-provreg] Revision of 4310

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Revision of 4310

Andrew,

You not saying  that the DS is active or not active, but that the associated DNSKEY in the child zone exists.  The term active is really misleading and certainly should not be used in this case.  Your proposing that the client tell the server whether they’ve published their DNSKEY for validation based on server policy?  I guess based on this something like childKeyActive is more appropriate since this is not an attribute of the DS.  I still have a concern about the interface that needs to be used to change the attribute ( secDNS:add and secDNS:rem the same DS or key with a new childKeyActive setting or using the secDNS:chg to replace all).  I don’t want to rework the interface to add this optional attribute, so will the existing interface work for this additional attribute?  

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: Andrew Sullivan <ajs@shinkuro.com>
Date: Tue, 26 Jan 2010 13:30:59 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 12:19:06PM -0500, James Gould wrote:

> Ok, so you¹re saying the difference is that the active flag only drives the
> server validation of the DNSKEY but the server would still publish
> it.

The idea that I had was that this was a way for the client to signal
to the parent what role the key is going to play, yes.  I don't
actually care what we call it, no.

> The
> term active and inactive is sort of misleading in this case.  An ³inactive²
> DS (or key) does not exclude the DS from being published in the zone, but
> simply removes the validation.

Maybe.  I figured the "active" meant "actively in use", and is
strictly speaking a property of the DNSKEY and not the DS.  The DS
happens to correspond to a DNSKEY that is in active use, or not.

A different name (with maybe a different meaning) is "published".
This one corresponds more exactly with the kind of use I'm thinking
of, because it tells the parent whether the DNSKEY appears in a public
zone.

> So why would the client ever ³activate² a DS, if the validation is
> being done as part of a server policy and the active flag controls
> the application of the policy?  The client would most likely want
> the server to do what they want and always set the flag to false.

Could be.  There's an advantage to the sponsor telling the repository
which keys are _supposed_ to be available, however, because that gives
the two parties responsible at the zone cut a mechanism for properly
co-ordinating their actions.  I haven't thought it through completely,
but it strikes me that this might also make life easier at domain
transfer time, also, because the target DNSKEY could be sent to the
parent and made available as a DS without actually being published.
(What bugs me about this is the potential for hijacking, so I'm not
yet convinced it's a good idea.)

> In either case would a better name of the attribute be ³validate²
> instead of ³active²?

Whatever we use, not "validate", please.  That word's already
meaningful in a DNSSEC context, and I don't want to overload it.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se