Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
"Paul C. Bryan" <paul.bryan@forgerock.com> Mon, 08 August 2011 19:20 UTC
Return-Path: <paul.bryan@forgerock.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 E568F5E8001 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 VHmU-AoblP1E for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 12:20:42 -0700 (PDT)
Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com [207.126.144.137]) by ietfa.amsl.com (Postfix) with SMTP id 5A8F121F8560 for <woes@ietf.org>; Mon, 8 Aug 2011 12:20:40 -0700 (PDT)
Received: from mail-pz0-f44.google.com ([209.85.210.44]) (using TLSv1) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKTkA3GUN8IN5Ri2QXEqTmnNlpwUniwwNd@postini.com; Mon, 08 Aug 2011 19:21:08 UTC
Received: by mail-pz0-f44.google.com with SMTP id 36so3289273pzk.31 for <woes@ietf.org>; Mon, 08 Aug 2011 12:20:57 -0700 (PDT)
Received: by 10.142.136.5 with SMTP id j5mr6004373wfd.18.1312831257081; Mon, 08 Aug 2011 12:20:57 -0700 (PDT)
Received: from [192.168.1.177] (S0106001346fbe4af.vf.shawcable.net [174.1.44.35]) by mx.google.com with ESMTPS id i9sm6206512pbk.4.2011.08.08.12.20.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 12:20:56 -0700 (PDT)
From: "Paul C. Bryan" <paul.bryan@forgerock.com>
To: woes@ietf.org
In-Reply-To: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
References: <50a36a05-edfd-4469-8b9e-047ca28df62a@default>
Content-Type: multipart/alternative; boundary="=-iNkFK04kZGa6VOzG8o7y"
Date: Mon, 08 Aug 2011 12:21:01 -0700
Message-ID: <1312831261.5484.40.camel@dynamo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Subject: Re: [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 19:20:43 -0000
On Mon, 2011-08-08 at 11:28 -0700, Hal Lockhart wrote: > 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. If such a position is actually forming, I'd like to know why we'd want to pre-bake obsolescence into the spec. > I am not in favor of this, but I concede that it would simplify things > in this group a lot. If by simplify you mean thinning out the number of people who will find it useful, perhaps. ;-) > If there was only one algorithm, there is no need for any JSON > metadata about what the algorithm is being used. True, but perhaps at the very least we'd need some kind of metadata saying what version of JOSE is being used, if nothing more than to determine what version of what cipher(s) it supports. > 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. This may not be enough, especially when JOSE undergoes a revision. > 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 think if we establish a minimum supported set, with extensibility (i.e. cipher suite can be specified), we retain core interoperability while not throwing out the standard when the core ciphers prove unsuitable. > 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. +1 > 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. +1, though I suggest we may codify a handful of well-used suites while possibly making one mandatory to implement. Paul
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Thomas Hardjono
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Peter Saint-Andre
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Matt Miller
- Re: [woes] Proposed charter, post-Quebec edition John Bradley
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Paul Hoffman
- Re: [woes] Proposed charter, post-Quebec edition Paul C. Bryan
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Proposed charter, post-Quebec edition Richard L. Barnes
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- [woes] Naked Public Key, was: RE: Proposed charte… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Proposed charter, post-Quebec edition Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Eric Rescorla
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Sean Turner
- Re: [woes] Proposed charter, post-Quebec edition Sean Turner
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Proposed charter, post-Quebec edition Jeremy Laurenson
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Phillip Hallam-Baker
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Joe Hildebrand
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Leif Johansson
- Re: [woes] Proposed charter, post-Quebec edition Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Paul C. Bryan
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Ben Adida
- Re: [woes] Naked Public Key, was: RE: Proposed ch… John Bradley
- Re: [woes] Naked Public Key, was: RE: Proposed ch… Hal Lockhart
- [woes] Support multiple Crypto algorithms? was RE… Hal Lockhart
- Re: [woes] Support multiple Crypto algorithms? wa… John Bradley
- Re: [woes] Support multiple Crypto algorithms? wa… Paul C. Bryan
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Richard L. Barnes
- Re: [woes] Support multiple Crypto algorithms? wa… Phillip Hallam-Baker
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand
- Re: [woes] Support multiple Crypto algorithms? wa… Thomas Hardjono
- Re: [woes] Support multiple Crypto algorithms? wa… Joe Hildebrand