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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 05 August 2011 18:49 UTC

Return-Path: <hallam@gmail.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 B392C11E8097 for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 11:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.878
X-Spam-Level:
X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1]
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 f8j+jeFiIk0G for <woes@ietfa.amsl.com>; Fri, 5 Aug 2011 11:49:20 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD24411E80B2 for <woes@ietf.org>; Fri, 5 Aug 2011 11:49:19 -0700 (PDT)
Received: by yxp4 with SMTP id 4so2234475yxp.31 for <woes@ietf.org>; Fri, 05 Aug 2011 11:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fqHsyYf3LuClMpKJ3qNflHrNNY61yhUd5HUMo/QooBs=; b=WvRGje3MGEr3qyS5iWlNP5Ydh6jW17SWflIddlDwmJ0C9eMl7imuXwgPafLaxjanhC mnSrqlmEckdfM1ZXWdL3cUSK8qfUwSJaYdgam2eYkYft9wlkTAZxBb68ogmm4iRv/bh6 CcXrWcXnUnywSMQRoBPRVf9m4qzyVqDdowZFo=
MIME-Version: 1.0
Received: by 10.101.134.40 with SMTP id l40mr173386ann.138.1312570177649; Fri, 05 Aug 2011 11:49:37 -0700 (PDT)
Received: by 10.100.34.3 with HTTP; Fri, 5 Aug 2011 11:49:37 -0700 (PDT)
In-Reply-To: <4E3C32C3.4090004@ieca.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>
Date: Fri, 5 Aug 2011 14:49:37 -0400
Message-ID: <CAMm+LwgMama=X+V2=oSG7LxBEG9aSTP0JQFzA36BaYychFrRLg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary=001636c9274c2e7d9604a9c68f49
Cc: "woes@ietf.org" <woes@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.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 18:49:20 -0000

On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <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...

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.



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