ConcatKDF in xmlenc-core1: ambiguous concatenation

Hello W3 security group,

The ConcatKDF key derivation function as specified in XML Encryption Syntax and Processing Version 1.1 doesn’t look quite right.
http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF

The derivation involves the hash calculation:
  H(counter || secret || AlgorithmID || PartyUInfo || PartyVInfo || SuppPubInfo || SuppPrivInfo)

The problem is that concatenating the last 5 components is ambiguous. The boundaries between these components are not preserved.

Perhaps there is an unstated assumption that (for any given secret) each component is unambiguous by having a fixed length or starting with its own internal length field. To be secure, the unstated requirement is that the recipient confirms the lengths of each component before performing the key derivation. It seems very unlikely that implementations will ever be that careful — and certainly not without a prominent warning to do so.

The last 5 components are specified in XML attribute values of type hexBinary, with a leading byte indicating the number of unused bits in the last byte (so each component can have an arbitrary bit length).

Example 25 includes:
<xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo="03D0">

So AlgorithmID is 8 bits (00000000), PartyUInfo is 5 bits (11011), PartyVInfo is 5 bits (11010). Presumably SuppPubInfo and SuppPrivInfo are empty. Concatenating gives 18 bits: 00000000 11011 11010. You get the same 18 bits, and hence the same derived key by splitting these 18 bits differently. Eg 0000000011 0111 1010. In XML this would be:
<xenc11:ConcatKDFParams AlgorithmID="060000" PartyUInfo="0470" PartyVInfo="04A0">


Another problem is Example 36 (and Example 34 and Example 42), which includes:

<xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo="">

In this case AlgorithmID is presumably the empty bit string, but PartyUInfo and PartyVInfo look invalid.



On a related note, I think there is a mistake in the interop test DRV.1 for ConcatKDF at http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/Overview.html. The plaintext is not padded before it is encrypted (or the plaintext is 312 bytes, not the stated 320 bytes).
320 bytes of plaintext -> 1 block for IV + 20 blocks of plaintext + 1 block padding -> 352 bytes of ciphertext -> 470 base64 chars
However the <xenc:CipherValue> element has only 448 base64 chars.
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/microsoft/dkey-example-ConcatKDF-crypto.xml


I cannot get the interop test DRV.3 to work either. Is the shared secret key really supposed to be 2176 bits long?
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/ibm/secret.concat.kdf


--
James Manger (Telstra)