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

Sean Turner <turners@ieca.com> Fri, 05 August 2011 18:16 UTC

Return-Path: <turners@ieca.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 E758721F8B72 for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 11:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.238
X-Spam-Level:
X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
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 OuFnAuMCi73A for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 11:16:17 -0700 (PDT)
Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by ietfa.amsl.com (Postfix) with SMTP id EE0E721F8B46 for <woes@ietf.org>; Fri, 5 Aug 2011 11:16:16 -0700 (PDT)
Received: from [98.139.212.152] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2011 18:16:33 -0000
Received: from [98.139.212.248] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2011 18:16:33 -0000
Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 05 Aug 2011 18:16:33 -0000
X-Yahoo-Newman-Id: 136544.73470.bm@omp1057.mail.bf1.yahoo.com
Received: (qmail 97483 invoked from network); 5 Aug 2011 18:16:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312568192; bh=i5SZOmL+7p0AiPyl5r5EBZhUj+cDMThBAW15D/7N+1k=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vi4qVE2gqQ8qXXosCIwvWpCRX4DKMWbIisanZF63fn+lOJxY20lG9jBHNwoMjPjNyLYnkwdxRy7HSywSzAxoJwciUXiX+gcTEav+vJCkaIChhZYld10mv8eAArBhmZUKVZuGQQhThHQ76WCAJpFsmoloAs3YOEgm5iChsc8jbn0=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: ahn_kxYVM1khbsg495gkapbCvNGTcFg6gf8MD8sGseQqf_e bvarcGW3ZS0xRXvyARylSYbQbphdU7g9dpvFHyP0LhPBSxNxpNbMKvbjQUCz pMMbDcLs0p1hVzi2qoJPKXtIlYrvnTKBzu0bylk3zFP_UCHkEOXpuC0bc.He LTSS.U1V40F7uQBNJeTgzp1WrNJsP7upF64uwLUHrYbOF_ClPx0kE07NJrBv 2pFbaw69dVAPp4_esVpsqXCQA5f.wdpFT6BdUx8rY2ccP3O522jVQXkOKZ0z J0ey6hRJRzKn_LMpGiNfUayjZNVMze.GrrK_6RmwsoEFwDJw34NMTDfZKmst AXO_GGyy5coZhhGJoKkDlZ8cal82PT5lYwVSdVU3G6I3ch.vDT_C6ju.e2m_ IfXsVw9yvM_sXIJAGpOoMH4J7xoiWJdmFZXYBNIpZoVfG5C5ilsZ9IhtGcRE tAgCj_drFJRJiwZLOUlw-
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from thunderfish.westell.com (turners@96.231.128.54 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 05 Aug 2011 11:16:31 -0700 PDT
Message-ID: <4E3C337E.6050205@ieca.com>
Date: Fri, 05 Aug 2011 14:16:30 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: John Bradley <ve7jtb@ve7jtb.com>
References: <4F25253E-A870-4956-AAB1-20890B655984@vpnc.org> <4E3A9885.50600@ieca.com> <CAMm+LwjpNMqO3AG6rOsrRgV81M8JJ7V9+uHUAMsmARxr-TCWxg@mail.gmail.com> <8EF83897-EE6B-40C0-B1B6-79A03B38EFD1@ve7jtb.com>
In-Reply-To: <8EF83897-EE6B-40C0-B1B6-79A03B38EFD1@ve7jtb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 05 Aug 2011 18:16:18 -0000

So I'll bite on this ;)

I think we can write the spec to require a particular algorithm choice, 
but it might make more sense to define the options and then allow the 
environment in which the solution will be used to specify it's 
requirements.  But, I believe that is a discussion we'll have while 
writing the spec.

spt

On 8/4/11 9:29 AM, John Bradley wrote:
> HMAC is requirement for adoption in the JWS use cases.
>
> If we want to describe it as something other than a "Qualified Digital
> Signature", that is fine as long as it is MTI:)
>
> John B.
>
>
> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>
>>
>>
>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <turners@ieca.com
>> <mailto: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/
>>
>> _______________________________________________
>> woes mailing list
>> woes@ietf.org <mailto:woes@ietf.org>
>> https://www.ietf.org/mailman/listinfo/woes
>