Temporary Binding implementation #21
Conversation
| func NewTemporaryBinding(pad *PAD, key string, value []byte) *TemporaryBinding { | ||
| str := pad.currentSTR | ||
| index := computePrivateIndex(key) | ||
| tb := str.SerializeWithSignature() |
There was a problem hiding this comment.
This is a similar comment to what I had in #8 (comment)
In §3.3, STR is defined as,
STR = SignSKd (t||tprev||roott ||H(STRprev)||P)
which to me look like it's just the signature. I know I'm picking at nits, but now when I go look at the definition of TB in §4.1.1,
TB = SignKd (STRt, i, k)
(which, in an aside to @masomel, probably wants to be, TB = SignSKd (STRt || i || k), consistent with SKd and concatenation)
it's again not clear what is meant by STR.
There was a problem hiding this comment.
I see your confusion now. I went back to look at Certificate Transparency's Signed Tree Head spec, after which STRs are modeled, and I think technically, the STR should be only the signature.
What this means for prevStrHash and also TB (which yes, the notation should really use concatenation for consistency, though I believe commas are more proper crypto notation), is that these should only use STR.signature in their respective computations.
However, when TBs and STRs are sent to the client (and eventually to auditors in STRs' case), we will still have to include all the values to allow for signature verification.
There was a problem hiding this comment.
Thanks for the clarification. I opened #22 for prevStrHash.
|
I feel like |
I had the same thought, but decided it would be best to leave it up to the developer to use TBs in the server implementation. The reason is that we've found that temporary bindings may not actually be the best approach to solving the immediate issuance problem, as we've been discussing in #13 and as we've learned from other contacts in industry (all of which are looking for alternatives to TBs). So we should definitely continue refining our solution for TBs, and I think it's fine to provide the TB interface for those developers who are willing to use TBs, but I don't think the |
Ok, I'm on board with that. I guess I'm most uncomfortable with |
This makes sense to me. |
The reason I did it is I thought it would be more consistent with other |
| sig []byte | ||
| } | ||
|
|
||
| func (pad *PAD) NewTemporaryBinding(key string, value []byte) *TemporaryBinding { |
There was a problem hiding this comment.
Can we move this to pad.go though, to be closer to PAD's other methods? And maybe rename it to just .TB().
|
I approve of everything @arlolra commented on. Especially of making Also I'm not sure if we'll need all the getters ( |
I think we still need these getters since we need to expose these values to the client to allow them verify the signature. Does it make sense? |
| tb = append(tb, index...) | ||
| tb = append(tb, value...) | ||
| sig := crypto.Sign(pad.key, tb) | ||
|
|
There was a problem hiding this comment.
Should we also call pad.Set(key, value) in here? If we're issuing a TB, it's kind of implying that, no?
There was a problem hiding this comment.
Yes, I couldn't find out any other reasons to not to do it, so we should do it.
Implement the TB struct for registration protocol.