MSC1935: Key validity enforcement

[turt2live]

Rendered

Reference: matrix-org/synapse#4364

[ara4n]

lgtm mod comment

[anoadragon453]

Looks good to me. I think it's fine to change the definition of past room versions as well as long as we agree upon it democratically.

It seems like this'll be a fairly minor change that people will be happy with, so:

@mscbot fcp merge

[mscbot]

Team member @anoadragon453 has proposed to merge this. The next step is review by the rest of the tagged people:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

Concerns:

• needs more detail (MSC1935: Key validity enforcement #1935 (comment))
• v4 definition should be a separate msc (MSC1935: Key validity enforcement #1935 (comment))

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[turt2live]

I think it's fine to change the definition of past room versions as well as long as we agree upon it democratically.

ftr, the reason the room version specs are in-tree is for cases like this. Like other specifications, they are immutable once written however by moving stuff into a new room version we have to update the old versions as well. The old versions should not be receiving changes which alter their intended purpose or expectation for the time they were introduced. More plainly said, room versions get added information but cannot change.

[richvdh]

I have two, somewhat related, concerns here.

The basic problem is that I think there is more to enforcing validity periods than just saying "make it so". There are unanswered questions around how you apply validity periods to objects which may have been signed some time ago, how you go about establishing whether a key was valid at a given point in the past, whether you should actively attempt to refresh your copy of a key which will shortly expire, etc etc. These are the reasons that I have avoided making this into an MSC so far: I want to do some experimentation and investigation to figure out exactly what's involved.

Relatedly, to date we've tried out things which need room version changes in a test room version first. For example, we might discover that there is some critical security bug that needs to go into a new room version asap and I don't want to have to make it v5 because v4 is reserved for something that we aren't ready for yet.

@mscbot concern needs more detail
@mscbot concern v4 definition should be a separate msc

[richvdh]

I have two, somewhat related, concerns here.

The basic problem is that I think there is more to enforcing validity periods than just saying "make it so". There are unanswered questions around how you apply validity periods to objects which may have been signed some time ago, how you go about establishing whether a key was valid at a given point in the past, whether you should actively attempt to refresh your copy of a key which will shortly expire, etc etc. These are the reasons that I have avoided making this into an MSC so far: I want to do some experimentation and investigation to figure out exactly what's involved.

Relatedly, to date we've tried out things which need room version changes in a test room version first. For example, we might discover that there is some critical security bug that needs to go into a new room version asap and I don't want to have to make it v5 because v4 is reserved for something that we aren't ready for yet.

@mscbot concern needs more detail
@mscbot concern v4 definition should be a separate msc

[turt2live]

This MSC wasn't created in the right frame of mind, and as @richvdh mentions the proposal is certainly lacking in many areas. Instead of proposing a half-baked solution here, I'm closing this so that someone with a lot more knowledge on the system at play can form a more concrete proposal.

Also, I fully agree the v4 inclusions need to be done separately.

@mscbot fcp cancel

[mscbot]

@turt2live proposal cancelled.