[woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

Hal Lockhart <hal.lockhart@oracle.com> Mon, 08 August 2011 18:28 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 829ED21F8B9A for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 11:28:31 -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=[AWL=0.000, 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 Izi4358raYVx for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 11:28:30 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 83C5821F8B8B for <woes@ietf.org>; Mon, 8 Aug 2011 11:28:30 -0700 (PDT)
Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p78ISrhO024196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Aug 2011 18:28:55 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p78ISqNa010586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 18:28:53 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p78ISlen011974; Mon, 8 Aug 2011 13:28:47 -0500
MIME-Version: 1.0
Message-ID: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
Date: Mon, 8 Aug 2011 11:28:46 -0700 (PDT)
From: Hal Lockhart <hal.lockhart@oracle.com>
To: Jeremy Laurenson <jlaurens@cisco.com>, woes@ietf.org
In-Reply-To: <2454ACF9-17E5-41D3-A9D9-57B5BC51FBFC@cisco.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: rtcsinet22.oracle.com [66.248.204.30]
X-CT-RefId: str=0001.0A090206.4E402AE8.0031,ss=1,re=0.000,fgs=0
Subject: [woes] Support multiple Crypto algorithms? was RE: 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 18:28:31 -0000

There seems to be a position forming around the idea that woes/joes/jose should specify (perhaps even design) a single algorithm (perhaps one for sign and one for encrypt). I presume that means that if in future it was necessary to use a different algorithm we would just start over and write a new spec.

I am not in favor of this, but I concede that it would simplify things in this group a lot.

If there was only one algorithm, there is no need for any JSON metadata about what the algorithm is being used.
All we need is a way to indicate what is signed or encrypted and something that says this is a JOES signature (or encryption) and perhaps some kind of indication of what key was used.

If we were to specify only one algorithm, but provide metadata to indicate the algorithm, others will use additional, unspecified algorithms, just as people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which only includes DES.

I won't bother to list the many (many, many) reasons why a single algorithm is unlikely to fly, unless it turns out a lot of people are really committed to that view. 

Instead, I suggest we say explicitly say that multiple algorithms will be possible, but one will be MTI. It wouldn't hurt to also say we are not going to design any new algorithms, but simply provide means to specify which existing one is being used.

Hal

> -----Original Message-----
> From: Jeremy Laurenson [mailto:jlaurens@cisco.com]
> Sent: Saturday, August 06, 2011 12:31 AM
> To: woes@ietf.org
> Subject: Re: [woes] Proposed charter, post-Quebec edition
> 
> 
> From a Javascript dev perspective, specifying an algorithm 
> will make it a hell of of lot easier to implement, instead of 
> having to potentially account for multiples.
> 
> Lets use the example of a web app that aggregates social 
> media data - just for giggles - and uses WOES to secure the 
> communications to well-defined interfaces
> 
> If multiple vendors' websites implement WOES/JOES/JOSE with 
> different algorithms, it becomes more complex vs a single, 
> consistent one.
> 
> 
> 
> 
> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
> 
> > 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
> >> 
> > _______________________________________________
> > woes mailing list
> > woes@ietf.org
> > https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes
>