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

From: Roy Arends <[email-masked]>
Date: Mon, 17 Mar 2003 20:14:37 +0100 (CET)

On Mon, 17 Mar 2003, Olaf Kolkman wrote:

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

Just curious, but why not use the key with KSK bit = 0 ? Or maybe the
signer can use the set of private keys available online in case of dynupd
? (I assume hygiene insists private ksk and the private zsk are not in the
same room). Also, imho a ZSK is a subset of the KEY RRset, which in itself
is a subset of zone data. The ZSK bit does the trick of making the KEY
distinct from other keys in the apex RRset. The distinction is that the
KSK is typically used for authentication of other keys.

Anykey, just mey .02 euros.

Roy

--
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: David Blacka <[email-masked]>
Date: Mon, 17 Mar 2003 19:27:07 -0500

On Monday 17 March 2003 12:32 pm, Olaf Kolkman wrote:

> 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