#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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
