Re: [ietf-provreg] Revision of 4310

[Andrew Sullivan <ajs@shinkuro.com>]

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