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

It is not very clear if the implementation needs to concatenate the 
padded bit strings, or the orginal unpadded bit strings. I think it is 
the later, but can we make it clear?

Also are recommending a value for AlgorithmID? Earlier we had said that 
it should be 00 hex. Is that still our recommendation?

Pratik


On 11/2/2009 7:44 PM, Magnus Nystrom wrote:
>
> 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
>
>  
>