Public STR and TB fields for verification

[arlolra]

Reopening for discussion here since I messed up #34

[masomel]

Shouldn't LibVersion(), HashID() and EpochDeadlinePolicy() be in policy.go?

[vqhuy]

These can change in epochs, thus I think it should be here, corresponding with policies of a specific STR. How does that sound? Never mind. I fixed it in 1d49b1e8b922409ad6f0b24fc6e7befee70978cc

[masomel]

Alternatively to having public fields in the TB and STR, what I had in mind when I opened #24 was to expose a Verify() function. What do you think of db24bfa?

[masomel]

In my branch, I decided to leave the public fields that were added in 812caad since I'm not sure if the client will still need to access those fields using the getters.

[vqhuy]

Alternatively to having public fields in the TB and STR, what I had in mind when I opened #24 was to expose a Verify() function. What do you think of db24bfa?

I got your idea. But the signing key cannot be used here, since I presume that the Verify() function should be called in the client-side only.

In my branch, I decided to leave the public fields that were added in 812caad since I'm not sure if the client will still need to access those fields using the getters.

Actually, I think the key server would use those getters to return the STR/TB to the client. The client doesn't use those getters directly.

[masomel]

the signing key cannot be used here, since I presume that the Verify() function should be called in the client-side only.

Yes, the idea would be for the client to call Verify(). I chose to use the SigningKey since that's what crypto.Verify() uses as well. If SigningKey is the server's key pair, I agree that Verify() shouldn't take it as a param, but then neither should the verification function in crypto.

Actually, I think the key server would use those getters to return the STR/TB to the client. The client doesn't use those getters directly.

Ok, I see.

[vqhuy]

Yes, the idea would be for the client to call Verify(). I chose to use the SigningKey since that's what crypto.Verify() uses as well. If SigningKey is the server's key pair, I agree that Verify() shouldn't take it as a param, but then neither should the verification function in crypto.

Sorry for that. I removed it in 3da95ef40a19094ad9f95f556676649c1deb2daf

[masomel]

Sorry for that. I removed it in 3da95ef

Yeah, with all the signature verification wrappers in place, I suppose we no longer need to export crypto's verify(). I don't think we need to remove it entirely if we want something like VerifySTR() to work. I gave this a shot in d46c806. Please let me know what you think!

[masomel]

I suppose we no longer need to export crypto's verify(). I don't think we need to remove it entirely if we want something like VerifySTR() to work.

Argh, this was silly of me. I forgot crypto is no longer a subpackage of merkletree. Sorry for the noise.

[masomel]

Like we've decided to keep the VerifyX() functions in the lib as we discussed in d46c806#commitcomment-18452858, so I'll go ahead and merge in the str-tb-verify-idea branch and close this PR.