Subject: Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

From: Joe Abley <[email-masked]>
Date: Fri, 1 Oct 2010 10:38:37 +0000

On 2010-10-01, at 06:58, Tony Finch wrote:

> What is the purpose of the historical information in the XML TA file?

Debugging, context, historical record.

Joe

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Oct 2010 19:59:58 +0100

> Debugging, context, historical record.

Right, so it's aimed at human consumption rather than automatic tools?

How much do you intend automated tools to use the trust anchor publication
web site? And which of the files that are published there?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 3 Oct 2010 09:23:55 +0200

On 30 sep 2010, at 18.51, Stephan Lagerholm wrote:

> It is not clear if the validUntil time is referring to the time when the
> key is expected to be rolled into RFC 5011 revoked state or when it is
> expected to be removed from the zone.

Once the key is revoked, it is no longer valid and cannot be used for validation. Given this, I'd say validUntil specifies how long the key is valid for validation - once the revoke bit is flipped, it is no longer valid.

> What will happen with the keytag field in the published data for an
> historical key that has been revoked? Will it still have the original
> keyid or keyid+128?

For the anchor XML I'd expect the keytag field to stay unchanged.

> Does it make sense to add an additional timer in the published data so
> that the revoked state can be described better?

I don't think this - the anchor XML works quite well without RFC5011, if you a) parse the dates and b) fetch the anchor XML often enough.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 3 Oct 2010 09:27:44 +0200

> Right, so it's aimed at human consumption rather than automatic tools?

Given the historical information (together with old DNSKEY), you could build a trust anchor history zone.

> web site? And which of the files that are published there?

I know of at least one vendor that has started to implement support to base trust anchor fallback on the information in the TA repository. As soon as their code and ideas are mature enough, I hope they'll share their thoughts.

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Tony Finch <[email-masked]>
Date: Sun, 3 Oct 2010 12:59:14 +0100

> Given the historical information (together with old DNSKEY), you could build a trust anchor history zone.

Not really, since you need the private key of the old TA to sign the public key of the new one to get a cryptographic proof of the history. Without that it is just a third party attestation, which is rather weaker.

You can get a proof of the history by archiving the root DNSKEY and associated RRSIG RRsets, but that includes a lot of irrelevant noise from ZSK rollovers and signature refreshes.

> I know of at least one vendor that has started to implement support to base trust anchor fallback on the information in the TA repository. As soon as their code and ideas are mature enough, I hope…

Sounds good.

I should have asked more clearly whether you expect end-user devices to use the IANA publication site directly or whether vendors should re-publish it for their purposes.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Sun, 3 Oct 2010 11:54:31 -0400

> Not really, since you need the private key of the old TA to sign the public key of the new one to get a cryptographic proof of the history. Without that it is just a third party attestation, which…

As has been expressed many times, old keys are not trustworthy and hence their signatures have no value.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Oct 2010 09:32:37 -0700

Why?

Ekr

On Oct 3, 2010, at 8:54, Joe Abley <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Sun, 3 Oct 2010 13:18:01 -0400

> Why?

Are you asking because you've reviewed those discussions and have issues with them, or because you didn't review those discussions?

I'm not entirely sure the answer shouldn't be "because we manage the keys, and we say so" actually.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Oct 2010 10:31:02 -0700

On Sun, Oct 3, 2010 at 10:18 AM, Joe Abley <[email-masked]> wrote:

> Are you asking because you've reviewed those discussions and have issues
> with them, or because you didn't review those discussions?
>

I'm asking because I'm pretty familiar with cryptography and I know that
keys don't suddenly become
worthless just because they get past their intended use lifetime. The
semantics of signature
security of old keys is a lot more complicated than that.

If there's some particular discussion that you'd like me to review that
makes the case that
this is different, please point me at it.

> I'm not entirely sure the answer shouldn't be "because we manage the keys,

If that's the answer, then I most certainly do not agree.

-Ekr

---

From: Joe Abley <[email-masked]>
Date: Sun, 3 Oct 2010 13:54:03 -0400

On 2010-10-03, at 13:31, Eric Rescorla wrote:

> I'm asking because I'm pretty familiar with cryptography and I know that keys don't suddenly become
> worthless just because they get past their intended use lifetime. The semantics of signature

