This document:Public document·View comments·Disposition of Comments·
Nearby:XML Security Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-2734 LC-2735
There are 2 comments (sorted by their types, and the section they are about).
Consider backward compatibility attacks, http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/
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 >
Add a comment.