[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>