Comment 56 for bug 1490804

I won't pretend to know the intricacies of the PKI/PKIZ implementation, though presumably if you're going to call into `openssl cms` during validation against the revocation list then storing/checking a hash of just the tdata (instead of or alongside the full document hash currently used) doesn't impose much additional performance penalty? This of course wouldn't help already stored hashes, but for any new ones added the revocation could be matched regardless of optional fields since the tdata seems like it should be unique.

I'm completely in favor of ripping out PKI/PKIZ tokens in Mitaka (with appropriate communication in release notes/upgrade documentation), but we continue to claim security support for features in Kilo and Liberty for some months to come. If there's a compatible solution which can be backported to our current stable branches, it's of potential temporary benefit to deployments which may have trouble switching to UUID or Fernet quickly and are looking for some alternative mitigation in the interim. If that really just can't work, then sure we should proceed with the current plan to tell those people they're stuck with a gaping insecurity until they alter a fundamental aspect of their deployment.

It's of course also possible I'm overestimating the amount of work involved in switching the token type for a deployment, since I'm not an operator.