[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
> At 0:44 +1100 12/20/02, Mark.Andrews@isc.org wrote:
> > 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.
>
> Agggh NO!!!
> Agggh NO!!!
> Agggh NO!!!
>
> (But I say it with love.)
>
> In the verifier, the bit must be ignored.
>
> In the signer, the bit must only be used to prepare the key for
> exposure to the parent for DS RR processing. (Note: I do not mean
> the signer must use the bit to prepare the key for sending to the
> parent. I mean that the signer, if the implementation chooses to do
> so at all, must *only* use the bit for that purpose.)
>
> In the key generator, the bit can be set.
>
> In "whatever-generates the DS RR from the KEY RR" may read the bit to
> determine that this is a key for which a DS is desired.
>
> As for why "Agggh NO!!": what if the child zone has just one key?
> That key is both the KSK (needs DS) and ZSK.
Then you don't set KSK in the first place or you tell the
signer to ignore the KSK and use the key to sign all the
data sets.
A KSK key is by definition a KEY that *only* signs the zone
key.
There is no benefit in a KSK if a KSK signs the entire zone.
> Another reason to not do this: Please don't repeat the mistake of the
> A/C bits of the 2535 flags field - the "authentication prohibited"
> and "confidentiality prohibited" goof ups.
This a flag to tell the signer what to do. It is NOT
enforced by the resolver.
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-703-227-9854
> ARIN Research Engineer
>
--
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/>