Users can modify a PKI(Z) token to avoid token revocation
When keystone is configured for PKI or PKIZ tokens, you get a token which is a base64-encoded signed document. In order to validate the token, auth_token middleware un-base64 encodes the document and validates it using the `openssl cms -verify` subcommand. `openssl cms -verify` doesn't validate all the fields in the document, so the document can be modified in some places and it will continue to pass validation.
When auth_token middleware validates that a token is not revoked, it compares the hash of the token to see if it's in the revocation list. Since the modified token hash isn't going to match the value in the revocation list the token will be allowed. So the user can modify their token and continue to use the token even after revocation.
Here's how I'd summarize the problem:
Users can modify a PKI(Z) token to avoid token revocation
When keystone is configured for PKI or PKIZ tokens, you get a token which is a base64-encoded signed document. In order to validate the token, auth_token middleware un-base64 encodes the document and validates it using the `openssl cms -verify` subcommand. `openssl cms -verify` doesn't validate all the fields in the document, so the document can be modified in some places and it will continue to pass validation.
When auth_token middleware validates that a token is not revoked, it compares the hash of the token to see if it's in the revocation list. Since the modified token hash isn't going to match the value in the revocation list the token will be allowed. So the user can modify their token and continue to use the token even after revocation.