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

"Paul C. Bryan" <> Mon, 08 August 2011 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBFCC21F85FE for <>; Mon, 8 Aug 2011 10:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iKI86KBcntYd for <>; Mon, 8 Aug 2011 10:09:08 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 5343A21F8588 for <>; Mon, 8 Aug 2011 10:09:07 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTkAYQQLWXixjHmi/; Mon, 08 Aug 2011 17:09:34 UTC
Received: by pzk6 with SMTP id 6so3815171pzk.36 for <>; Mon, 08 Aug 2011 10:09:20 -0700 (PDT)
Received: by with SMTP id x20mr6019143wfx.288.1312823359986; Mon, 08 Aug 2011 10:09:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id u6sm6338292pbh.32.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 10:09:19 -0700 (PDT)
From: "Paul C. Bryan" <>
In-Reply-To: <>
References: <0c100e09-dad3-4cc5-87a2-b42f1f6c834b@default> <>
Content-Type: multipart/alternative; boundary="=-gSZmC/xeaJPa9sNDMyYL"
Date: Mon, 08 Aug 2011 10:09:24 -0700
Message-ID: <1312823364.5484.21.camel@dynamo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Aug 2011 17:09:10 -0000

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 
>, 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