The context here is the publication of DNSSEC trust anchors for the root zone.

At least some of the cases we're talking about involve signatures necessarily made by keys after an emergency key roll which has taken place because the old key has been compromised. Such signatures are worthless. In the general case we must assume that there will exist a point in the future at which at least one prior key roll has been due to a key compromise, and hence we can expect that an unbroken chain of trust that involves outgoing keys signing incoming keys will not always be available.

If we consider the more usual case to be one where a key was rolled for reasons other than a compromise, then a signature made by the outgoing key is useful so long as the security of the outgoing key is maintained. Since the procedures followed to effect a scheduled key roll would involve the destruction of the outgoing private key, we would hope that this was not an issue. As a matter of operational pragmatism, however, I have argued that a system that relies upon the absolute, secure destruction of all prior keys is more fragile than one that does not.

> If there's some particular discussion that you'd like me to review that makes the case that

The conversations were all on this list, relating to the trust-history proposal. The paragraphs above are my attempt at a summary of the concerns I raised at the time.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Oct 2010 07:31:31 -0700

On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley <[email-masked]> wrote:

> At least some of the cases we're talking about involve signatures
> necessarily made by keys after an emergency key roll which has taken place
> because the old key has been compromised. Such signatures are worthless.

I don't think this follows.

It's pretty commonly suggested that at the time you roll out key K_n you
also *immediately* generate
key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all
that is required for security
is that the signature itself take place prior to the compromise of K_n this
allows for rollover even
if K_n is subsequently compromised, provided that the relying party can
verify that the signature
on K_{n+1} was computed before the compromise date. There are a variety of
techniques for
doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Oct 2010 07:52:49 -0700

At 7:31 AM -0700 10/4/10, Eric Rescorla wrote:
>On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley <<mailto:[email-masked]>[email-masked]> wrote:
>
>
>At least some of the cases we're talking about involve signatures necessarily made by keys after an emergency key roll which has taken place because the old key has been compromised. Such signatures are worthless.
>
>
>It's pretty commonly suggested that at the time you roll out key K_n you also *immediately* generate
>key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all that is required for security
>is that the signature itself take place prior to the compromise of K_n this allows for rollover even
>if K_n is subsequently compromised, provided that the relying party can verify that the signature
>on K_{n+1} was computed before the compromise date. There are a variety of techniques for

Does the "create your next key immediately" process work with HSMs if you don't have 2x the number you would normally have in production? I'm no fan of HSMs for a system like DNSSE that often needs operational agility, but it seems like I'm in the minority here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 10:56:12 -0400

Hi,

> I don't think this follows.

In the context of our discussion, it does. We are discussing arrangements for publishing a trust anchor for a key whose management has already been carefully specified, and does not include (for example) pre-generation of the next key in the way you suggest.

I think it's perfectly valid to discuss the management of the root zone KSK, ideally with careful reference to the DPS that ICANN published. However, that's not what we're talking about here.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Oct 2010 08:02:46 -0700

I think it would depend on the HSMs. In at least some of them, it's the card
keys that are important and you could have a disjoint set of card keys for
K_{n+1}

-Ekr

On Mon, Oct 4, 2010 at 7:52 AM, Paul Hoffman <[email-masked]> wrote:

> Does the "create your next key immediately" process work with HSMs if you
> don't have 2x the number you would normally have in production? I'm no fan
> of HSMs for a system like DNSSE that often needs operational agility, but it
> seems like I'm in the minority here.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Oct 2010 08:11:10 -0700

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley <[email-masked]> wrote:

> In the context of our discussion, it does. We are discussing arrangements
> for publishing a trust anchor for a key whose management has already been
> carefully specified, and does not include (for example) pre-generation of
> the next key in the way you suggest.
>

Carefully specified, perhaps, but what you're saying here also makes me
think it was
also incorrectly specified, since, as I said, the technique I described is
well-known,
and failing to do so leads to precisely the complications that are at issue
here.

So, rather than designing a bunch of kludgy workarounds, it would be better
to ask
what the right thing to do is, even if that requires changing some
preexisting
document.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Oct 2010 08:12:25 -0700

