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

Actually, the KDFs are not exactly the same. In X9.63

Hashi = H(Z, Counter, SharedInfo)

And this is the case also with the ANSI-X9.63-KDF in SEC 1 (although in my copy of ANSI X9.63, the parameters Z and SharedInfo are bit strings and not, as in SEC 1, octet strings).

Also, all the SHA hash functions do take bit strings as input parameters (and NIST SP 800-56 only allows FIPS 180-2 hash, i.e. SHA-x, functions), and then depending on the length you do padding, e.g. for SHA-1 up to 512 bit blocks.

-- Magnus

From: Pratik Datta [mailto:PRATIK.DATTA@oracle.com]
Sent: Monday, December 07, 2009 9:54 AM
To: Magnus Nystrom
Cc: public-xmlsec@w3.org
Subject: RE: Issues with SP80056AConcatKDF in XML Encryption 1.1 - ACTION-406

I am still having one problem with the ConcatKDF.

The AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are bit strings, so concatenating them to OtherInfo might result in a length that is not a multiple of 8. What do we do in that case? Because we have to compute Hashi = H(counter || Z || OtherInfo) and for this we need OtherInfo to be a bit string that is a multiple of 8.

Is this SP80056 KDF the same as the ANSI 9.63 KDF? Because in this (SEC 1 section C6  http://www.secg.org/collateral/sec1_final.pdf )
They have defined these attributes as octet strings, not bit strings.

>From SEC1 section C6
ASN1SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] OCTET STRING OPTIONAL,
entityVInfo [1] OCTET STRING OPTIONAL,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}

Maybe we could also define them as Octet Strings.

Pratik

From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
Sent: Tuesday, November 03, 2009 10:18 AM
To: Pratik Datta
Cc: public-xmlsec@w3.org
Subject: RE: Issues with SP80056AConcatKDF in XML Encryption 1.1 - ACTION-406

Yes, it is the latter. In the last paragraph, one could change to: "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. The concatenation shall be done using the original, unpadded bit string values."

As for your second question, based on the decision to defer to applications to interpret, I would say no - this will be up to applications to decide.

-- Magnus

From: pratik.datta@oracle.com [mailto:pratik.datta@oracle.com]
Sent: Tuesday, November 03, 2009 9:47 AM
To: Magnus Nystrom
Cc: public-xmlsec@w3.org
Subject: 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:

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.

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.

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