<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/2/2019 10:46 AM, Joe Abley wrote:<br>
</div>
<blockquote type="cite"
cite="mid:FDE0BAC4-75C9-4E62-BC2F-67AD95950250@hopcount.ca">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi Mike,<br class="">
<div><br class="">
<div class="">On 2 Apr 2019, at 09:33, Michael StJohns <<a
href="mailto:msj@nthpermutation.com" class=""
moz-do-not-send="true">msj@nthpermutation.com</a>> wrote:</div>
<div class=""><br class="Apple-interchange-newline">
</div>
<blockquote type="cite" class="">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> </div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">It is a <u class=""><b
class="">monumentally bad idea</b></u> to retain
revoked key material - especially when you don't
actually have any way to use it.</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>My concern is that we don't know if we have any way to use
it until KSK rollovers stop being science projects.</div>
</div>
</blockquote>
<p>Hoarding! I have no way of knowing if that necktie hanging on my
rack will ever come back into style, but it has a better chance of
being useful than your revoked key.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:FDE0BAC4-75C9-4E62-BC2F-67AD95950250@hopcount.ca">
<div>
<div><br class="">
</div>
<div>The topic that prompted the concern was Warren raising
Wouter's old trust anchor link proposal from the dead. I
thought Wouter's proposal was a bad idea, years ago and I'm
not sure whether Warren's current idea is best described as a
recurring bad dream or a prodigal son returning, but it seems
silly to rush to a conclusion when we don't need to.</div>
</div>
</blockquote>
<p>Hoarding! It's a bad idea mainly because of the way time works
and that the keys are not policy bound to sign things bound in
time. (e.g. I can't tell the difference between an object with a
timestamp of 1 jan 2010 signed on 1 jan 2010 and the same object
with the same time stamp signed in 2020). Because of that I can
use a revoked key to sign data that appears to have been signed
before the key was revoked.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:FDE0BAC4-75C9-4E62-BC2F-67AD95950250@hopcount.ca">
<div>
<div><br class="">
</div>
<div>What is the harm from keeping leaving the KSK-2010 smart
cards that are already in the safe there for as long as it
takes to have a stable plan in place for rolling the key? This
is not a rhetorical question -- you know more about this stuff
than I do, and I'm interested in your answer.</div>
</div>
</blockquote>
<p>As long as the cards are around, the keys are usable. If it were
a perfect 5011 world, then that would be less of a problem as
resolvers would mark them as revoked ore remove them from the
trust anchor set. If you read 5011 you'll note that there's a
housekeeping comment about removing information from the
trustanchor set after its no longer useful. E.g. why hang on to
the revoked key info for years on end when you know that the key
holders have destroyed the private key. What you say? They
didn't actually destroy the key?? <br>
</p>
<p>In an ideal world, those keys should be no more useful than any
randomly generated key pair - e.g. they exist in no DNS root
DNSKEY RRSet trust anchor set in any resolver in the world. But
5011 cannot (and no system can) result in perfect uptake by all
resolvers of the fact of the revocation of the keys and their
deletion from the trust anchor set for a given key - in this case
2010. Think of it this way - we think we've defused the bomb, but
it still contains explosives and can cause harm if mishandled.<br>
</p>
<p>At this point two things are true: 1) The 2010 key set still
exists, and 2) there is at least one resolver out there that will
still accept that key as a trust anchor. Deleting the key set
will make (2) a non-issue.</p>
<p>And given that there are humans involved, having yet another set
of key material that is nominally out of service but must be
protected at the same level of in-service key material increases
the risk to all key material some small amount. (i.e., you're
spreading your focus protecting things you really shouldn't have
to be watching)<br>
</p>
<blockquote type="cite"
cite="mid:FDE0BAC4-75C9-4E62-BC2F-67AD95950250@hopcount.ca">
<div>
<div><br class="">
</div>
<div>Note that I'm not suggesting that old key materials be
hoarded as a general principle; rather that since we don't yet
know what we are doing, perhaps we shouldn't act as though we
do.</div>
</div>
</blockquote>
<p>Let's say it takes you 6 months (being generous, I think it will
be a year or so) to figure out what to do and socialize it and
publish the RFC. Take another 6 months to get uptake from the
resolver vendors and operators to actually implement it. Take
another 6-12 months to get sufficient coverage in the sales
channel - call it 2 years for the sake of argument. At that point
I *really* hope that the 2017 key set has bit the dust and we're
on to 2019 or later. Given that we're concerned with the state of
the root trust anchor set, and as of today the publisher thinks
that 2010 is a dead key why would you include it in any
representation of the state of the set going forward from this
point? Answer - you wouldn't.<br>
</p>
<p>Problem for the reader: the original netscape browser contained
lots of keys in its trust anchor set. How many of those are still
in modern browsers, and do any browsers contain a history of the
supercession of those keys? Argue that it would be a good idea to
keep a history of those keys so that a browser that's been offline
for two years can get to the current trust set without updating
the software of the 1999 version of Netscape.</p>
<p>Later, Mike</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:FDE0BAC4-75C9-4E62-BC2F-67AD95950250@hopcount.ca">
<div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Joe</div>
<div><br class="">
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>