Subject: [therightkey] review of draft-laurie-pki-sunlight-03: point 10

From: Ben Laurie <[email-masked]>
Date: Mon, 17 Dec 2012 18:19:14 +0000

> (10) 3.1, identifying a log solely on the basis of its key_id
> without any roll-over seems dumb. What if the log wants to
> roll its signature key? This would have to be fixed in a
> standards-track RFC but really could be done now and would be
> better for having being done.

Our view was that a new key is effectively a new log and so roll-over
is achieved by ... starting a new log. If it is done because of key
compromise, then the old log can no longer be trusted.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Dec 2012 22:17:06 +0000

Hiya,

> compromise, then the old log can no longer be trusted.

Hmm. That seems wrong to me in some cases.

If signing with RSA then I might want to roll a new, longer
key at some point in future, but without having to consider
the log as changing. Similarly, I might want to have both
RSA and ECC based signatures if different clients support
different algs. A log might also want to upgrade some
crypto h/w in a way that doesn't allow for migration of
the same private key.

Maybe this and other similar things might be usefully
handled in a section called "stuff we might change as we
move to standards-track" or something?

S.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 10:47:35 +0000

> crypto h/w in a way that doesn't allow for migration of

Maybe. The only way to do this that makes much sense to me would be to
allow the log's "master key" to delegate to subkeys (rather like
DNSSEC's KSKs and ZSKs). In which case the ID would still be derived
from the key.

> move to standards-track" or something?

Sounds like a good idea.