-Ekr

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 11:14:20 -0400

On 2010-10-04, at 11:11, Eric Rescorla wrote:

> Carefully specified, perhaps, but what you're saying here also makes me think it was 
> also incorrectly specified, since, as I said, the technique I described is well-known, 
> and failing to do so leads to precisely the complications that are at issue here.

Regardless of what you think of it, what we have is what we have. Specifying a trust anchor publication strategy that works with something different seems a little pointless.

> So, rather than designing a bunch of kludgy workarounds, it would be better to ask
> what the right thing to do is, even if that requires changing some preexisting
> document.

Workarounds to what?

I have not heard a clear description of a problem yet, just a lot of possible solutions.

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 16:18:19 +0100

On Sun, 3 Oct 2010, Joe Abley wrote:
> necessarily made by keys after an emergency key roll which has taken
> place because the old key has been compromised. Such signatures are
> worthless.

This argument also implies that RFC 5011 cannot be used to roll over root
trust anchors in the event of a compromise.

It isn't immediately clear to me from the root KSK DPS whether you expect
RFC 5011 to work in the event of a compromise. It says:

   As part of the KSK emergency roll-over procedures, ICANN maintains
   the capability of being able to generate and publish an interim Trust
   Anchor within 48 hours.  In favorable circumstances, this interim
   Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011]
   automatic KSK roll-over to a new and sanctioned Trust Anchor
   generated at a new scheduled key ceremony held with reasonable time
   notice.

Does that mean you'll use 5011 to roll from the interim TA to the
sanctioned TA, but that validator operators will have to manually install
the interim TA?

There seems to be a significant difference between 5011 and the root TA
operational plan. 5011 suggests there should be a backup TA key pair which
is generated and published well in advance, but not used operationally. It
just exists to be ready in case of loss or compromise of the operational
TA. The root TA has no such backup.

Sorry for being so late to look at these documents in detail.

Tony.

---

From: [email-masked]
Date: Mon, 4 Oct 2010 15:24:51 +0000

> Regardless of what you think of it, what we have is what we have. Specifying a trust anchor publication strategy that works with something different seems a little pointless.

	i think the correct point is, this work documents what _was_ done, eg. a historical
	fact.  It also lays out what the authors think is best practice, given the current
	constraints.

	Its kind of tough to argue w/ someones beliefs.
	Facts - yes, beliefs - not so much.
	If there are factual errors in what occured, those can and should be
	corrected.

> I have not heard a clear description of a problem yet, just a lot of possible solutions.

	And yet, you were part of a team that spent hundreds of thousands of dollars
	and several man-years working on a solution to a, as you state above, to a
	problem without a clear statement?

	I'd susggest that there might be better ways to do key management and that EKR 
	might have some good ideas on the subject.  But thats _future_ work.

--bill

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 11:32:05 -0400

> 	problem without a clear statement?

The solutions I'm talking about are those recently described involving the chain of trust from old keys through successive keys. The problems that those specific solutions are intended to solve  have not been described. As you know.

> 	might have some good ideas on the subject.  But thats _future_ work.

Thank you.

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 16:33:35 +0100

On Mon, 4 Oct 2010, Joe Abley wrote:
>
> I have not heard a clear description of a problem yet

How can a system that missed a TA rollover bootstrap its DNSSEC validator?
It might have missed a rollover because:

* It is an old software distribution that has just been installed;
* It is some old hardware that has just been deployed.
* It is some old hardware that has suffered a factory reset.

Here "old" means greater than two months - the root 5011 rollover period.

When a validator is bootstrapping it needs to be able to tell the
difference between an attack and a rolled TA. If it cannot get the new TA
using the DNS, it must do so using some higher level protocol. Higher
level protocols depend on the DNS. This implies that the system must
provisionally switch off its validator in order to obtain a new TA. This
implies that bootstrapping systems are vulnerable to downgrade attacks
and therefore spoofing.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 11:34:44 -0400

On 2010-10-04, at 11:18, Tony Finch wrote:

> RFC 5011 to work in the event of a compromise.
> 
> [...]

We seem once again to be moving from the subject at hand to a review and discussion of the KSK DPS. I would prefer to focus on the document at hand, here.

