Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt

[Mark.Andrews@isc.org]

> 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/>