RE: Issues with SP80056AConcatKDF in XML Encryption 1.1 - ACTION-406

This is in response to the discussion on this topic on last week's call and ACTION-406.

Based on the exchange during the call, Brian and I have come up with the below suggested new wording for the text in XML Enc 1.1 that covers the ConcatKDF parameters. The objective has been to defer to NIST 800-56A for interpretation of these parameters, clarify that applications must verify these parameters in an application-specific way (but in compliance with NIST 800-56A) but also to specify how these bit string values defined in 800-56A are to be converted to and from hexBinary. Here's the proposal:

The AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are as defined in NIST SP800-56A<http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#ref-SP800-56A>. Their presence is optional but AlgorithmID, PartyVInfo and PartyUInfo MUST be present for applications that need to comply with NIST SP800-56A<http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#ref-SP800-56A>.

In NIST SP800-56A<http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#ref-SP800-56A>, AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo are all defined as arbitrary-length bitstrings, thus they may need to be padded in order to be encoded into hexBinary for XML Encryption.  The following padding and encoding method MUST be used when encoding bitstring values for  AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo:

1)  The bitstring is divided into octets using big-endian encoding.  If the length of the bitstring is not a multiple of 8 then add padding bits (value 0) as necessary to the last octet to make it a multiple of 8.

2)  Prepend one octet to the octets string from step 1. This octet shall identify (in a big-endian representation) the number of padding bits added to the last octet in step 1.

3)  Encode the octet string resulting from step 2 as a hexBinary string.

Example: the bitstring "11011", which is 5 bits long, gets 3 additional padding bits to become the octet (in hex) D8.  This octet is then prepended with one octet identifying the number of padding bits to become the octet string (in hex) 03D8, which then finally is encoded as a hexBinary string value of "03D8".

Note that as specified in NIST SP800-56A, these attributes shall be concatenated to form a bit string "OtherInfo" that is used with the key derivation function. Applications MUST also verify that these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800-56.


-- Magnus