If you would like more insight into the design decisions that resulted in the current DPS, I am sure the authors of it would be happy to talk to you about it.

> TA. The root TA has no such backup.

Correct. There is no hot-standby replacement KSK for the root zone.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 11:35:21 -0400

> How can a system that missed a TA rollover bootstrap its DNSSEC validator?

The same way that it bootstraps itself at day zero.

Joe

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 4 Oct 2010 17:38:22 +0200

> trust anchors in the event of a compromise.

Depending on the type of compromise, a RFC 5011 may not be appropriate.

> sanctioned TA, but that validator operators will have to manually install

Correct.

	jakob

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Oct 2010 12:03:46 -0400

> keys, and we say so" actually.

I think I've made this argument before, but the above seems to me to
be one of two possibly relevant perspectives in respect of keys
(either in this DNSSEC context or more generally, but I'm
concentrating on the DNSSEC context just now).

On the one hand, we can understand keys as expressing a certain
trustworthiness-assurance on the part of the key publisher.  We can
understand the publication of the key as an assertion on the part of
the publisher that data signed with that key is trustworthy.  I call
this view publisher-centric.  If we understand keys according to this
scheme, then it is entirely reasonable for a key publisher to say,
"Once I have pulled a key, don't use it, ever."

On the other hand, we can understand keys as a feature a publisher
offers users in order that those users may make intelligent choices
about trust.  In this view, we can understand the publication of a key
as part of that support offered to users who want to validate data.
Those users are then in a position to make evaluations of data they
receive.  I call this the user-interpretive view.  Under this view, it
is not reasonable for a key publisher to try to prescribe how the key
is to be used once it is published.  This approach, however, comes
with the risk to the user that the user will not know of a key
compromise.  The problem in this case is that the use-value to the
user, which lies in increased confidence in the value of the signed
data, is misplaced.  Instead, the publisher's role is reduced to
warning users (by policies) what uses the publisher is willing to
support, and what uses are unsupported.

It seems to me that both perspectives are useful and valuable, but
they're different ways of looking at the issue and they have different
implications.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 17:39:20 +0100

> We seem once again to be moving from the subject at hand to a review and discussion of the KSK DPS. I would prefer to focus on the document at hand, here.

It is relevant because the trust anchor publication scheme is the only fallback we have when RFC 5011 fails. If we can reduce the number of possible failure scenarios then we don't have to rely so much on higher level systems that are less well documented and not so impressively well secured.

I am really concerned that it might become impossible to roll the root TA.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 17:53:24 +0100

> The same way that it bootstraps itself at day zero.

I expect that validators will ship with an initial TA built in (e.g. as
BIND does for DLV) which means the two scenarios are very different.

Even if the validator does not ship with an initial TA, there is still a
big difference between no TA and a broken TA, so the validator still has
to be able to work out if the breakage is benign or malicious.

It would be nice to see some evidence that other people are thinking about
this problem seriously and in detail rather than brushing off my questions
:-/

Tony.

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 17:56:29 +0100

> Depending on the type of compromise, a RFC 5011 may not be appropriate.

RFC 5011 allows for smooth operation across compromise or loss of the
active KSK, or compromise or loss of the backup KSK. Only if both of them
are simultaneously lost or compromised do things go horribly wrong.

Tony.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 4 Oct 2010 19:26:33 +0200

> are simultaneously lost or compromised do things go horribly wrong.

RFC 5011 is not very useful if the active KSK is rendered in-operational ("lost") nor is it very useful if the algorithm used for the active KSK is compromised. My point is that there are more than the "the active KSK has been stolen or brute-forced" scenario, and 5011 only helps you in some of those cases.

I believe it would be most useful if the vendor planning on using the current trust anchor publication scheme could explain their current ideas. They have been bcc'd on this message, perhaps they will step forward.

	jakob

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 13:37:56 -0400

> are simultaneously lost or compromised do things go horribly wrong.

I hear you, but there is no backup KSK in the sense that I think you mean (there is no pre-generated, hot-standby incoming KSK).

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 18:41:02 +0100

On Mon, 4 Oct 2010, Jakob Schlyter wrote:
>
> RFC 5011 is not very useful if the active KSK is rendered in-operational
> ("lost")

