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

Phillip Hallam-Baker <> Sat, 06 August 2011 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9739021F874E for <>; Sat, 6 Aug 2011 07:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.456
X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xSH9UmxlHTg2 for <>; Sat, 6 Aug 2011 07:58:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17F9121F85BB for <>; Sat, 6 Aug 2011 07:58:27 -0700 (PDT)
Received: by yxp4 with SMTP id 4so2559784yxp.31 for <>; Sat, 06 Aug 2011 07:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xioZ6cpHc7G1MdlrgharP27Chjq/vxbWpbf4VresXiU=; b=Q3jbvd7wmws+/VBHZN+XdQdQ55bz0qSZxtyHQItR0jHs3EKx/zxdLC5ioDhcOUivs3 kVqt4m7rOJFVeQCY9gBY7QWTcrRbh9IoBi/2PFDsj4+Aj4mflLigH3vp8B6CTms5LBYb BS9hnOZn8ukbQczGDID9SmYHa31M1FyH959hA=
MIME-Version: 1.0
Received: by with SMTP id r1mr3000894anp.6.1312642727237; Sat, 06 Aug 2011 07:58:47 -0700 (PDT)
Received: by with HTTP; Sat, 6 Aug 2011 07:58:47 -0700 (PDT)
In-Reply-To: <>
References: <b9332337-4efa-4355-93a9-7866a5506bb5@default> <> <> <> <> <>
Date: Sat, 6 Aug 2011 10:58:47 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Leif Johansson <>
Content-Type: multipart/alternative; boundary=001636c5bbf379591904a9d773c1
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: Sat, 06 Aug 2011 14:58:28 -0000

How about one spec with two implementation profiles?

WOES-P  MUST implement PKIX key handling.
WOES-R  MUST implement raw key handling.

The reason I think we need both is that the WOES-R mechanism is going to be
much more appropriate for the applications for which self-signed certs are
generally used.

[I really can't see what benefit a self signed cert provides over a raw key
for any application. All you have is proof that the holder of the key
created a self-signed cert.]

So in my application I am going to want a stack that supports certs for the
Internet trust aspects and a stack that supports raw key for the handheld
device aspects. I don't want to implement the raw key in the Internet
request side of things and I definitely don't want to implement the cert
stuff in the handheld device. Mobile phones come with PKIX libraries but
thermocouple driver chips don't .