- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 17 Mar 2009 13:21:44 +0100
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: Brian LaMacchia <bal@exchange.microsoft.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Per ACTION-224, I've added the text to the current editor's draft. -- Thomas Roessler, W3C <tlr@w3.org> On 24 Feb 2009, at 15:17, Frederick Hirsch wrote: > +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, 17 March 2009 12:21:55 UTC