BUG? Shouldn't passing a pcr value file as an auth policy argument raise an error?

[SharkOverBite]

Hi folks,

I just opened https://github.com/nokia/TPMCourse/issues/22, because I think the example they include of sealing data in nvram with a PCR policy is misleading. I'm opening a related issue here, because it seems to me their example functions as expected only because the tpm2_nvwrite/tpm2_nvwrite simply ignore what I think should actually be an invalid argument value.

Here is the command sequence they use:

$ tpm2_pcrread -o srtm.pcrvalues sha256:0,1,2,3
$ tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 -f srtm.pcrvalues -L srtm.policy
$ tpm2_nvdefine 0x1500019 -C o -s 32 -L srtm.policy -a "policyread|policywrite"
$ tpm2_nvwrite 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues -i testfile
$ tpm2_nvread 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues 

Clearly, there's no reason for =srtm.pcrvalues to be passed in for the last two lines. The PCR values for the policy protecting the NVRAM location is based on the device's current PCR values, not on any "PCR Values" the user hands the PCR.

Shouldn't the commands complain about this instead of simply ignoring it?

Also, as an unrelated question, can you confirm that the metadata for the PCRs used for a policy (i.e. "sha256:0,1,2,3") isn't actually stored with the policy itself? the caller really has to tell the device which bank/PCRs to compare against?