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

["Scott Rose" <scottr@antd.nist.gov>]

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

Correct, but if the admin is stupid enough to sign a zone with a KSK, and
not include a zone key (ie. the zone key has the KSK bit set).  The admin
shouldn't be punished.

After the signer is done - the KSK bit loses all meaning.  The resolver,
verifier and servers should not assigning any specially meaning to the KSK
on a KEY RR.

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

Correct again.  This bit is signer-meaningful only.

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

Scott


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