On 4/2/2019 11:53 AM, Salz, Rich wrote:
* 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