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

Ben Adida <ben@adida.net> Mon, 08 August 2011 16:41 UTC

Return-Path: <ben@adida.net>
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 B50EA21F8B15 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 09:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 SBfY4kDB7VU7 for <woes@ietfa.amsl.com>; Mon, 8 Aug 2011 09:41:24 -0700 (PDT)
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0E04021F8801 for <woes@ietf.org>; Mon, 8 Aug 2011 09:41:23 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id B845E2040E for <woes@ietf.org>; Mon, 8 Aug 2011 12:41:49 -0400 (EDT)
Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 08 Aug 2011 12:41:49 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=u/S5ItjP0rPjM3fTmtIxAG oEAzQ=; b=quwZmjrn5AVMV3exH312JGtbaHm9C8cIlxSHPK/MsAuCbzrKAgCy4Q Gd7B+sTnpJmVfSMIZFhYXVHQoEev4bAoSFoHla19OG6RT7ThAwAKng349DtGbbVE 325pIPQt8JeM1ybbh4DHWShlDp/YIQPkqhQomIfRU80xCEWS4WjzM=
X-Sasl-enc: DSdzFuaW0OY/UQkOBGCD7xdJplQT6EokPaSYjAprVHZ3 1312821709
Received: from Ben-Adidas-MacBook-Pro.local (c-67-188-2-67.hsd1.ca.comcast.net [67.188.2.67]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6613F45B111 for <woes@ietf.org>; Mon, 8 Aug 2011 12:41:49 -0400 (EDT)
Message-ID: <4E4011CC.7030903@adida.net>
Date: Mon, 08 Aug 2011 09:41:48 -0700
From: Ben Adida <ben@adida.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: woes@ietf.org
References: <0c100e09-dad3-4cc5-87a2-b42f1f6c834b@default>
In-Reply-To: <0c100e09-dad3-4cc5-87a2-b42f1f6c834b@default>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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 16:41:24 -0000

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