Re: [jose] Use of AES-HMAC algorithm - Consensus Request
"Vladimir Dzhuvinov / NimbusDS" <vladimir@nimbusds.com> Fri, 05 April 2013 08:58 UTC
Return-Path: <vladimir@nimbusds.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21421F9679 for <jose@ietfa.amsl.com>; Fri, 5 Apr 2013 01:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqIcEe+Wa8Vd for <jose@ietfa.amsl.com>; Fri, 5 Apr 2013 01:58:36 -0700 (PDT)
Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 727C121F89B2 for <jose@ietf.org>; Fri, 5 Apr 2013 01:58:31 -0700 (PDT)
Received: (qmail 15390 invoked from network); 5 Apr 2013 08:56:23 -0000
Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 5 Apr 2013 08:56:22 -0000
Received: (qmail 27565 invoked by uid 99); 5 Apr 2013 08:56:22 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 95.43.37.235
User-Agent: Workspace Webmail 5.6.34
Message-Id: <20130405015621.cc40c4f3d92d2001859047cd8cabb9ab.ac83af49ef.wbe@email07.europe.secureserver.net>
From: Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com>
To: "jose@ietf.org" <jose@ietf.org>
Date: Fri, 05 Apr 2013 01:56:21 -0700
Mime-Version: 1.0
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 08:58:38 -0000
+1 -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com -------- Original Message -------- Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request From: Mike Jones <Michael.Jones@microsoft.com> Date: Fri, April 05, 2013 1:13 am To: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org> I'm in favor of the change. I believe that this equivalent to issue http://trac.tools.ietf.org/wg/jose/trac/ticket/3 - correct? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, April 04, 2013 4:51 PM To: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request <chair> At the request of the editors, this is a formal consensus call on the first item in the list below. If there are objects to use a single long key rather than a KDF function for the AES-CBC/HMAC algorithm please speak up now. To date nobody has said that I was wrong to assume the consensus on that item. Call ends in one week. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: jose@ietf.org > Subject: [jose] Use of AES-HMAC algorithm > > <chair> > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up > with the > following set of issues that might need to be addressed as part of resolving > this issue. > > 1. Do we change from using KDC to having a double size key for the > algorithm? I think that there is probably a consensus that this > should be done. > > 2. Should IVs be prepended to the encrypted body as part of the > encoding steps? If so then this change should be universal. > > Doing so would eliminate one field from all of the encoding formats > which should be considered a plus. > Doing so would force code writers to understand how large the IV is > for all > algorithms as the IV would no longer be a separate item. > > 3. Should Authentication Tags be appended to the encrypted body as > part of the encoding steps? > > Doing so would eliminate one field from all of the encoding formats > which should be considered a plus. > Doing so would force code writers to understand how large the IV is > for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case > as either all recipient specific data would need to be excluded from > the authentication step or all of the recipient data would need to be > included for > by all recipients. > Changing how the recipient info is process is going to give a > performance benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that > it might > be a serious security flaw. > > 4. Should we reference the McGrew draft and provide text on how things > are changed or should we "copy" the draft into our text? > > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key > wrapping, does this change how we think about any of the above questions? > > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as > there is > no way to encode the three fields into the encrypted value unless with > use either a JSON structure in this location or we do use the single > appended binary output stream. The first approach leads to an > expansion of the field by > double base64 encoding which is highly undesirable. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Jim Schaad
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Dick Hardt
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Mike Jones
- Re: [jose] Use of AES-HMAC algorithm - Consensus … John Bradley
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Vladimir Dzhuvinov / NimbusDS
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Russ Housley
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Peck, Michael A
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Dick Hardt
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Matt Miller (mamille2)
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Nat Sakimura
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Edmund Jay
- Re: [jose] Use of AES-HMAC algorithm - Consensus … John Bradley