
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">

<style>

div.plaintext { white-space: normal; }

body { font-family: sans-serif; }

h1 { font-size: 1.4em; }

h2 { font-size: 1.2em; }

h3 { font-size: 1.1em; }

blockquote { margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777; }

blockquote blockquote { border-left-color: #999999; color: #999999; }

blockquote blockquote blockquote { border-left-color: #BBBBBB; color: #BBBBBB; }

blockquote a { color: #777777; }

blockquote blockquote a { color: #999999; }

blockquote blockquote blockquote a { color: #BBBBBB; }

@media (prefers-color-scheme: dark) { blockquote { border-left-color: #BBBBBB; color: #BBBBBB; }

blockquote blockquote { border-left-color: #999999; color: #999999; }

blockquote blockquote blockquote { border-left-color: #777777; color: #777777; }

blockquote a { color: #BBBBBB; }

blockquote blockquote a { color: #999999; }

blockquote blockquote blockquote a { color: #777777; }

}

math[display="inline"] > mrow { padding:5px; }

div.footnotes li p { margin: 0.2em 0; }

</style>

</head>

<body>

<div class="plaintext"><p dir="auto">On 3 Apr 2019, at 0:37, Geoff Huston wrote:</p>

<blockquote><p dir="auto">I’m uncomfortable with a “keep it indefinitely” position. I would prefer to see the community reach some rough consensus on a key chain structure  of new signing old that would allow a relying party that was configured with trust in some previous kSK to use a to-be-determined chain following tool that would allow it to trust the current KSK, or we conclude that this is a dud concept. At that point we should be destroying revoked KSKs. So perhaps we should give ourselves 24 months to either come up with something or conclude that its just not possible. At that point we can destroy KSK-2010.</p>

</blockquote><br><p dir="auto">Agree… </p>

<p dir="auto">Hold my beer… </p>

<p dir="auto">It occurs to me that the requirements are probably straight forward.</p>

<p dir="auto">Key N signs Key N+1 with a time of signature timestamp. Seems to me that writing down how the bits are stored is a short exercise.</p>

<p dir="auto">I do not see any reason to put an expiration date on the signature - since the signing key is revoked the signature is expired at the moment it is made. Any use of the chain of signatures during bootstrap is a big leap of fate anyhow - it be combined with a number of heuristics and used as a last resort mechanism in any case.</p>

<p dir="auto">Now, we do already have a chain of trust available, as long as we keep the old keysets and their signatures around (which we do, on those USB drives we copy around during the ceremony, not?). The only issue with those is that they carry a lot of extra baggage in the form of KSKs and expiration signatures. But if you want to you can construct a chain out of those.</p>

<p dir="auto">If you want to have a cruft-less chain of N->N+1 signatures then why not generate the signature with a time stamp. That seems pretty benign and doesn’t take years of engineering. </p>

<p dir="auto">Gimme that beer back so I can enjoy that tasty beverage, while I am being convince by all of you of the errors in my thinking.</p>

<p dir="auto">—Olaf</p>

<br><br></div>


</body>

</html>