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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 04 August 2011 13:12 UTC

Return-Path: <hallam@gmail.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 966BA21F854E for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level:
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+0S8v6h0xJf for <woes@ietfa.amsl.com>; Thu, 4 Aug 2011 06:12:43 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0721F8549 for <woes@ietf.org>; Thu, 4 Aug 2011 06:12:43 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1186722gxk.31 for <woes@ietf.org>; Thu, 04 Aug 2011 06:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/inTjmZ89lqNouQ5y7Bj6Dl/019rwpOdMhsnkiEhyX8=; b=gaWLkP1G/e6ABqU3wq3PvhYUKD4t4l/9K9bMJlbj0L0wBdDJqp35NyYDYEwAdMMwQU 2J9e17SVMM0OHpDe57ipikxRZeHa67csUMz1cINbHHdmKOw20hIDAt5zBE+14pJfSRqK thyVGmy/skaxRk6f/rTjcNxHdETWvgsNIZ9MA=
MIME-Version: 1.0
Received: by 10.101.190.6 with SMTP id s6mr679186anp.50.1312463577977; Thu, 04 Aug 2011 06:12:57 -0700 (PDT)
Received: by 10.100.34.3 with HTTP; Thu, 4 Aug 2011 06:12:57 -0700 (PDT)
In-Reply-To: <4E3A9885.50600@ieca.com>
References: <4F25253E-A870-4956-AAB1-20890B655984@vpnc.org> <4E3A9885.50600@ieca.com>
Date: Thu, 4 Aug 2011 09:12:57 -0400
Message-ID: <CAMm+LwjpNMqO3AG6rOsrRgV81M8JJ7V9+uHUAMsmARxr-TCWxg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary=00163691fc2d5892d704a9adbd84
Cc: woes@ietf.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: Thu, 04 Aug 2011 13:12:44 -0000

On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <turners@ieca.com> wrote:

> On 8/2/11 7:13 PM, Paul Hoffman wrote:
>
>> Here is a proposal for the charter based on the discussion in the BoF last
>> week and later discussion with Sean Turner. Comments, praise, scorn, etc.,
>> are welcome.
>>
>> --Paul and Richard
>>
>> Javascript Object Signing and Encrypting (jose)
>> ==============================**=================
>>
>> Background
>> ----------
>>
>> Javascript Object Notation (JSON) is a text format for the serialization
>> of structured data described in RFC 4627. The JSON format is often used for
>> serializing and transmitting structured data over a network connection. With
>> the increased usage of JSON in protocols in the IETF and elsewhere, there is
>> now a desire to offer security services such as encryption and digital
>> signatures for data that is being carried in JSON format.
>>
>> Different proposals for providing such security services have already been
>> defined and implemented. This Working Group's task is to standardize two
>> security services, encrypting and digitally signing, in order to increase
>> interoperability of security features between protocols that use JSON.  The
>> Working Group will base its work on well-known message security primitives
>> (e.g., CMS), and will solicit input from the rest of the IETF Security Area
>> to be sure that the security functionality in the JSON format is correct.
>>
>> This group is chartered to work on four documents:
>>
>> 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.
>>
>
> I just want to make sure that we agree now that a digital signature is a
> hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've seen
> a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a
> digital signature; one called it a symmetric key based digital signature
> algorithm (note this phrase didn't get through the IESG).


An HMAC is not a digital signature, but the spec definitely needs to be able
to cover MAC based authentication.


I know that public key is getting easier as far as computation goes. But for
many applications the non-repudiation you get in digital signatures is
actually undesirable.

There are interesting tricks you can do with symmetric crypto that are much
harder to do in public key and end up with some scheme that only 50
academics in the world can follow and has a security proof that rest on
rather esoteric assumptions.

-- 
Website: http://hallambaker.com/