[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
This sounds like a good section to add. I think it addresses the concerns
without calling for a spec change.
Scott
----- Original Message -----
From: "Olaf M. Kolkman" <olaf@ripe.net>
To: "Scott Rose" <scottr@antd.nist.gov>
Cc: <Mark.Andrews@isc.org>; <namedroppers@ops.ietf.org>
Sent: Thursday, December 19, 2002 10:04 AM
Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
>
>
>
> Does this text address both your concern? It uses SHOULD instead of MUST.
>
> <section title="Operational Guidelines">
>
> <t>
> By setting the KSK flag on a particular key, zone administrators
> indicate that that key SHOULD be used as the secure entry point for
> their zone. Therefore zone administrators SHOULD set the bit only for
> zone keys that are used to sign the KEY RR set only and are intended
> to act as the first link in the chain of trust for their zone. If KSK
> is set on any KEY in the apex KEY RR set, there SHOULD be other keys
> without KSK set to sign the rest of the zone's contents as key signing
> keys are restricted to only signing the KEY RR set.
> </t>
>
>
> --Olaf
>
>
>
> On Thu, 19 Dec 2002 09:30:33 -0500
> "Scott Rose" <scottr@antd.nist.gov> wrote:
>
> > I think we're in agreement here. The KSK is for the admin and signer
> > software and not for the resolver or server. The KSK has no protocol
value,
> > only some operational value to help differentiate it from any ZSKs in
the
> > zone.
> >
> > Though technically, a key with the KSK bit set could be used as a ZSK,
and
> > the only KEY in the zone. It is silly to do that, but for the protocol,
it
> > should be acceptable. I don't think there should be language in the
spec
> > saying that if a KEY RR has the KSK bit set, there MUST be another ZSK
in
> > the zone. It should only have a software/admin meaning, not a protocol
> > meaning.
> >
> > The main thing I am against is assigning a more stringent (i.e. RFC2119)
> > meaning to the bit.
> > Scott
> >
> >
> > ----- Original Message -----
> > From: <Mark.Andrews@isc.org>
> > To: "Scott Rose" <scottr@antd.nist.gov>
> > Cc: <namedroppers@ops.ietf.org>
> > Sent: Thursday, December 19, 2002 8:44 AM
> > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
> >
> >
> > >
> > > > If I remember the discussions that brought the KSK draft out: It
was
> > never
> > > > meant to be a protocol relevant bit, but a administrator/human
readable
> > bit.
> > > > The problem found during the workshops was the inability to
distinguish
> > > > between keys just by their fingerprint. So a bit was proposed to
> > signify
> > > > which KEY RR held the KEY signing key.
> > > >
> > > > A conscious decision was made to make this a "human readable only"
bit
> > in
> > > > the flags and not assign any protocol value to it. It would have
lead
> > to
> > > > more complexity for the resolver and the spec that is unnecessary.
Not
> > all
> > > > zones will have KEYs and KSKs and should not be made to have them.
A
> > > > resolver shouldn't care if the KSK bit is one and it is still used
to
> > sign
> > > > the zone.
> > > >
> > > > Scott
> > >
> > > The resolver doesn't care. The signer however does. Signing
> > > the entire zone with a KSK defeats the purpose of having a
> > > KSK. No one is saying that you have to have a KSK but if
> > > you have a KSK you need a ZSK (Zone Signing Key)
> > > key as well otherwise you have to sign the whole zone with
> > > a key that is tagged as KSK but is being used as a ZSK.
> > >
> > > You should be able to take a zone with multiple keys and
> > > just be able to sign it and have everything work. By that
> > > I mean KSKs sign just the KEY RRset. The ZSKs sign the
> > > entire zone including the KEY RRset. If you don't have
> > > a KSK then the zone just gets signed with ZSKs
> > >
> > > The KSK flag can also be used to seperate out the KSKs,
> > > if there are both types of keys, to send to the parent
> > > otherwise it defaults to all the keys. Note not all key
> > > may want to be sent at key rollover.
> > >
> > > The KSK flag is being used to identify a key that is being
> > > used to perform a certian role. Both humans and software
> > > need to look at the flag. While I can sign a zone with a
> > > non tagged KSK and a ZSK it's much easier and less error
> > > prone to just tag the key and let the software handle it.
> > >
> > > Mark
> > >
> > >
> > > > ----- Original Message -----
> > > > From: <Mark.Andrews@isc.org>
> > > > To: <namedroppers@ops.ietf.org>
> > > > Sent: Wednesday, December 18, 2002 10:51 PM
> > > > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
> > > >
> > > >
> > > > >
> > > > > There are multiple conflicting definitions of what a KSK is.
> > > > >
> > > > > With the DS record [5] the concept of key-signing and
zone-signing
> > > > > keys has been introduced. Key-signing keys are the keys that
sign
> > > > > the keyset only. In general, key-signing keys are the keys
that
> > are
> > > > > pointed to by DS records and are the first keys to be used when
> > > > > following a chain of trust into the zone. The key-signing keys
> > only
> > > > > sign the KEY RRset at the apex of a zone, zone- signing keys
sign
> > all
> > > > > other data in a zone. We propose a flag to distinguish the
key-
> > > > > signing key from other keys in the KEY RR set during DNSSEC
> > > > > operations.
> > > > >
> > > > > By setting the KSK flag on a particular key, zone
administrators
> > > > > indicate that that key SHOULD be used as the secure entry point
for
> > > > > their zone. Therefore zone administrators SHOULD set the bit
only
> > > > > for zone keys that are used to sign the KEY RRset and are
intended
> > to
> > > > > act as the first link in the chain of trust for their zone.
> > > > >
> > > > > The last sentence should be changed to:
> > > > >
> > > > > Therefore zone administrators SHOULD set the bit only
> > > > > for zone keys that are used to sign the KEY RRset only and are
> > intended
> > > > to
> > > > > act as the first link in the chain of trust for their zone.
> > > > >
> > > > > to bring the definitions into alignment.
> > > > >
> > > > > There should be a note that if KSK is set on a key that there
> > > > > MUST be other keys without KSK set to sign the rest of the zone's
> > > > > contents as KSK's are restricted to only signing the KEY RRset.
> > > > >
> > > > > Mark
> > > > > --
> > > > > Mark Andrews, Internet Software Consortium
> > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org
> > > > >
> > > > > --
> > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org
> > with
> > > > > the word 'unsubscribe' in a single line as the message text body.
> > > > > archive: <http://ops.ietf.org/lists/namedroppers/>
> > > >
> > > --
> > > Mark Andrews, Internet Software Consortium
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org
> >
> >
> > --
> > to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/namedroppers/>
> >
>
>
>
> --------------------------------------------| Olaf M. Kolkman
> | www.ripe.net/disi
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>