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