[dns-operations] .Org DNSSEC key management policy feedback
marka at isc.org
Tue Jun 23 00:22:31 UTC 2009
In message <20090623000026.GB13468 at vacation.karoshi.com.>, bmanning at vacation.ka
> > > I remember the main counter argument was that folks might want to
> > > configure the .ORG key for everything in and under .ORG, and not trust
> > > the root key for .ORG, but do trust the root key for everything else.
> > > Doesn't fly. There might be simple dependencies from domains under ORG
> > > on something not ORG. See for instance http://www.links.org/?p=635 on
> > > "who pwns the internet".
> > For . and ORG I agree. For ORG and ISC.ORG I disagree.
> > For wattle.id.au (when it is signed) and andrews.wattlet.id.au
> > I disagree. There are couple of hundred zones where your
> > policy makes sense. There are millions where named's default
> > policy will make sense.
> > Your policy model make sense if you *start* doing DNSSEC
> > during the bottom up development phase. If you start in
> > the top down phase it doesn't and top down is the long term
> > status.
> > Mark
> > > kind regards,
> > >
> > > Roy
> i think i have to side w/ Roy here. the nominal policy model is
> that I trust those w/ whom i have a direct business relationship.
> while ISC.ORG may not have any given policy about the use of the
> crypto it has by its employees (for IPSEC/VPN and perhaps SIDR &
> DNS validation) many other enterprises/entities do have such policies
> and insist on their employees/contractors use those tokens as a conditi
> of employment.
> Since very few actually have such a relationship with the root, I'd pos
> that the root key is the least trusted key of the bunch. Its the backs
> when all other trust paths are exausted.
> ymmv of course.
Actually you sided with me. As a employee you *only* use the
keys the employer gives you. You don't trust other paths.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations