Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition
"Richard L. Barnes" <rbarnes@bbn.com> Mon, 08 August 2011 21:11 UTC
Return-Path: <rbarnes@bbn.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 BC56121F8BE5 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 14:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.901
X-Spam-Level:
X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 zPmoB2rrDAh2 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 14:11:11 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 693E421F8BDB for <woes@ietf.org>; Mon, 8 Aug 2011 14:11:11 -0700 (PDT)
Received: from ros-dhcp192-1-51-80.bbn.com ([192.1.51.80]:51028) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1QqX6f-0005ob-1P; Mon, 08 Aug 2011 17:11:29 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <CA659998.D933%joe.hildebrand@webex.com>
Date: Mon, 08 Aug 2011 17:11:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C31C2F25-79DA-477A-8933-7CA5876810B3@bbn.com>
References: <CA659998.D933%joe.hildebrand@webex.com>
To: Joe Hildebrand <joe.hildebrand@webex.com>
X-Mailer: Apple Mail (2.1082)
Cc: "woes@ietf.org" <woes@ietf.org>
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 21:11:12 -0000
+1 This is exactly what the DNSSEC community has done. <http://tools.ietf.org/html/rfc6014> On Aug 8, 2011, at 3:48 PM, Joe Hildebrand wrote: > Agree. Algorithm agility is a must, but large numbers of supported > algorithms out of the gate are not. Having a small set of algorithms > widely-implemented will increase interoperability drastically, particularly > considering that in some of the target operating environments, we'll need to > wait for people with adequate cryptographic skills to help. > > I do really like the idea of splitting the MTI specification into a small > separate draft, so that it can be rev'd easily as needed. > > > On 8/8/11 1:04 PM, "John Bradley" <ve7jtb@ve7jtb.com> wrote: > >> Hal, >> >> JWE/JWS supports multiple algorithms. I haven't seen any argument to not >> have algorithm ajility. >> >> There was a mention of what algorithms should be MTI. I expect that >> discussion will continue. (It is still gong on for xmlenc/xmldeig over at >> W3C) >> >> We clearly need multiple algorithms, in my opinion. >> >> John B. >> On 2011-08-08, at 2:28 PM, 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. >>> >>> 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 >>>> >>> _______________________________________________ >>> 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 > > -- > Joe Hildebrand > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes
- 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