Er, yes it is. You have a pre-published standby SEP key which validators
are ready to use as a trust anchor, so you can immediately promote it to
being the operational KSK. You handle key compromises in exactly the same
way. (This implies you ahould have diverse systems and storage for the
live and backup keys.)

> nor is it very useful if the algorithm used for the active KSK
> is compromised.

There isn't a very good solution for that since DNSSEC requires that a
zone has RRSIGs for all algorithms for which it has DNSKEYs, so you can't
pre-publish an inactive SEP key with a different algorithm.

We just have to hope that algorithms are broken slowly, like MD5 :-)

Tony.

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 13:46:18 -0400

> BIND does for DLV) which means the two scenarios are very different.

We've talked to DNS vendors and although I don't want to foreshadow their timelines for making code or strategies available, I can tell you that there is work underway to accommodate 5011 rollover, 5011 rollover with a client that is disconnected over the transition window, and day-zero trust anchor bootstrap. No show-stoppers have been identified in the conversations I have seen. No doubt the vendors concerned will describe their approach when they are ready.

> this problem seriously and in detail rather than brushing off my questions

I think some of your questions are best directed towards vendors.

I think some of your observations (those that relate to root KSK management in general, as described in the DPS) would have been good to hear before July, during the design process. The DPS is not written in concrete, but at the same time we are not about to make radical changes in a split second now that the key is in production. We are being audited against the current DPS, as-published.

I think also that there is some sense that the trust-anchor document is intended as a starting point for a working group design exercise, which is not the case. This is an informational document describing an existing service, and is being published in the interests of having a stable specification in a sensible place for vendors to code against. We are not seeking working group adoption; our goal is an AD-sponsored, individual submission. Hence the review here is really in the interests of document quality and clarity of the specification (something that many reviewers have helped us with already, and which I expect will result in a better document).

Really, I'm not trying to brush off your questions, but given the context above it's difficult to give you the kind of answers you seem to want.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 13:46:45 -0400

On 2010-10-04, at 13:41, Tony Finch wrote:

> Er, yes it is. You have a pre-published standby SEP key

No. We don't.

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 18:56:11 +0100

> > Er, yes it is. You have a pre-published standby SEP key

I meant that the emergency rollover scenarios described in 5011 expect you
to have one.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Oct 2010 19:13:03 +0100

On Mon, 4 Oct 2010, Joe Abley wrote:
>
> I think some of your observations (those that relate to root KSK
> management in general, as described in the DPS) would have been good to
> hear before July, during the design process.

Yes :-/ I was still only starting to get to grips with key management back
then.

> I think also that there is some sense that the trust-anchor document is
> intended as a starting point for a working group design exercise, which
> is not the case. This is an informational document describing an
> existing service, and is being published in the interests of having a
> stable specification in a sensible place for vendors to code against.

Understood.

One thing that is missing is any description of the kind of load you
expect the service to bear. Would it be OK if a vendor sold millions of
DSL modems that hit data.iana.org every time they recovered from a power
loss?

Tony.

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Oct 2010 14:37:19 -0400

> DSL modems that hit data.iana.org every time they recovered from a power

This, to me, is an operational consideration that is orthogonal to the specification.

I agree that there are circumstances where we might receive an unpleasant load of traffic. If that was to happen, we would deal with it, as ICANN's IT department deals with other such operational challenges.

I can tell you that data.iana.org is currently being hosted on some sensibly-sized iron and I would expect it to accommodate substantial flash crowds, and that there is a full-time team of engineers that runs all ICANN's internal infrastructure, for what that's worth.

Joe

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 08 Oct 2010 14:45:44 +0200

Hi Dnsop,

On 10/04/2010 07:46 PM, Joe Abley wrote:
> We've talked to DNS vendors and although I don't want to foreshadow
> their timelines for making code or strategies available, I can tell
> you that there is work underway to accommodate 5011 rollover, 5011
> rollover with a client that is disconnected over the transition
> window, and day-zero trust anchor bootstrap. No show-stoppers have
> been identified in the conversations I have seen. No doubt the
> vendors concerned will describe their approach when they are ready.

