- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 30 Oct 2001 12:16:14 -0500
- To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- cc: XML Encryption WG <xml-encryption@w3.org>
Hi, From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de> Date: Mon, 29 Oct 2001 13:44:21 +0100 To: reagle@w3.org Cc: XML Encryption WG <xml-encryption@w3.org> Message-ID: <3635681325.1004363061@pinkpanther> >Hi Joseph, > >in [1], I did not find any information about what padding mechanism we use? >PKCS7/PKCS5? This depends on which algorithm you are talking about. For TripleDES, and AES, I suppose we should continue to go with whatever S/MIME does / will do. For key transport, the padding is explicitly given for RSA 1.5. It's complicated for RSA-OAEP but is given in the referenced RFC. For Symmetric Key Wrap, the normal case of a TripleDES wrap of a TripleDES key or any key that is a multile of 64 bit (i.e., all AES keys) needs no padding and one would assume that NSA will define appropriate padding for AES wrapping of AES keys. Since a TripleDES key is the same size (192 bits) as an allowed AES key, it will presumably be possible to AES wrap it like a 192 bit AES key. However, I suppose, that we should either restrict TripleDES wrapping to keys that are a multiple of 64 bits or say how to pad other lengths. For AES, I'd prefer not to change any text until we see the NSA recommendation. >And for AES which allows block sizes of 128, 192 and 256 bit, we should >explicitly state that we use a block size of 128 bit (OK, the IV is 128 bit >and that should be a hint for the block size, but writing it down would be >clearer). The (draft) NIST standard allows only block size 128 bits, but there is no harm in mentioning this explicitly. >Best regards, >Christian Thanks, Donald >[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
Received on Tuesday, 30 October 2001 12:18:31 UTC