The result of getcapability for transient objects should normally be
virtual handles that the application sees, not the TPM handles.
However, there is a corner case - auditing the getcapability command.
Audit is a TPM function that maintains a hash of commands
and responses, and can sign the audit log.
If the command is audited, the application will see different data from
the TPM (if the getcapability command is even sent to the TPM). Thus,
the audit log won't match.
Two solutions:
1 - Detect the audit bit in the session, and don't virtualize the
command. Send it to the TPM and return the TPM handles.
2 - Declare that auditing getcapability -> transient objects won't work.
The TSS WG specifies #1.
My feeling is that audit is a dubious use case, and auditing
getcapability is a very unlikely use case. I'd go with #2.
Again, what's the sense of the group? I want to know if I have to
either (#1) write TSS code or (#2) put an informative comment in the TPM
library specification.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
tpmdd-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
