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

Sean Turner <> Fri, 05 August 2011 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E41D021F8B6B for <>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.658
X-Spam-Status: No, score=-101.658 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E9A6N6uUisIe for <>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 3312621F8B77 for <>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
Received: from [] by with NNFMP; 05 Aug 2011 20:23:41 -0000
Received: from [] by with NNFMP; 05 Aug 2011 20:23:41 -0000
Received: from [] by with NNFMP; 05 Aug 2011 20:23:41 -0000
Received: (qmail 69630 invoked from network); 5 Aug 2011 20:23:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1312575821; bh=yETqyv+xSEUI3zKAPQs89aZAaZ/d2qa9brqmNGQGhdU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IkqOVXrH1Ty5drMFqffCiEaY3iyiS1OIPzmPzkNySwfNJZ5dGWhYbN6qIEGigGPnkKbZDhqCuD/abtITDAU+9L9OH9UPkqOBfsQvx5v/MtNmXRI9nUBkpdis6Z49piOXUGJcDzKwsbcOqz6Vy786VOPnPS8IuKAzFl8a4U8Tdr0=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: uT5OAOsVM1nvWZcc5uMxW0Bc8X1MmuYgRQOChoCD9zOy2Wa jJoIEGaQufd1ala9Q6TGV8IPTgfQzazce0dNj4LI7aKdMpBN6V84c4bnV0Le jT7l61yQbdmdZQ_baP4NLbOWVbeNzqL_7lxEvaThWF.Zgy9YPqIB_1wwVOd0 BsqydI8e3j3kzzjCRTEG.bZ2K5ABeY6n5EHuCQ7yufHDKf6_oo.._rLbfBtp IkMdBQPZzB90lVI2bMv6AAqyTvN3W9n.YrUYkPide1UIAAQtHajvNvueMEKZ xmAqPgYwJqU.5Ljt1gx5c6xUUHeV1uJhdOv1lVXPOJ9rfZxbiw0eUhW.03MJ QNGoOseBF1cjPpVgYzyk1pm1iOYFJWq8PJRT62PhH_6Pshon6.rOAca9iKDT 1VbKnRSwohW9Rpc0u2AlyLnhehesDUQH7pF_QeHCeeVBkhHYGzWUqSj7BC0r YYrdgZUf8rDO7gIpX1lTADasdTnLDL2XTKXznI1uPHqDJrCVdF9wr83ilX25 kG1dUxoevx8aZ3qfMq2A5hts6A5DWmiMtJcM1qwYqtwXEcIWFV2TXmi1LE3u KnoA2pQ--
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from (turners@ with plain) by with SMTP; 05 Aug 2011 13:23:40 -0700 PDT
Message-ID: <>
Date: Fri, 05 Aug 2011 16:23:38 -0400
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <b9332337-4efa-4355-93a9-7866a5506bb5@default> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
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: Fri, 05 Aug 2011 20:23:25 -0000

On 8/5/11 2:49 PM, Phillip Hallam-Baker wrote:
> On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <
> <>> wrote:
>     On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
>         Question: What exactly is a 'raw key' in any case?
>     I believe the people that want this are trying to avoid X.509.  I'd
>     bet a $1 it won't end up just being the 'raw key' there's going to
>     be parameters, etc.  If you look at what Mike's proposing in
>     <> which I
>     believe is one draft on offer as input, it already includes more
>     than just the key - as it should.
> At some point he will add a criticality flag but call it something else.
> Like Conditions. There was some guy who did that in SAML...

nothing like designing a protocol by committee ;)

> I am not even opposed to eventually creating a whole new cert format.
> Just as long as we don't fool ourselves into thinking that this is the
> easy option, its not.
>     I have never assumed that the charter item for a 'raw key' implied
>     that it was *the* way to convey the public key in the resulting
>     JSON-structures for signatures/encryption.  I have always assumed
>     there would be some faction that would want an option to refer
>     to|point to|include a certificate.
> Given the way certain charters have been used to lay claim to 'own'
> certain issues in the recent past I would like this to be explicit in
> the charter. I don't want to end up having a four month argument as to
> whether to do it.

I have no problem with adding something along the line of:


The resulting solutions will support both JSON-encoded public keys and 
X.509 public key certificates.

I purposely choose "support" and didn't specify which is the MTI.  We 
can have that debate when writing the spec.

do others have an issue with this?


>     We can fight about what the required mechanism is when we actually
>     write the spec.  I've gotten the impression that regardless of the
>     choice that wins a 'bare key' JSON format is needed - hence the
>     charter item.
> No, I don't think that there should be a required mechanism as I don't
> think this is going to be used on its own.
> Specifically for my protocol, Web Confirmation Protocol (WCP) support
> for certificates is definitely going to be a MUST for authenticating
> inbound confirmation requests. But support for raw keys is going to be a
> MUST for interaction between the service and the client.
> --
> Website: