Flexible (Wild Card) Policy
One major problem with the TPM 1.2 design was the brittleness of PCRs. When an entity was locked to a PCR, it was not possible to change the required values of the PCR after it was so locked. PCR0 represents the BIOS firmware, which is security critical. If PCR0 changed, it could indicate a security breach. As a result, applications like Microsoft BitLocker use it for security. However, BIOS firmware may need to be upgraded. When it's upgraded, the value of PCR0 will change, which makes anything locked to that PCR no longer useable.
Programs got around this limitation by decrypting keys, upgrading the BIOS, and then re-encrypting the keys to the new value of PCR0. However, this process is messy and leaves keys exposed for a short period of time while the upgrade is taking place. As a result, it was important that EA be able to allow for changing of the values to which a PCR was locked without decrypting the locked data. But it needed to also be obvious to anyone who wished to check the policy under what circumstances the policy could be changed. A number of possibilities were considered, including having yet another authorization whose only use was to change the policy.
The solution chosen was clever and is given using the command TPM2_PolicyAuthorize, which I call a wild card policy. A wild card policy is owned by a private key whose public key is associated with the wild card. In poker, a wild card can substitute for any card the holder of the wild card wishes. A wild card policy can substitute for any policy the owner of wild card wishes. Any policy approved by the owner of a wild card can be used to satisfy the wild card policy. Policies also can be restricted with a wildCardName that can be given to the wild card when it's created. This allows the owner of the wild card to specify that only wild cards with a particular name can substitute for a particular policy. A wild card associated with an OEM's BIOS signing key could theoretically be used to approve any BIOS signed by the OEM.
The wild card policy is created in a way similar to the command used for the state of an external device, by extending a policy session with TPM_CC_PolicyAuthorize || keySign→nameAlg || keyName || wildCardName. Just as with the PolicySigned assertion, if you're using a trial session to create a wild card policy, you first have to load the public key into the TPM (using the TPM2_LoadExternal command) and then execute the PolicyAuthorize command.
TPM2_LoadExternal returns the handle of the loaded public key, here called aPublicHandle. Then you can execute TPM2_PolicyAuthorize, passing it the handle of the trial session, wildCardName, and aPublicHandle.
TPM2_PolicyAuthorize is one of the most useful policies in the TPM, because it's the only way to effectively change a policy after an object has been created. This means if objects have been locked to one set of PCR values (corresponding to a particular configuration), and the configuration has to change, the objects' policy can be effectively changed to match the new set of configuration values. You see a number of other uses as well in the “Examples” section.