OK, so I have been contemplating a good way to 'ship DNSSEC' as a
vendor.  The current solutions are trust-history and the draft from the
subject line.  I have investigated and implemented them.

So, we can ship a root TA (or additional key), under our license
agreement (BSD license), to facilitate deployment.  To implement it the
config file needs a tweak by the user.  It is not a 'default' today.
The tool can output its builtin hardcoded key for inspection.

The trust-history proposal has been described previously.  The method
with which we intend to use the https provided xml file is as follows.
After that description I'll compare the two approaches.

There is an add-on tool (unbound-anchor, available from svn) that
contains the hardcoded keys.  It runs before the daemon is started (i.e.
at system boot).  Initially it provides the key to start.  Then it uses
RFC5011-tracking.  The main daemon then also uses RFC5011 tracking while
in operation.  If RFC5011-tracking fails because the system was not
turned on, then the alternative update path is used, the xml file is
fetched, verified, and used to re-instate RFC5011 tracking.

The initial-key setup, this means trust anchor files do not exist; the
hardcoded root-DS record (from TCR attestions) is tried first, and the
certificate verified xml is tried after.  To diminish load on iana.

To protect the system as well as the iana service, its checks that the
30-days timer from 5011 has really passed before bothering the https
server.  This should keep the load for iana manageable, and also keep
startup time fast (usually only a RFC5011 UDP transaction).  (This is
not as easy as it seems, in case of missing the ADDPEND announce, a todo
item).  Thus, it is a pretty simple tool that reads the RFC5011-state on
disk (if any), probes DNS, and performs https update if necessary and
then writes the updated (or wholly new) RFC5011-state back to disk.  It
implements a DNS-lookup for the website even while the root anchor is
not available.  Lots of options to override the cert, key, etc, and for
manual checks to be performed if the tool 'fires'.

The difficult issues for the cert-update tool, are how to exactly
interface with RFC5011 state (state changes that it makes).  And what to
do when the certificate expires (current tool goes to bogus; thus
devices will cease operation at 2028, which I find a bit ... not nice).
 And code if the root goes to insecure (I think I have this implemented
correctly).

Comparison of TH (trust history), CU (certificate update).

* How long does that baked-in key last?  TH: forever.  CU: until
certificate expires (2028 or so).

* Security.  TH: uses old KSKs.  CU: that cert.
TH: dnsop consensus against use of retired keys.
CU: the problem is really moved to the certificate itself.

* Deployment.  TH, no movement.  CU: prototype client I just wrote,
https service works.

* Load on the system:  TH: load at rollover time, data in DNS.  CU:
tries to use DNS in first 30 days, probably peak http 30-days after the
roll.

* trustpath:  TH: trust goes to the operator of the zone KSK.
CU: depends on which of the various options that are listed that you
choose.  Several provide an independent trustpath; we use one that is an
independent trust path (the SMIME key).

* key rollover.  TH: the KSK roll *is* the trust anchor roll.  CU: the
KSK roll is covered by another key, whose keyroll is not specified.  A
software-update process?  If that is so, you would need to roll out a
new certificate (lasting to 2038) within the next 10 years, to keep the
system '20 years' ahead, a careful calculation of this sort seems wise.

* Handle revocation-back-to-insecure.  TH: yes.  CU: yes.

* Dependency on local clock.   TH: yes, otherwise old keys could be
abused.  CU: yes, same, old keys or the cert expiry time can be triggered.
My current implementation of the CU tool prohibits function before
20100715 (when the root was signed), to avoid a downgrade attack if the
clock is set before that date.

* Initial trust deposition.  Both use a trusted software install, that
includes the correct key to get things started.
* Regular updates.  Both use RFC5011 (DNS usage only).
* If the machine was offline.  TH: handles with key-signs-key data.  CU:
handles via certificate and https.
* If the network cable was not connected for a year: basically out of
scope.  (i.e. script runs at boot time).

Other vendors can speak for themselves, and I note a CSR signing request
is available if they use their own certificates.

Like Joe says, it looks okay, just have to get trust in the certificate
processed, and engage with the port/distro maintainers about
configuration and bootscripts.  But if you have any comment, I would
greatly appreciate it.  Or hear other vendors' ideas.

Best regards,
   Wouter