Link to specs & define compatibility requirements#46
Conversation
rgdd
left a comment
rgdd
left a comment
There was a problem hiding this comment.
Broad strokes -- looking good. Dropped a few minor comments that might be worth resolving before merge.
| - [tlog-witness][] defines a witness API contract. | ||
| - [tlog-checkpoint][] defines how logs must represent their state when | ||
| interacting with witnesses. | ||
| - [tlog-cosignature][] defines the signature schemes used on `checkpoints`. |
There was a problem hiding this comment.
Suggestion: work in that the semantics of what a signature means is also defined in tlog-cosignature.
| specification. | ||
| - Witnesses MUST support verification of either `MLDSA-44` or `ed25519` | ||
| signatures from logs, but SHOULD support both. | ||
| - Witnesses MUST return `MLDSA-44` cosignatures, and MAY also return |
There was a problem hiding this comment.
This MUST seems too strong, since none (or few?) of the current witnesses in our network support this.
We could be opinionated on not letting any new witnesses in without ML-DSA-44, but I think even that is probably a bit counterproductive. Not entirely sure though, WDYT?
(How we decide to frame here, and in particular if we change the framing, then we might also need to update the final paragraph that's changed in this PR. I.e., relating to what's expected on the witness about page.)
There was a problem hiding this comment.
This "MUST" is a starter-for-10 and represents aspiration, not going to die on this hill, but I thought it was the right place to kick off the convo given:
- The current momentum in the industry to get PQ ready.
The first MTC log & mirror instances are about to land, and MTC mirrors (which are witnesses, by definition) already MUST support ML-DSA-44 (By-the-by the intention is that Tessera's MTC mirror will support PWN out of the box).
We can likely piggy-back on this momentum while it's still fun :) - The witness network is still at
staging, but I could imagine it becomingprodin the not-super-distant future. Easier, perhaps, to make this change before then.
Logs which may want to carry both Ed and ML-DSA cosigs will I guess(?) have to use a more complex witness policy if they cannot rely on witnesses returning both ("I want a quorum of Ed from this set AND a quorum of ML-DSA" from this other differently sized set" - maybe this is not the end of the world).
| the public key in [vkey format][]. Keys may be of the following types: | ||
|
|
||
| - `0x01` (ed25519), | ||
| - `0x04` (Timestamped ed25519 cosignature/v1), |
There was a problem hiding this comment.
Are there any logs that use 0x04 that wants to join the witness network? Otherwise I think it would make sense to not include this as one of the things that essentially MUST be supported to be compliant, especially considering that it will confuse those that want to understand why there are two different Ed25519.
Suggestion: remove.
There was a problem hiding this comment.
Don't feel super strongly about it, there's a certain symmetry to having everyone sign with time, but if this is on its way out anyway then we'll just get it for free if/when everyone's using ML-DSA cosig/v1.
|
|
||
| - `0x01` (ed25519), | ||
| - `0x04` (Timestamped ed25519 cosignature/v1), | ||
| - `0x06` (Timestamped MLDSA-44 cosignature/v1). |
There was a problem hiding this comment.
What's the status of supporting this in the current implementations? Not against merging even if it is not supported yet, but would make sense if we ensure that PRs are on the way so our witnesses has something to update to. At a quick glance it looks like, e.g., litewitness doesn't support this yet (as a consequence of note.Open not supporting this. But I might be mistaken, I'm looking here: https://cs.opensource.google/go/x/mod/+/refs/tags/v0.37.0:sumdb/note/note.go;l=260-271)
There was a problem hiding this comment.
github.com/transparency-dev/witness and github.com/transparency-dev/tessera both support it. Our staging witness ring-any-bells is returning ML-DSA-44 cosigs currently, and, um, a log running Tessera is using ML-DSA-44 for its signatures too.
note.Open definitely supports it, since that's what we use in both of the above, but the verifier the sumdb note package supports does not (you need to pass in your own note.Verifier, e.g. https://github.com/transparency-dev/formats/blob/main/note/note_cosigv1.go)
4 participants
This PR add links to the C2SP specs the witness network relies on, and explicitly spells out compatibility requirements and strengthens recommendations for participating entities.
This was somewhat prompted by C2SP/C2SP#276.
The requirements in here are slightly stronger than the language in the linked PR and tlog-witness wrt to
MLDSA(MUST vs SHOULD), this seemed in keeping with the shift for PQ but it's more of a starter-for-10; happy to soften this to match if that's the better approach.