On Tue, Oct 17, 2000 at 05:02:44PM +0200, Ted Lindgreen wrote:
> > How about this?
> >
> > 1) Child sends keys to parent
> > 2) Parent signs keys of child
> > 3) Parent sends results of signing to child
> > 4) The child verifies the result and tells parent
> > 5) If okay, parent publishes, else start over
>
> OK, I like it, and it does solve the mr. Badguy leak also.
> It means that our informational message gets replaced with
> a real message that must be ACKed. We will try to see
> how this fits in.
It is important to note that there is a difference between:
1) a scheduled key renewal request from the child
2) the first key for a child
3) a child's (private) key compromise
1)
The child _has_ a valid key, so it can sign its request with
that key. Nothing difficult has to be done here.
2)
The most difficult step. The five steps above seem to solve most
of the problems here.
3)
This looks most like its first KEY, as the old key cannot
be trusted anymore. But now there may be extreme timepresure,
especially if this is child has again many children (like a large
TLD), or is dealing with high volume creditcard transactions.
grtz Miek
