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

From: [email-masked]
Date: Tue, 18 Mar 2003 12:02:37 +1100

> On Monday 17 March 2003 12:32 pm, Olaf Kolkman wrote:
> 
> > 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.
> 
> I don't think I agree with this.
> 
> The reason why the KSK bit is a good idea is primarily that is has an on the 
> wire use.  Specifically, with the KSK bit, it is possible for the parent to 
> query the child in-band to determine from which key(s) DS records should be 
> calculated.  The fact that it can also be used by the signer to 
> automatically determine which keys are KSKs versus ZSKs might be a nice 
> thing, but IMHO not the real reason for the bit.
> 
> 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.
> 
> -- 
> David Blacka    <[email-masked]> 
> Sr. Engineer    Verisign Applied Research

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

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 09:41:16 -0800

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

>>>>> "David" == David Blacka <[email-masked]> writes:
    David> I don't think I agree with this.

  I don't agree that you don't agree!
  Your later text explains that you do.

  I claim you do agree. We (the humans) need to identify which is KSK and
which is ZSK. Sometimes humans will ask the computer to help them figure it
out, such as when the parent wants to know which key to download for offline
verification. It is also useful so that humans can more easily be told by
the tools, "I think that you made a mistake, add --I-really-mean-it if you
are sure".

]       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"); [