Re: Re: updated XML Encryption 1.1 editors draft for 6.1.3 security consideration ( LC-2735)

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 22:53:27 UTC