- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 7 Jan 2013 19:49:15 +0100
- To: Donald Eastlake <d3e3e3@gmail.com>
- Cc: frederick.hirsch@nokia.com, Juraj Somorovsky <juraj.somorovsky@rub.de>, public-xmlsec@w3.org, tibor.jager@gmail.com
We're all confused about that. Not sure what happened there. -- Thomas Roessler, W3C <tlr@w3.org> (@roessler) On 2013-01-07, at 19:47 +0100, Donald Eastlake <d3e3e3@gmail.com> wrote: > Hi, > > I'm unclear why my email address is given as the response address... > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Mon, Jan 7, 2013 at 1:37 PM, <frederick.hirsch@nokia.com> wrote: >> Dear Juraj Somorovsky , >> >> The XML Security Working Group has reviewed the comments you sent [1] on >> the Last Call Working Draft [2] of the XML Encryption Syntax and Processing >> Version 1.1 published on 18 Oct 2012. Thank you for having taken the time >> to review the document and to send us comments! >> >> The Working Group's response to your comment is included below. >> >> Please review it carefully and let us know by email at d3e3e3@gmail.com if >> you agree with it or not before 11 January 2013. In case of disagreement, >> you are requested to provide a specific solution for or a path to a >> consensus with the Working Group. If such a consensus cannot be achieved, >> you will be given the opportunity to raise a formal objection which will >> then be reviewed by the Director during the transition of this document to >> the next stage in the W3C Recommendation Track. >> >> Thanks, >> >> For the XML Security Working Group, >> Thomas Roessler >> W3C Staff Contact >> >> 1. http://www.w3.org/mid/50BE1B56.90406@rub.de >> 2. http://www.w3.org/TR/2012/WD-xmlenc-core1-20121018/ >> >> >> ===== >> >> Your comment on : >>> 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 >>>> >> >> >> Working Group Resolution (LC-2735): >> Defer definition of key derivation based on algorithm identifier to a >> version 1.2 of XML Encryption >> >> (see item #1 in CfC >> http://lists.w3.org/Archives/Public/public-xmlsec/2012Dec/0015.html ) >> >> ---- >> >> >
Received on Monday, 7 January 2013 18:49:29 UTC