Re: Fwd: I-D ACTION:draft-ietf-dnsext-delegation-signer-00.txt

[Olafur Gudmundsson <ogud@ogud.com>]

At 05:25 AM 6/12/2001, Olaf Kolkman wrote:

>  Olafur Gudmundsson <ogud@ogud.com> writes:
>  *
>  * Just in case anyone did not see this one, here are my .02 SKR solution to
>  * the problem of keysets at apex.
>  * Please read and comment as I would like do figure out real soon
>  * if this is better or worse than Sigs at parent.
>
>
>Hi Olafur,
>
>I have a small question:
>
>In the abstract you write:
>  "...
>   proposes to store a different record in the parent that specifies
>   which one of the child's keys can sign the child's KEY set.
>   ..."
>
>
>This seems a little restrictive. Can't the Child's key, as pointed to
>by the DK record, be used to sign the other child data as well? Why
>only child's KEY's ?

I read this differently, which means this needs to be clarified.
which one of the child's keys can" to means that keys are allowed to
sing the keys set and does not imply anything about signing other data.
But if you can read into this that this outlaws signing other data
I must update this. Text welcome.


>Only in the abstract you explicitly mention this and you refer to this
>scheme when talking about regular key roll overs so I wonder if the
>'restriction' is intentional and if so why?
>
>Can you clarify?

I was trying to point out that if one key is only used to sign the key set
that key can be strong and live for a long time, thus minimizes the
burden on the parent. What you are reading as a restriction was indented
to be a good practice suggestion.

The ONLY restriction that I wanted to put in place was what keys from the
apex key set can sign the apex key set.

I'm going to be updating the draft so any text that you find unclear, 
confusing bad etc. please point it out to me for fixing.

         Olafur