Policy sessions need to know authValue for parameter encryption

[chrisfenner]

According to Part 1, 21.1: Session-based encryption introduction:

If a session is also being used for authorization, sessionValue (see 21.2 and 21.3) is sessionKey || authValue. The binding of the session is ignored. If the session is not being used for authorization, sessionValue is sessionKey.

NOTE 1 A policy session that is used for parameter encryption uses authValue to calculate sessionValue even if the policy does not include TPM2_PolicyAuthValue().

This means we need to hook in some way for a caller who's using a policy session for authorization and parameter encryption with an object with non-empty auth value, to pass that auth value, in an ergonomic way.

[josephlr]

Do we envision a need for someone to use a session for both authorization, and parameter encryption? It seems like in most cases you would want to use separate session handles for this.

It seems really complicated to have an ergonomic workflow for this, while keeping authorization sessions separate from encryption/audit sessions means that we can have specialized workflows for each, and make each of them easier to use.

[chrisfenner]

We could wait til we have a concrete use case, but then we should still disable the use of policy sessions for parameter encryption for now.

[josephlr]

That seems reasonable, I'm not even exactly sure how you would use a policy session for parameter encryption, so it's definitely an area of the API that needs more thought