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

[Stefan Santesson <[e-mail]>]

Just for reference.

ConcatKDF is defined in NIST SP 800-56A. Here is Bouncycastle implementation of ConcatKDF: https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/kdf/ConcatenationKDFGenerator.java
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" <[e-mail] on behalf of [e-mail]> wrote:

    Hi,
    
    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: https://www.w3.org/TR/xmlenc-core1/#sec-ECDH-ES 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: https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF
    
    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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/secdir
    wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview