[Opendnssec-develop] KSK vs ZSK
Roy Arends
roy at nominet.org.uk
Thu Mar 5 17:00:51 UTC 2009
John Dickinson <jadsab at googlemail.com> wrote on 03/05/2009 05:41:13 PM:
> On 5 Mar 2009, at 13:54, Roy Arends wrote:
>
> > Matthijs Mekking wrote on 03/05/2009 02:38:33 PM:
> >
> > > The discussion continued at our office.
> > > RFC 4641 says the ZSK should sign all the RRsets.
> > > For the sake of OpenDNSSEC, perhaps we should add an attribute to
> > keys
> > > called 'sign-what' or something, that can have the following values:
> >
> > Okay, lets ignore the terminology SEP/KSK/ZSK for now.
> >
> > > - sign nothing
> > > - sign all
> > > - sign all but keyset
> > > - sign only keyset.
> > >
> > > Makes sense?
> >
> > Yes it does. We need to have a set of keys, that when combined,
> > signs everything in the zone (the keys need to complement each
> > other), and also note that overlap is not an issue.
> >
> > I can think of a variety of 'ranges' for a key:
> >
> > DNSSEC signing, three bits:
> >
> > sign keyset: 001
> > sign data: 010
> > sign NSEC/3: 100
> >
> > So, a key with range 7 would sign everything (similarly like a ZSK),
> > and a key with range 1 would be a KSK.
> >
> > All the keys that are currently in use, must have a combined range
> > of "7"
> >
> > I can also see seperate DNSKEY uses, for instance signatures over
> > SSHFP's or over CERT records, which would automatically get a range
> > of 0, and an associated range.
> >
>
> Do we really need all this complexity? What is wrong with
>
> KSK = SEP = Sign only DNSKEY RRSet.
> ZSK = !SEP = Sign all RRSets.
>
> This might be boring but it causes no surprises and is as people
> expect when they read the Pro DNS and BIND book or the dnssec-keygen/
> signzone man pages. One of the aims of OpenDNSSEC is to make DNSSEC
> simple.
There is nothing wrong with the assumption that KSK=SEP=Sign DNSKEY, and
ZSK=!SEP=Sign All. That can be taken care of in the presentation layer,
right? The gui, the default settings, etc.
However, with an increasing flexible and dynamic name-service environment,
while we might see new applicability of DNSSEC to specific needs, why not
provision for that. Is it really so much more? Is it really so complex?
Mind you, we're not actually presenting this flexibility and complexity
to the end user, but we could take it into account now.
To converge, why not have the KSK functionality have a value of "1" and
the ZSK functionality a value of "7". Leave the rest undefined, ffu, or
what not.
Regards,
Roy Arends
Sr. Researcher
Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090305/1c07e483/attachment.htm>
More information about the Opendnssec-develop
mailing list