W3C

List of comments on “XML Encryption Syntax and Processing Version 1.1” (dated 18 October 2012)

Quick access to

There are 2 comments (sorted by their types, and the section they are about).

general comment comments

Comment LC-2734
Commenter: Juraj Somorovsky <juraj.somorovsky@rub.de> (archived message)
Context: 6. Security Considerations 6.1 Chosen-Ciphertext Attacks A... (New security consideration)
assigned to Frederick Hirsch
Resolution status:

Consider backward compatibility attacks,
http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2735
Commenter: Juraj Somorovsky <juraj.somorovsky@rub.de> (archived message)
Context: in
assigned to Frederick Hirsch
Resolution status:

Frederick

yes, we were thinking about including some concrete examples how a
secure key derivation should (must) look like. But we are not experts in
this concrete field and for the construction of a secure derivation we
would need more time...

Best Regards
Juraj

On 12/04/2012 04:05 PM, Frederick.Hirsch@nokia.com wrote:
> Juraj
>
> I think what you are saying is that it would help to clarify how key derivation using the algorithm identifier is done. We have definitions for key derivation functions in the spec as well as algorithm ids. Are you suggesting that we need to be clear how to create the master secret, e.g. prepend the master key with the algorithm id, etc? What kind of text would you be suggesting?
>
> If this is the case, would an informative example suffice?
>
> I'm concerned because the specification is already "frozen" and we are on path to publish final recommendation. We decided to incorporate the security consideration at the last minute since is informative, but adding normative text would imply a new cycle of interop testing, repeat of all process steps, and a significant delay in publication, which may not be possible.
>
> Perhaps there is a way we can avoid another cycle yet address the concern.
>
> regards, Frederick
>
> Frederick Hirsch, Nokia
> Chair XML Security WG
>
>
>
> On Dec 4, 2012, at 9:25 AM, ext Juraj Somorovsky wrote:
>
>> Hi Frederick,
>>
>> thanks for CC'ing us, there are our thoughts.
>>
>> On 12/03/2012 03:51 PM, Frederick.Hirsch@nokia.com wrote:
>>> 2. Implementations using symetric keys should not use the same key material for different algorithms, even if serving the same purpose. Key derivation based on a single key and the algorithm identifier can be used to accomplish this, for example.
>>> 3. Implementations that plan to use the same symetric key for both confidentiality and integrity functions should use it as the basis for a key derivation producing different keys for those functions.
>> We are puzzled what is the difference between these two points.
>> Is 2. meant to be specifically for AES-CBC / AES-GCM and 3. specifically
>> for AES-CBC / HMAC ?
>>
>> If yes, would it be not better readable to summarize 2. and 3. into one
>> point?
>>> On a related note, should we define in XML Encryption 1.1 the specific key derivation function to derive a key based on algorithm identifier and key? I'm concerned about what this means for interop and progressing the specification. If we do need this I suggest we might progress it as an independent specification, but am not sure we need to do this. Thoughts?
>> We think it is necessary to include the key derivation function into the
>> standard (for interoperability reasons as well as for better understanding).
>>
>> Thank you
>> Juraj and Tibor
>
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org