• It is a monumentally bad idea to retain revoked key material

 

+1, +2, +1000!

 

If you want a chain of trust, when you generate key “N+1” sign it with key “N”.  Repeat for each generation.

The problem with this is that you need to know *when* N signed N+1, and you can't believe N about the time.  (E.g. in 2020, I use key 2010 to sign key 2017 well after 2010 was revoked, at the same time I sign Fake2017, and lead a chain of trust through Fake2017 for future signings).   This problem is at the root of why a simple chain of trust won't work.  I'm trying to figure out a way to mix-in something to tie each transaction to a point in time (or at least an order in time) in a manner that possession of a key (revoked or not) earlier in the chain doesn't allow you to lie about what comes after.    I don't know that its possible to do that automatically.  It may require a human making a trust decision based on other non-DNS information.

[5011 works because each resolver updates its state as things happen, so twiddling with the signing chain a year or two after a key is revoked won't cause the resolver to update its state as the key is either not in trust anchor set, or is there in a revoked state.  Trying to replicate this behavior with a resolver that's been offline for two years just won't work].

 

• This is not a case where holding on to the past preserves the future.

 

Nice turn of phrase!

 

Thanks!

Mike