Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

John Bradley <ve7jtb@ve7jtb.com> Mon, 08 August 2011 17:06 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 C0BB921F855D for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 10:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level:
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 33wzbPBM3NDh for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 10:06:59 -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 CE84F21F854D for <woes@ietf.org>; Mon, 8 Aug 2011 10:06:58 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1211534qwc.31 for <woes@ietf.org>; Mon, 08 Aug 2011 10:07:24 -0700 (PDT)
Received: by 10.224.214.133 with SMTP id ha5mr4726963qab.155.1312823244412; Mon, 08 Aug 2011 10:07:24 -0700 (PDT)
Received: from [192.168.1.213] ([190.22.90.82]) by mx.google.com with ESMTPS id q9sm4504667qct.44.2011.08.08.10.07.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 10:07:23 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_FCDBA439-571B-4FA2-A0E1-60FD69A816F9"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4E4011CC.7030903@adida.net>
Date: Mon, 08 Aug 2011 13:07:40 -0400
Message-Id: <52BF03BA-2831-4AB5-B03A-E9F8D8FE63A4@ve7jtb.com>
References: <0c100e09-dad3-4cc5-87a2-b42f1f6c834b@default> <4E4011CC.7030903@adida.net>
To: Ben Adida <ben@adida.net>
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:06:59 -0000

+1  For openID Connect forcing x.509 processing in all environments is not practical, or desirable.

Not all environments can call out to openSSL.  We will need to create new native libraries for some environments.  Having a simple JSON container for key information is important to our developers.

John Bradley
On 2011-08-08, at 12:41 PM, 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.
> 
> 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