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

Sean Turner <turners@ieca.com> Fri, 05 August 2011 20:23 UTC

Return-Path: <turners@ieca.com>
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 E41D021F8B6B for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.658
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9A6N6uUisIe for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by ietfa.amsl.com (Postfix) with SMTP id 3312621F8B77 for <woes@ietf.org>; Fri, 5 Aug 2011 13:23:24 -0700 (PDT)
Received: from [98.139.91.69] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 20:23:41 -0000
Received: from [98.139.91.52] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 20:23:41 -0000
Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 20:23:41 -0000
X-Yahoo-Newman-Id: 827308.10945.bm@omp1052.mail.sp2.yahoo.com
Received: (qmail 69630 invoked from network); 5 Aug 2011 20:23:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; 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 thunderfish.westell.com (turners@96.231.124.70 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 05 Aug 2011 13:23:40 -0700 PDT
Message-ID: <4E3C514A.1000402@ieca.com>
Date: Fri, 05 Aug 2011 16:23:38 -0400
From: Sean Turner <turners@ieca.com>
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 <hallam@gmail.com>
References: <b9332337-4efa-4355-93a9-7866a5506bb5@default> <CA60EB18.D5CF%joe.hildebrand@webex.com> <CABcZeBPWj8GC4nK7qZ_uypk+4uAPtGYhQu3rAdz+xr9AuP13rg@mail.gmail.com> <CAMm+LwiCzCKYA4JJ-iQVftrxLWYgeW+ahd6wVbnfhr2v4aB71w@mail.gmail.com> <4E3C32C3.4090004@ieca.com> <CAMm+LwgMama=X+V2=oSG7LxBEG9aSTP0JQFzA36BaYychFrRLg@mail.gmail.com>
In-Reply-To: <CAMm+LwgMama=X+V2=oSG7LxBEG9aSTP0JQFzA36BaYychFrRLg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "woes@ietf.org" <woes@ietf.org>
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: 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 <turners@ieca.com
> <mailto:turners@ieca.com>> 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
>     http://datatracker.ietf.org/__doc/draft-jones-json-web-key/
>     <http://datatracker.ietf.org/doc/draft-jones-json-web-key/> 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:

OLD:

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?

spt

>     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: http://hallambaker.com/
>