Interop 2 Issue: Signed Token

["Hal Lockhart" <hlockhar@bea.com>]

Tony pointed out that in Scenario #7, there is a backward reference from the
signature to the token used for encryption. This does not make much sense
and is hard to implement because we are first signing and then encrypting
the data, so logically the token is not even present when the signature is
computed unless we interleave the processing.

Thinking about it more, it does not really make much sense to sign the
encryption token, since if the receiver can decrypt with the corresponding
key (and the signature checks out) then it must be the right key and we
don't care about any of the other contents of the token.

So it must have been my mistake. I went back to my original notes on the
scenarios and sure enough, is says "sign the signing token." But come to
think of it, this doesn't make a lot of sense either. By its nature, a
signature binds the key to the signature. And the rest of the token contents
are bound to the key by the issuer's signature.

I can't see any cases where it makes sense to sign the tokens used for
operations in the current message. It does make sense in some other cases,
such as when passing a key for a future encryption. It also makes sense in
the sign and encrypt case, to encrypt the token so as not to reveal the
signer's identity to 3rd parties.

I forget exactly what we were trying to test in this case. One thing we
could sign, which does make sense is the Timestamp.

So, how should I fix this scenario?

1. Sign the signing token
2. Sign the Timestamp
3. Other, specify

Hal