Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1D1270AE; Fri, 20 Apr 2018 04:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr-qA3lcHrRl; Fri, 20 Apr 2018 04:03:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022CB1250B8; Fri, 20 Apr 2018 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3KB39FW027632; Fri, 20 Apr 2018 13:03:09 +0200 (CEST) Received: from client-0174.vpn.uni-bremen.de (client-0174.vpn.uni-bremen.de [134.102.107.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40SCd92Wz1zDXFp; Fri, 20 Apr 2018 13:03:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Fri, 20 Apr 2018 13:03:08 +0200 Cc: Scott Arciszewski , cfrg@ietf.org, jose@ietf.org X-Mao-Original-Outgoing-Id: 545914982.158986-79cbfd1956e01b70884143440ab5007d Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Neil Madden X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 11:03:15 -0000 On Apr 20, 2018, at 12:49, Neil Madden wrote: >=20 > insecure implementations of old standards don=E2=80=99t go away = because you introduce a new standard Exactly. If we have to invent a new standard each time an existing standard is = implemented with a security flaw, we have a lot of work to do. Insecure implementations exist even of standards such as TLS. Usually = the strategy is to fix the implementations. (It is also a good idea to = envision what implementers will mess up when creating a new standard. = But there are limits to that approach.) One of the objectives in the definition of COSE was to avoid some of the = pitfalls of JOSE. There is also work ongoing to document the security considerations of = JOSE better, e.g., draft-ietf-oauth-jwt-bcp. I=E2=80=99d like to focus the energy that appears to be visible here on = agreeing good SIV constructions and getting them registered with COSE. Gr=C3=BC=C3=9Fe, Carsten