Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys?

["trans issue tracker" <[e-mail]>]

#170: Allow for separate SCT and STH keys?
-------------------------+-----------------------
 Reporter:  rlb@…        |       Owner:  eranm@…
     Type:  defect       |      Status:  assigned
 Priority:  major        |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-----------------------

Comment (by linus@…):

 As a log implementer and log operator I'd like to express support for the
 idea of using separate keys for signing SCTs and STHs.

 In an architecture where the log owner can delegate //some// power to
 other organisations for operating frontend nodes by allowing frontend
 nodes to sign SCTs but not STHs, this would lower the risk of "full
 takeover" of a log. While there certainly are attacks that can be
 performed by an adversary capable of producing either SCTs //or// STHs I
 think there are also attacks that require that //both// SCTs and STHs can
 be signed.

 Note that the threat is not limited to an adversary getting hold of a copy
 of key material but also includes the capability of having SCTs and STHs
 signed by a signing service. I mention this because the design and
 implementation of such signing services would be less complex if they
 didn't have to deal with multiple keys and roles for these keys.

 While I disagree with the stated lack of benefit I do agree that there is
 a cost in client implementation and also in overall complexity of the
 system. I think that the benefit outweigh the cost but would like to hear
 other peoples view on this, especially CT client implementors.

--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/170#comment:3>
Public Notary Transparency  Wiki <https://trac.ietf.org/trac/trans>
My example project