Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define Canonical Representations for SignedLogRoot and SignedMapRoot #958

Closed
gdbelvin opened this issue Jan 31, 2018 · 3 comments
Closed
Assignees

Comments

@gdbelvin
Copy link
Contributor

gdbelvin commented Jan 31, 2018

The current ObjectHash based signature for the SignedLogRoot and SignedMapRoot in Trillian is not stable enough for production use. A simpler, well defined signature scheme is desired. A simpler scheme would enable:

  • Signing SignedLogRoots inside Google
  • General gossip
  • Verifiers in other languages

The proposed canonical encoding is a TLS struct containing the relevant fields.

Design Doc

Backwards compatibility

This change would break backwards compatibility with existing SignedLogRoots.
However:

  • The current Trillian APIs do not support retrieving old SignedLogRoots.
  • All known clients of Trillian do not use the signature in the SignedLogRoot. (Please speak up if you know of a counter example)

Going forward, the TreeInfo struct will declare what signature format to use.

@gdbelvin
Copy link
Contributor Author

gdbelvin commented Mar 6, 2018

After much discussion the new SignedLogRoot will take on the following format which allows gossip participants to forward SignedLogRoots without risk of DoS. key_hint should give an efficient path to looking up the correct key to use to verify the signature. The LogID is determined by association with the public key that verified the structure.

message SignedLogRoot {
   bytes key_hint = 1;  // Typically log_id. 
   bytes log_root = 2;
   bytes signature = 3;
}

The content inside log_root (For Trillian Logs) has the following TLS specified format. Clients SHOULD verify the signature on log_root before attempting to parse this data structure.

enum { v1(1), (65535)} Version;
struct {
  uint64 tree_size;
  opaque root_hash<0..128>;
  uint64 timestamp_nanos;
  uint64 revision;
  opaque metadata<0..65535>;
} LogRootV1;
struct {
  Version version;
  select(version) {
    case v1: LogRootV1;
  }
} LogRoot;

@AlCutter
Copy link
Member

Fixed?

@gdbelvin
Copy link
Contributor Author

gdbelvin commented May 23, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants