Subject: DNSEXT WGLC: Key-Signing Key (KSK) Flag

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 12 Mar 2003 22:59:30 -0500

This starts a 2 week Working Group last call on this document,
concluding on March 28'th 2003.

This document defines a new KEY RR flag that is used to identify keys that
are used to sign KEY RRset. The flag is not used by the DNSSEC resolution
process. The main purpose of this flag is to ease administration of DNSSEC
signed zones.

This document is on standards track and is available via following URL:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt

Silence on this document during the last call will interpreted by chairs
as instruction to drop this document.

	Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 17 Mar 2003 18:32:27 +0100

In response to

 * > This starts a 2 week Working Group last call on this document,
 * > concluding on March 28'th 2003.

 [email-masked] writes:

 * 	As currently specified this is going to result in operational
 * 	problems.
 * 
 * 	We really need to specify key functionality at key creation time.
 * 	This way signer and DS key generation can be well defined.
 * 	
 * 	I propose two bits (...)

In somewhat more detail:

Based on experiences during the recent workshop we came to the
conclusion that a signer (either the off-line or the on-line, in the
case of dynamically updated signer) needs to know which key is to be
used for signing the zone data. This can be done by using a second
bit.

With this bit and some definition on the behaviour of the signer based
on the settings of the bit signers can do their work automatically.

The behaviour of the signers given the states of the bit needs to be
clearly specified.

 KSK  ZSK
  0    0       Signers treat this as an undefined state.
  1    0       The Key is used to sign the apex key set only.
  0    1       The Key is used to sign all zone date except the apex key set.
  1    1       The Key is used to sign all zone and apex key data.

As in the current version of the draft the bit provide operational
hints and MUST not be used in resolving and verification.

If during the working group meeting on Tuesday supports this idea I'd
like to modify the draft to incorporate these ideas and push a new
version in order 1-2 weeks.

---

From: David Blacka <[email-masked]>
Date: Tue, 18 Mar 2003 00:09:08 -0500

On Monday 17 March 2003 08:02 pm, [email-masked] wrote:

> > I agree that both humans and zone signing tools should be crystal clear 
> > about which keys are KSKs, ZSKs or both.  But this can be done locally 
(for 
> > instance, by adding this information to the key file names).  I cannot 
> > think of a wire use for the ZSK bit.

> 	Remote debugging.  If the intent of the key is clear/visble
> 	this is relatively easy.

Remote debugging of what, exactly?

Trying to figure out what the zone signing key is has never been an issue in 
any of the workshops that I've attended, AFAIK.  Trying to figure out which 
key is the secure entry point HAS been an issue.
-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 10:52:24 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "David" == David Blacka <[email-masked]> writes:

    >> Remote debugging.  If the intent of the key is clear/visble

    David> Remote debugging of what, exactly?

    David> Trying to figure out what the zone signing key is has never been
    David> an issue in any of the workshops that I've attended, AFAIK.

  Have multiple keys been tested prior to last week?
  Certainly we did get the wrong keys sent to the parent. If we couldn't
talk across the table, then we would have had a problem debugging.

  So, I want those bits there - they are for the CPU in my head?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Mar 2003 22:50:03 +0000

> Have multiple keys been tested prior to last week?

yes.

> So, I want those bits there - they are for the CPU in my head?

i'm withdrawing my prior support for the KSK draft.  KSK vs ZSK should
either be two distinct RR types (possibly as part of a type code roll)
or the "key type" bit (KSK vs ZSK) should be used by validators.  this
is because of Orr's principle (data which is not used will be wrong)
and also because key management techniques such as rollover or parent
signing of child zone keys or DS RR generation and insertion are not
really practical as "operational sugar" and ought to be specified in
the basic protocol.

this does not bear on johani's "threshold validation", since there can
still be more than one key of any type (KSK vs ZSK) which needs more
than one key.