- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 27 Feb 2012 20:55:08 +0000
- To: <cantor.2@osu.edu>
- CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
I have taken a look at the web cryptography group that is in the chartering process [1]. It is still in the early stages but seems to have low level crypto functions along the lines of the DOMCrypt input, including hash, HMAC, sign/verify and encrypt/decrypt but no mention of authenticated encryption [2]. I can raise the issue... regards, Frederick Frederick Hirsch Nokia [1] http://www.w3.org/2011/11/webcryptography-charter.html [2] http://www.faqs.org/rfcs/rfc6476.html On Feb 27, 2012, at 2:36 PM, ext Cantor, Scott wrote: > I checked with JohnB about JOSE and JWT plans, and the impression I have is that they have goals involving combining encryption and sender authentication/verification in one layer that I don't think are a fit for XML Encryption, which keeps the authentication of a message separate from any use of integrity protection in the data cipher. There are also format and message size considerations that aren't applicable to this spec. > > I think it's unlikely we'd end up with the same algorithm and ciphertext layout in both places, so trying to quickly get consensus on a single approach isn't likely and shouldn't hold up a decision about 1.1. I would expect that decision therefore to be that if I/we want to do a separate document to describe a new algorithm for HMAC+CBC along the lines of the CMS RFC, that's the way forward, without holding up 1.1. > > But again I will note that formal compliance with AES-GCM as MTI will be effectively very limited to vendors and Java tools (and many of those Java stacks have to interop with people using other toolkits, so actual wire interop will be left at CBC). > > It might also be instructive for somebody to investigate the "crypto in the browser" work going on in W3C. > > -- Scott > >
Received on Monday, 27 February 2012 20:55:48 UTC