- From: Magnus Nystrom <mnystrom@microsoft.com>
- Date: Fri, 8 Jan 2010 23:01:17 +0000
- To: XMLSec WG Public List <public-xmlsec@w3.org>
- Message-ID: <1081D4CDDC85CF4491AFD941A52242EF4B2741C3@TK5EX14MBXW651.wingroup.windeploy.ntde>
All, This is in response to ACTION-451 that Brian and I got during this week's call. We suggest replacing the last sentence of the AES-GCM section: "AES-GCM is used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified Authentication Tag, and fail if they don't match." With: For the purposes of this specification, AES-GCM shall be used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified Authentication Tag, and fail if they don't match. For details on the implementation of AES-GCM, see [SP800-38D]. The reasons for the suggested change are: a) AES-GCM is not, as the current text implies, only used with a 96-bit IV and 128 bit tag (see e.g. RFC 5084), and b) the text currently in the spec is not sufficient anyway to implement AES-GCM, it really only specifies constraint applicable to 1.1. -- Magnus
Received on Friday, 8 January 2010 23:01:51 UTC