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

Hal Lockhart <> Mon, 08 August 2011 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E20F121F8661 for <>; Mon, 8 Aug 2011 11:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e9BikIOmCtyM for <>; Mon, 8 Aug 2011 11:07:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 514EC21F85AB for <>; Mon, 8 Aug 2011 11:07:14 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.4) with ESMTP id p78I7Weg024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Aug 2011 18:07:34 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id p78I7VrC006519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 18:07:32 GMT
Received: from ( []) by ( with ESMTP id p78I7PNL007027; Mon, 8 Aug 2011 13:07:25 -0500
MIME-Version: 1.0
Message-ID: <fd46e0ae-9761-425f-a302-99d543259821@default>
Date: Mon, 8 Aug 2011 11:07:23 -0700 (PDT)
From: Hal Lockhart <>
To: "Paul C. Bryan" <>,
In-Reply-To: <1312823364.5484.21.camel@dynamo>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook (410211) [OL]
Content-Type: multipart/alternative; boundary=""
X-Source-IP: []
X-CT-RefId: str=0001.0A090204.4E4025E6.0092,ss=1,re=-2.300,fgs=0
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 18:07:16 -0000

I think people are reading more into my comment about raw keys than I said.

The specific historical use case was that we needed to verify a signature with a specific PK. There was no certificate chain, no PKI processing of any kind required. The key was explicitly trusted. Revocation was out of scope. Therefore we (SAML TC) decided to specify the use of a PK as a binary value, not imbedded in a cert. 

When implementations were done, it was discovered that common libraries, OpenSSL for example, expected the key to be contained in something that looked like an ASN.1 formatted certificate. It would not accept a binary value. In order to use such a library, it was necessary to gin up an ASN.1 certificate structure and stuff in the key value, simply to comply with the requirements of the method signature.

I am not talking about doing PKI. I am not talking about doing X.509. I am not talking about processing any other part of the cert except the PK.

I am talking about defining something that is practical to implement. I agree with those who believe both forms should be specified. 

There seems to be a distinct argument about the generality of the spec, which I will address in a separate message.

  -----Original Message-----
  From: Paul C. Bryan []
  Sent: Monday, August 08, 2011 1:09 PM
  Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

  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.

woes mailing list