Re: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH

Stefan Santesson <> Fri, 22 March 2019 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 219C3130E8F for <>; Fri, 22 Mar 2019 01:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cm80nxpX7_2u for <>; Fri, 22 Mar 2019 01:43:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE803127287 for <>; Fri, 22 Mar 2019 01:43:52 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 71BBA1F19808 for <>; Fri, 22 Mar 2019 09:43:40 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 39D9B794786 for <>; Fri, 22 Mar 2019 09:43:40 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 34C331349BB0 for <>; Fri, 22 Mar 2019 09:43:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with LMTP id 2mU6TMJWsvC4 for <>; Fri, 22 Mar 2019 09:43:39 +0100 (CET)
X-Loopia-Auth: user
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 8A0381349B8F for <>; Fri, 22 Mar 2019 09:43:39 +0100 (CET)
User-Agent: Microsoft-MacOutlook/
Date: Fri, 22 Mar 2019 09:43:38 +0100
From: Stefan Santesson <>
Message-ID: <>
Thread-Topic: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Mar 2019 08:43:55 -0000

Just for reference.

ConcatKDF is defined in NIST SP 800-56A. Here is Bouncycastle implementation of ConcatKDF:
OtherInfo is the concatenation of all ConcatKDF parameters ==> AlgorithmID || PartyUInfo || PartyVInfo {|| SuppPubInfo }{|| SuppPrivInfo }

As you can see, OtherInfo is a byteArray and all bits of its content is used in the ConcatKDF key generation process.

IMO XML Enc should limit the use of ConcatKDF to use only full bytes of data without padding as parameters. The addition of a padding counter byte is a mistake that will cause interop issues, but that is too late to change now.

Stefan Santesson 

On 2019-03-22, 09:29, "secdir on behalf of Stefan Santesson" < on behalf of> wrote:

    I'm looking for anyone with an insight in this issue, anyone experiencing interop issues or anyone willing to seek a solution.
    The XML Encryption standard has some errors and lack of specification with regard to the use of the Key Derivation Function ConcatKDF
    The example on ECDH use at: express the ConcatKDF parameters as AlgorithmID="00" PartyUInfo="" PartyVInfo=""
    This is inconsistent with the same specification definition of how to use ConcatKDF and how to specify its parameters:
    Further. ConcatKDF parameters stors bit strings of arbitrary length in chunks of byte data. The bitstring length may not be devisable by 8. Implementers are supposed to strip padding bytes and send the actual bit strings as ConcatKDF input.
    Current implementations of ConcatKDF, in particular from Bouncycastle can only handle ConcatKDF input in the form of byte array.
    Implementations I have seen have fed ConcatKDF parameters from XML enc directly into ConcatKDF without attempting to strip padding bits and length byte from the data. All implementations must have this right or nothing will work.
    There are some serious issues threaten interoperability here:
     - Implementers may be tricked to send illegal parameter values following the example in 5.6.4
     - Implementers are supposed to strip out padding bits, but if they do, they may end up with data they can't use because the result can't be stored in bytes.
    Apparently there is a need for further clarifications here, but the XML Security group of W3C is closed and I have found no way to send them feedback.
    Is there anyone here who have insights in this issue or know how to solve it?
    Stefan Santesson 
    secdir mailing list