[ksk-rollover] alternatives to 5110 for automating roll-over

[Michael Richardson]

Lars-Johan Liman <liman at netnod.se> wrote:
    ebersman> It is not the IETF's job to tell large ISP that they must do
    ebersman> 5011. We need to consider that the world will never be all 5011
    ebersman> and that alternate automation methods are valid and how we'd
    ebersman> address that in an emergency.

    mcr> I don't really understand the long-term reasons for not doing 5011.
    mcr> Can you explain this further?

    > list-ksk-rollover at dragon.net:
    >> Phased rollout and control of when things change.

    > Aye.

    > I agree that we shouldn't prescribe how people automate, or even that
    > they do it at all. 5011 is _one_ way to do it, and I happen to like it,
    > but that doesn't mean that it is good for $everybody.

In particular, it fails when the device is not on/connected during the period 
that the 5011 adds the new key, then it can not use 5011.  
I think that an alternative to straight 5011 is needed.

As far as I understand 5011, the only reason we can't leave the entire chain
of keys in at the trust point is because the RRset would get unreasonably
large, causing other failures.

It seems that the problem is solved if the history of the DNSkey can be
placed at some other place.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190329/a4fdddf9/signature.asc>