Re: [woes] Proposed charter, post-Quebec edition

Hal Lockhart <hal.lockhart@oracle.com> Mon, 08 August 2011 15:27 UTC

Return-Path: <hal.lockhart@oracle.com>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5C21F8AAC for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 08:27:57 -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 JBM7VSnPcFQ9 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 08:27:57 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2227E21F8A35 for <woes@ietf.org>; Mon, 8 Aug 2011 08:27:51 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p78FSDjY017260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Aug 2011 15:28:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p78FSBXO002533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 15:28:12 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p78FS5QZ012131; Mon, 8 Aug 2011 10:28:06 -0500
MIME-Version: 1.0
Message-ID: <f959ce73-617c-4170-9a1e-560eaaef7017@default>
Date: Mon, 08 Aug 2011 08:28:04 -0700
From: Hal Lockhart <hal.lockhart@oracle.com>
To: Sean Turner <turners@ieca.com>, woes@ietf.org
In-Reply-To: <4E3C3A35.70408@ieca.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 9.0.0.6627]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090202.4E400090.0130,ss=1,re=0.000,fgs=0
Cc: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [woes] Proposed charter, post-Quebec edition
X-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 15:27:57 -0000

Given the state of the art in integrity protection is in flux (e.g. new attacks, authenticated encryption modes) it seems foolish to limit integrity protection to two specific technologies.

Although there may be no intent to cover anything more than asymmetric key signatures and HMACs during the initial phase, the JSON metadata should be capable of representing other, present and future methods, at least to the extent we currently understand their requirements.

Hal

> -----Original Message-----
> From: Sean Turner [mailto:turners@ieca.com]
> Sent: Friday, August 05, 2011 2:45 PM
> To: woes@ietf.org
> Cc: Hal Lockhart; Paul Hoffman; Eric Rescorla
> Subject: Re: [woes] Proposed charter, post-Quebec edition
> 
> 
> On 8/4/11 4:41 PM, Hal Lockhart wrote:
> > +1
> >
> >> -----Original Message-----
> >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> >> Sent: Thursday, August 04, 2011 12:03 PM
> >> To: Eric Rescorla
> >> Cc: woes@ietf.org
> >> Subject: Re: [woes] Proposed charter, post-Quebec edition
> >>
> >>
> >>
> >> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
> >>
> >>> IMO, symmetric integrity protection is a useful 
> primitive, and it's
> >>> already part of the
> >>> JWT spec. I think all that's required here in the charter is to
> >>> wordsmith it to separate
> >>> out symmetric from asymmetric integrity algorithms,
> >>
> >> Current:
> >> 1) A Standards Track document specifying how to apply a
> >> JSON-structured digital signature to data, including (but not
> >> limited to) JSON data structures. "Digital signature" is
> >> defined as a hash operation followed by a signature operation
> >> using asymmetric keys.
> >>
> >> It sounds like you would prefer something like:
> >> 1) A Standards Track document specifying how to apply
> >> integrity protection to data, including (but not limited to)
> >> JSON data structures. This integrity protection can be
> >> achieved with both symmetric and asymmetric algorithms.
> >>
> >> Is that right?
> 
> I'm liking what Paul B. suggested but tweaked ever so slightly:
> 
> 1) A Standards Track document specifying how to ensure the integrity 
> and/or authenticity of data, including (but not limited to) JSON data 
> structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic 
> algorithms both need to be supported.
> 
> I'd like to not just call out integrity - and we should just call out 
> the HMAC-based algs because that's what folks really want to use (or 
> have I gotten this wrong?).
> 
> Any violent objections to this?
> 
> spt
>