Longterm versioning strategy

[dennisjackson]

@thomwiggers:

The one thing that makes me frown a bit is the intended versioning scheme. I don't think consuming identifiers is a problem, but perhaps we can pre-define the code points and variables for the next, say, N=0xff years? Then the versioning mechanism is set for the foreseeable future. (You could even say that we wrap the code points after N years).

As well as the discussion on the mailing list, this was also discussed during the tlswg meeting @ IETF 117. There was no particular consensus on the most suitable strategy.

A related issue is whether this draft will slow rotation of intermediate certificates. As discussed in Appendix B and at the IETF 117 Presentation, this might mean using an extension and dynamic negotiation is more suitable.

[ilaril]

As a note, one dynamic negotiation strategy I came up with:

• Assign the identifiers backwards from 0xffffff (no real certificate is anywhere even near 16MB).
• Removed certificates are replaced by tombstones.
• Client sends size (including placeholders and tombstones) of its certificate dictionary to server in extension.
• Server includes any certificates where the identifier is out of range for the client in full.

This seems like it could move as fast as stable sequencing of new certificates can be done. Both new and expired/removed certificate bunches in WebPKI seem to happen a bit more often than once per week on average.