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

This is in response to ACTION 406 that I got on this week’s call.

My suggestion is that we simplify the current text as follows (note in italics):

The PartyUIInfo attribute shall, when present, contain information identifying the sender of data encrypted (or authenticated) with the derived key. The encoding of the attribute value shall be as defined in [NIST SP800-56A<http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#ref-SP800-56A>], Section 5.8.1 (the Notes paragraph at the end of the section). For this version of this specification, only one piece of identifying information shall be present in the attribute value. The sender (Party U) shall be identified with an X.509 certificate and the substring shall use the “variable-length” encoding defined in Section 5.8.1 of [NIST SP800-56A]. and shall contain (the hex encoding of) the length of the certificate in big-endian representation immediately followed by the (hex encoding) of the DER-encoded certificate. The length field shall always be two octets (i.e. 4 hex digits) long.
The PartyVIInfo attribute shall, when present, contain information identifying the intended recipient of data encrypted (or authenticated) with the derived key. The encoding of the attribute value shall be as defined for PartyUIInfo, but using information identifying the recipient.
It seems to me this restriction would enable concatenation to bit string while still allowing for separation. Comments?
-- Magnus

From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of pratik.datta@oracle.com
Sent: Tuesday, October 13, 2009 7:10 PM
To: XMLSec WG Public List
Subject: Issues with SP80056AConcatKDF in XML Encryption 1.1

We are looking at ECC encryption more closely.

1. How do we convert the AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, SubbPrivInfo to bit strings?  If we just concatenate the hexBinary values as is, then we won't be able to separate them. Should we use a fixed length bit strings or variable length strings with the length prefix as the NIST spec mentions?


2. These parameters can be quite complex. This is what the spec says

The PartyUIInfo attribute shall, when present, contain information identifying the sender of data encrypted (or authenticated) with the derived key. The encoding of the attribute value shall be as defined in [NIST SP800-56A], Section 5.8.1 (the Notes paragraph at the end of the section). At a minimum, this means that two substrings need to be present in the attribute value: One indicating the method used to identify the sender and one providing the identifying information. The initial substring shall be one octet (two hex digits) long and shall have the value "00" when the sender is identified with an X.509 certificate. Other values of the initial substring may be defined in later revisions of this specification. When identifying the sender with an X.509 certificate, the subsequent substring shall use the "variable-length" encoding defined in Section 5.8.1 of [NIST SP800-56A] and shall contain (the hex encoding of) the length of the certificate in big-endian representation immediately followed by the (hex encoding) of the DER-encoded certificate. The length field shall always be two octets (i.e. 4 hex digits) long.


Representing such a complex parameter as a single hexBinary attribute is very cryptic. Can't we define PartyUInfo in a more xml-ish way e.g. as an element which can have subelements representing each part?  Then we can define a uniform mechanism to convert each part to a bit string.

Pratik