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:               |
-------------------------+-----------------------
Changes (by eranm@…):

 * owner:  draft-ietf-trans-rfc6962-bis@… => eranm@…
 * status:  new => assigned
 * component:  to-be-decided => rfc6962-bis
 * milestone:   => review


Comment:

 I agree with the analysis that the keys used for signing SCTs and STHs do
 not have to be the same.
 However, I'm not sure there's value in allowing that, and it does incur
 added cost.

 In theory it allows for separate security domains between the front-end
 and the signer. But I’d argue that as a log operator, that doesn’t buy us
 much because the signer is not tied to a single datacenter / HSM. The
 signing "role" migrates between jobs at different datacenters (for
 resiliency). Additionally, the key separation would be completely
 unnecessary if we ever build a log with immediate incorporation, where a
 signer is not necessary since sequencing of entries (and STH production)
 is done for each submission.
 As Richard points out, compromise of either keys has the same
 implications.

 It does complicates the client implementation: Client now has to keep two
 keys for the log instead of one.


 So I suggest closing this as wontfix.  We can mention the option somewhere
 in the document, but currently I don't see the need.

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