Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition
John Bradley <ve7jtb@ve7jtb.com> Mon, 08 August 2011 17:37 UTC
Return-Path: <ve7jtb@ve7jtb.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 0959C21F8B51 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 10:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 mmNHDYu9BDEI for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 10:37:45 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E258D21F8B4A for <woes@ietf.org>; Mon, 8 Aug 2011 10:37:44 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1228073qwc.31 for <woes@ietf.org>; Mon, 08 Aug 2011 10:37:45 -0700 (PDT)
Received: by 10.229.18.77 with SMTP id v13mr4537071qca.56.1312825065697; Mon, 08 Aug 2011 10:37:45 -0700 (PDT)
Received: from [192.168.1.213] ([190.22.90.82]) by mx.google.com with ESMTPS id d12sm4534945qcd.2.2011.08.08.10.37.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 10:37:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_F1ED0488-305E-47F6-ACA2-320AE606F946"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <1312823364.5484.21.camel@dynamo>
Date: Mon, 08 Aug 2011 13:38:03 -0400
Message-Id: <DD481E68-7917-4F79-86E2-244A3D87FFAD@ve7jtb.com>
References: <0c100e09-dad3-4cc5-87a2-b42f1f6c834b@default> <4E4011CC.7030903@adida.net> <1312823364.5484.21.camel@dynamo>
To: "Paul C. Bryan" <paul.bryan@forgerock.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: woes@ietf.org
Subject: Re: [woes] Naked Public Key, 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 17:37:46 -0000
No argument on that. We just can't assume that it is trivial to reemployment PKIX X.509 processing in all new environments. Using public keys without PKIX, is a simpler task. Where we need to develop new libraries, using establishd cryptographic methods should be the goal. JWE/JWS had no intention of deviating from those norms and inventing new algorithms. John B. On 2011-08-08, at 1:09 PM, Paul C. Bryan wrote: > On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote: >> >> On 8/8/11 8:36 AM, Hal Lockhart wrote: >> > >> > I am with Eric here. I would like to explicitly state that I think it >> > is NOT desirable to do anything which encourages people to do new >> > implementations of crypto operations. The corollary is that the spec >> > should specify objects in formats which make them easy to be passed >> > as arguments to existing libraries, especially libraries which are >> > likely to be present in the target environment. >> >> I think this may miss some important use cases. We're using JWT/JWS at >> https://browserid.org, and we need to do all of the crypto in >> JavaScript. JavaScript-based crypto, and crypto in other programming >> languages in general, is likely to be a growing need. So, "no new >> implementations" is unrealistic. There will be new implementations. >> There have to be. > I think the point is that one should use existing, proven software libraries to implement the cryptography wherever possible—JOSE should not necessitate a novel application of cryptography to achieve the charter objectives. If no such library exists in a particular programming/runtime environment, then obviously one would need to be developed. That said, I would suggest that such a new implementation focus on implementing the cryptographic functions much the way they are implemented in other environments, and allow JOSE implementations to build upon that. > >> If we force these new implementations to bear the full complexity of >> X.509, then we're introducing security risk. It would be much better if >> we had a simpler, JSON-focused certificate format. >> >> We don't get to choose whether there will be new implementations. We >> only get to choose how simple those have to be. >> >> -Ben >> _______________________________________________ >> 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
- 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