Re: padded AES key wrap

+1

We want what is ready to be included in the draft for review, what  
requires more work to be an issue for the WG.

Asking whether this should be included has generated a clear response  
that it needs more work. Ditto for the other schema issue.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 24, 2009, at 5:58 AM, ext Thomas Roessler wrote:

> Putting this into a later draft works for me.
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
> On 24 Feb 2009, at 10:22, Brian LaMacchia wrote:
>
>> Thomas,
>>
>> It is really that critical that this new draft key wrap alg be
>> present in the FPWD?  Can't we add it later (still within the
>> publication process), after the IETF draft has had a bit more bake
>> time?  It's a -00 draft after all.  Just trying to understand the
>> rush to include this.  Perhaps it's just me, but I'd like to keep to
>> a minimum the amount of stuff we're slamming into the draft at the
>> very last minute in order to make the FPWD cut-off.  If it's not
>> critical (and I don't think it is), perhaps we should just hold it
>> for now.  (And we can always put out a SPWD, right?)
>>
>>                                      --bal
>>
>> -----Original Message-----
>> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org
>> ] On Behalf Of Thomas Roessler
>> Sent: Monday, February 23, 2009 7:53 PM
>> To: XMLSec WG Public List
>> Subject: padded AES key wrap
>>
>> When we last talked about the padded AES key wrap proposed by Housley
>> and Dworkin, the question came up whether or not that algorithm gives
>> the same values as its unpadded cousin, for the key lengths that are
>> supported by both.
>>
>> The spec:
>>
>>  http://tools.ietf.org/html/draft-housley-aes-key-wrap-with-pad-00
>>
>> ... makes clear that the values will be different, due to a different
>> choice of an alternate initial value; see section 3.
>>
>> I suggest that we include a reference to this algorithm (with
>> algorithm URI) in the FPWD for Encryption, as an optional algorithm.
>> (I have some thoughts about optional vs mandatory, but think it's too
>> late to do anything about them till we publish the FPWD.)
>>
>> Specifically, I propose adding:
>>
>>> 5.6.4 AES Key Wrap with Padding
>>>
>>> Identifiers and Requirements
>>> http://www.w3.org/2009/xmlenc11#kw-aes-128-pad      (OPTIONAL)
>>> http://www.w3.org/2009/xmlenc11#kw-aes-192-pad      (OPTIONAL)
>>> http://www.w3.org/2009/xmlenc11#kw-aes-256-pad      (OPTIONAL)
>>>
>>> These identifiers are used for symmetric key wrapping using the AES
>>> key wrap with padding algorithm with a 128, 192, and 256 bit AES key
>>> encrypting key, respectively.
>>>
>>> Implementation of AES key wrap with padding is defined in [draft-
>>> housley].  The algorithm is defined for inputs between 9 and 2^32
>>> octets.  Unlike the unpadded AES Key Wrap algorithm, the input
>>> length is not constrained to multiples of 64 bits (8 octets).
>>>
>>> Note that the wrapped key will be distinct from the one generated by
>>> the unpadded AES Key Wrap algorithm, even if the input length is a
>>> multiple of 64 bits.
>>
>> Bibliography entry:
>>
>>> [draft-housley] Advanced Encryption Standard (AES) Key Wrap
>>> Algorithm with Padding. R. Housley, M. Dworkin. Internet-Draft (Work
>>> in Progress), 29 January 2009. http://tools.ietf.org/html/draft-housley-aes-key-wrap-with-pad-00
>>
>>
>> Regards,
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

Received on Tuesday, 24 February 2009 14:18:37 UTC