Re: [rtcweb] Regarding the assertion mechanism in the new security draft
Eric Rescorla <ekr@rtfm.com> Mon, 14 November 2011 08:42 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD321F8E38 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 00:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.937
X-Spam-Level:
X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p4K0tp6Ps6z for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 00:42:08 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42A21F8E32 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 00:42:08 -0800 (PST)
Received: by ggnr5 with SMTP id r5so695089ggn.31 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 00:42:08 -0800 (PST)
Received: by 10.146.72.7 with SMTP id u7mr2513670yaa.9.1321260128071; Mon, 14 Nov 2011 00:42:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.146.88.36 with HTTP; Mon, 14 Nov 2011 00:41:26 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <A1B638D2082DEA4092A268AA8BEF294D180B8F3616@ESESSCMS0360.eemea.ericsson.se>
References: <A1B638D2082DEA4092A268AA8BEF294D180B8F333B@ESESSCMS0360.eemea.ericsson.se> <CABcZeBM8uhr5fxkcFy7Vob6zmF5Q9QzVAnHBR74w8o+LazysAA@mail.gmail.com> <A1B638D2082DEA4092A268AA8BEF294D180B8F3616@ESESSCMS0360.eemea.ericsson.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Nov 2011 00:41:26 -0800
Message-ID: <CABcZeBO+D-m51sJ-BWhFiSNzyp+o9s_wUysCvpAGZp4AqPUgpQ@mail.gmail.com>
To: Oscar Ohlsson <oscar.ohlsson@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 08:42:09 -0000
On Mon, Nov 14, 2011 at 12:36 AM, Oscar Ohlsson <oscar.ohlsson@ericsson.com> wrote: > I had a slightly different scenario in mind when I was posing the question. Say that I have several client certificates (issued by some CA) installed in my browser and I want to use one of them to authenticate myself in WebRTC. Would I then also need to sign the ROAP session ID using this certificate? If not, what is the difference between a CA issued certifcate and self-signed certificate whose fingerprint is asserted through BrowserID? I would assume that whatever mechanism you had for generating assertions would have them cover the same data values. I.e., I'm not yet ready to commit on whether we need the session ID, but presumably it should always be covered or not. -Ekr
- [rtcweb] Regarding the assertion mechanism in the… Oscar Ohlsson
- Re: [rtcweb] Regarding the assertion mechanism in… Eric Rescorla
- Re: [rtcweb] Regarding the assertion mechanism in… Eric Rescorla
- Re: [rtcweb] Regarding the assertion mechanism in… Oscar Ohlsson