Nuvoton auth value size handling looks wrong

[chrisccoulson]

I have a Nuvoton TPM on my Dell XPS15:

TPM2_PT_MANUFACTURER:
  raw: 0x4E544300        
  value: "NTC"
TPM2_PT_VENDOR_STRING_1:    
  raw: 0x4E504354
  value: "NPCT"        
TPM2_PT_VENDOR_STRING_2:
  raw: 0x37357800
  value: "75x"
TPM2_PT_VENDOR_STRING_3:
  raw: 0x200003B
  value: ""
TPM2_PT_VENDOR_STRING_4:
  raw: 0x726C7300
  value: "rls"
TPM2_PT_VENDOR_TPM_TYPE:
  raw: 0x0
TPM2_PT_FIRMWARE_VERSION_1:
  raw: 0x70002
TPM2_PT_FIRMWARE_VERSION_2:
  raw: 0x2

It doesn't seem to handle auth value sizes in the same way as the reference implementation. From experimenting, it seems to behave as follows:

• Trailing zero bytes are stripped from auth values supplied with a password session in a command payload in the implementation of CheckPWAuthSession, which is good.
• At least TPM2_HierarchyChangeAuth strips trailing zero bytes from the auth value before storing it, which is good.
• At least TPM2_Create strips trailing zero bytes from the auth value of the new object, which is different to the reference implementation (which pads the auth value to the size of the name algorithm).
• Duplicating an object with TPM2_Duplicate doesn't normalize the auth value of the duplicated sensitive area by padding it to the size of the name algorithm, which is different to the reference area.
• The auth value in sensitive areas loaded with TPM2_LoadExternal are not modified, which is good.
• The implementation of EntityGetAuthValue doesn't strip trailing zero bytes from the returned auth value before using it in other TPM code, which is different from the reference implementation.

A consequence of this is that if an object that has an auth value with trailing zero bytes is loaded with TPM2_LoadExternal, then that object's auth value cannot be used for password authentication.

It would be worth figuring out if any of these behavioural differences require handling in go-tpm2.