Potential IDPrism problem

[Nathan D. Bowen]

Taral wrote:

>It shouldn't need padding. You're XORing two 20-byte strings together
>and then encoding them.
>  
>
Depending on the values of those two 20-byte strings, the XOR might 
result in a value that *could* be represented in fewer than 20 bytes. 
Whether or not it *is* represented with fewer than 20 bytes would be 
dependent on the implementation. So some implementations might need to 
pad the result of the XOR to get 20 bytes.

My perl's rusty, but from my understanding, Net::OpenID::Server is 
another example of a server that will send 19 bytes if it XORs two 
values that happen to begin with the same 8 bits.

However, it's not just a coincidence that the IDPrism server is where 
this problem showed up. That installation is using the DH secret as the 
MAC secret, so the proper value for enc_mac_key is 0.

I haven't seen any other consumer fail because it didn't receive 20 
bytes in the enc_mac_key, but I made the change because I assume that 
*every* consumer will be happy with 20 bytes.

I'm not sure the spec is clear on the correctness of sending fewer than 
20 bytes, but from a standpoint of robustness I'd say that server 
implementors would always want to send 20; consumer implementors would 
always want to accept fewer.